What is a TLS-RPT record and how do I set up SMTP TLS reporting?

SMTP TLS between mail servers is opportunistic: if STARTTLS is missing or a certificate is broken, most senders quietly fall back to plaintext rather than fail. That means your inbound mail can be downgraded and read in transit without anyone noticing. TLS-RPT (SMTP TLS Reporting, RFC 8460) closes the visibility gap. By publishing one TXT record, you ask every sending organisation to email or POST you a daily aggregate report of how their TLS sessions to your mail servers went.

What the record looks like

TLS-RPT is deliberately tiny — there are no policy decisions to make, because it never changes how mail is delivered, it only collects evidence: _smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]".

• v=TLSRPTv1 — version tag, always first, currently always this value.
• rua= — where reports go. A mailto: address, an https: endpoint that accepts an HTTP POST, or a comma-separated mix of both.

Multiple destinations are allowed and may be mixed: v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.com/tlsrpt. Note there is no mode and no max_age — TLS-RPT is report-only by design, unlike MTA-STS.

How it pairs with MTA-STS and DANE

TLS-RPT is the reporting companion to the two TLS enforcement standards. MTA-STS (a cached HTTPS policy) and DANE (TLSA records pinned via DNSSEC) both tell senders to require valid TLS and refuse delivery when it's missing — which can silently bounce legitimate mail if your setup is wrong. TLS-RPT gives you the visibility to catch those failures before you enforce. The recommended order: publish TLS-RPT (zero risk — data only); deploy MTA-STS in testing mode (or DANE); watch reports for a week or two; move to enforce only once reports are clean. Without TLS-RPT you'd switch to enforcement and discover broken senders only when their mail starts bouncing.

How to set it up

1. Pick a destination — a dedicated mailbox is simplest; many DMARC report processors also ingest TLS-RPT, so you can reuse one.
2. Build the record with the TLS-RPT generator.
3. Add a TXT record at host _smtp._tls in your DNS provider with the generated value.
4. Save and wait for propagation (typically 5–60 minutes).

Reading the reports

Reports arrive as gzipped JSON, by email or HTTP POST. Each names the reporting organisation, a date range, and result types with success/failure counts — values like starttls-not-supported, certificate-host-mismatch, certificate-expired, validation-failure, and successful-session. A few stray failures from an obscure forwarder are normal; a consistent failure from a large provider like Google or Microsoft is a signal to fix your MX certificate or MTA-STS policy before you enforce anything. Point rua at a mailbox or processor that can parse the JSON.

It's useful even on its own

You don't need MTA-STS or DANE first. On its own, TLS-RPT reports on opportunistic STARTTLS successes and failures for inbound mail — which can reveal an MX server quietly accepting plaintext or presenting a broken certificate. It's the lowest-risk first move toward hardened SMTP transport. Pair it with the MTA-STS Generator, validate with the MTA-STS Checker and SMTP TLS Checker, or run a full scan on the IntoDNS.ai homepage.