SMTP TLS Reporting: Set Up and Read TLS-RPT Data
Publish TLS-RPT, route reports, parse failure data, and define retention without confusing transport evidence with inbox placement.
Product & Engineering · September 25, 2026 · 2 min read
TLS-RPT is a reporting mechanism for SMTP TLS failures. Publish a _smtp._tls TXT record that describes where reports should go, then treat the resulting data as transport evidence. It does not measure inbox placement and should not be used as a substitute for message or complaint data.
Design the reporting path
Read [RFC 8460] and decide whether reports arrive at a mailto or HTTPS endpoint supported by your tooling. Define an owner, authentication and access controls, retention, parsing, and redaction policy before publishing. Test the endpoint with a fixture and ensure the system can associate a report with a domain and reporting period.
If you use MTA-STS, keep policy deployment and reporting changes coordinated but separate. A TLS-RPT record does not enforce TLS; it tells participating senders where to report policy evaluation results.
Interpret a report carefully
Extract report source, period, policy domain, successful sessions, failed sessions, failure reason, receiving MX, and policy result. Group failures by certificate, DNS, hostname, TLS negotiation, or policy retrieval. Compare timestamps with certificate renewals, MX changes, DNS edits, and provider migrations. Do not turn a report count into a percentage for all mail unless its coverage and denominator are known.
Feed transport events into sending observability, but keep them distinct from SMTP acceptance, bounce, complaint, and placement. If a failure appears, preserve the report, reproduce the relevant DNS or HTTPS path, and assign the infrastructure owner before changing policy.
Related resources
Use the Email Infrastructure academy for transport architecture.
This workflow should be checked against the cited standards and current provider documentation 1.
Retention and privacy boundaries
Reports can contain domains, MX names, timestamps, and failure details that should not be available to every application user. Restrict access, define a retention period, and redact data before copying it into tickets. Correlate a failure with DNS, certificate, or policy changes, but avoid attributing a delivery or placement outcome when the report only describes the TLS session.
Make TLS reporting operational
TLS-RPT is feedback about attempted encrypted delivery, not proof that every message was encrypted, delivered, or placed. Define the reporting domain, URI owner, parser, retention, access, and incident responder before publishing. For an external destination, preserve the authorization evidence.
| Field | Evidence | Stop/qualify rule |
|---|---|---|
| _smtp._tls | exact TXT, TTL, ticket | Stop on malformed URI or wrong domain |
| Policy | mode, URI, owner, failure behavior | Qualify as aggregate telemetry |
| Authorization | record/token and approver | Stop until confirmed |
| Ingestion | sample, parser version, timestamp | Stop if unreadable or dropped |
| Incident | severity, owner, provider packet | Pause unexplained failures |
| Access | permissions and retention decision | Qualify with counsel if needed |
Use RFC 8460 and RFC 8461. Start monitoring-only, classify failures as policy, certificate, DNS, or network, and link each to a ticket. Do not increase volume while a failure is unexplained. Revalidate after certificate, DNS, provider, or destination changes.
References
Resources in this guide
| Field | Question | Action |
|---|---|---|
| Report period | When did the observations occur? | Align with changes |
| Policy domain | Which domain was evaluated? | Check intended policy |
| Successful sessions | What worked? | Track coverage |
| Failure type | What failed? | Inspect certificate, DNS, or TLS |
| Report endpoint | Where was data sent? | Verify access and retention |
Frequently asked questions
What does TLS-RPT prove?
It reports observations about SMTP TLS policy evaluation for participating senders. It does not prove that every message was observed or that mail reached the inbox.
Where should TLS-RPT reports go?
Use a controlled mailto or HTTPS endpoint supported by your operational tooling, with an owner, access controls, parsing, and retention plan.
Is TLS-RPT the same as MTA-STS?
No. MTA-STS publishes a transport policy; TLS-RPT reports failures and successes related to TLS policy evaluation.
Continue learning
Instrument sending observability
Continue with the closest operational guide.