TLS-RPT. Know When Mail Encryption Fails

What is TLS-RPT?

Encrypted mail delivery fails silently. When a sending server can't negotiate TLS with your MX host, expired certificate, hostname mismatch, STARTTLS stripped by a middlebox, it either falls back to plaintext or, if you enforce MTA-STS, queues and bounces. Either way, you never hear about it. The sender knows; you don't.

TLS-RPT (RFC 8460) fixes the feedback gap. You publish one TXT record asking senders to report TLS outcomes for mail addressed to your domain. Participating senders, Google and Microsoft being the ones that matter, aggregate a day's worth of delivery attempts and email you a compressed JSON report: how many sessions succeeded, how many failed, and exactly why.

Why it matters

• It's the safety net for MTA-STS. Enforcing a TLS policy without reports is flying blind: if your policy is wrong, mail silently stalls and you learn about it from angry customers. With MTA-STS in testing mode plus TLS-RPT, you see every would-be failure while mail still flows.
• It catches certificate problems on your MX hosts. Web certs get noticed when the browser screams. Mail server certs expire quietly. A wave of certificate-expired results in your morning report is often the first signal.
• It surfaces active attacks. starttls-not-supported reports for a server that definitely supports STARTTLS suggest someone between the sender and you is stripping encryption.

How to check it

dig +short txt _smtp._tls.example.com

If nothing comes back, you're not receiving reports. If a record exists, confirm the rua mailbox actually exists and isn't filtering the reports to spam.

Setting it up, step by step

1. Create a mailbox or alias for reports, e.g. tls-reports@example.com. A dedicated address keeps the JSON out of your inbox and makes filtering trivial.
2. Publish the TXT record at the _smtp._tls subdomain:

   _smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

   You can also specify an HTTPS endpoint (rua=https://...) if you run a report collector, or list multiple destinations separated by commas.
3. Wait a day or two. Reports arrive roughly every 24 hours, but only from senders that actually delivered (or tried to deliver) mail to you that day.
4. Read one report end to end, once. Gunzip the attachment; the JSON lists each policy evaluated, success counts, and failure details with result types and IPs. After that, let tooling watch for changes.

What's actually in a report

The result types you'll see, roughly in order of how much you should care:

• certificate-expired / certificate-host-mismatch, your MX cert needs fixing. Now.
• starttls-not-supported, your server stopped offering STARTTLS, or something on-path is stripping it.
• validation-failure, the sender couldn't validate your cert chain (often a missing intermediate).
• sts-policy-fetch-error / sts-policy-invalid, your MTA-STS policy file is unreachable or malformed.

Common mistakes

1. Publishing the record at the wrong name. It's _smtp._tls.example.com, both labels, with underscores. _tls alone or _smtp_tls won't be found.
2. A rua mailbox that doesn't exist. The record validates fine; the reports bounce. Send yourself a test mail to the address.
3. Spam-filtering the reports. Gzipped JSON attachments from an unfamiliar sender trip filters. Add a rule for the reporting addresses.
4. Setting it up and never looking. The record is step one; the value is in noticing when the failure counts change.
5. Enforcing MTA-STS without it. Not a TLS-RPT mistake exactly, but the most expensive way to skip it.

Monitoring TLS-RPT going forward

The record itself is simple, but it's also exactly the kind of thing that gets deleted in a DNS cleanup ("what's this underscore thing?") and nobody notices, because the absence of reports looks identical to the absence of problems.

DomainsDoc verifies your TLS-RPT record on every scan, checks the syntax, and alerts you if it disappears or changes, alongside MTA-STS, SPF, DKIM, DMARC, MX, and SSL checks that share the same root causes. Add your domain to start monitoring, or compare plans on the pricing page.