TLS-RPT (SMTP TLS Reporting) Record Checker
Fetches a domain's _smtp._tls TXT record to diagnose whether the report destination (rua) for failed TLS connections is configured correctly per RFC 8460. Useful alongside MTA-STS/DANE.
Tips
- TLS-RPT is declared by the receiving domain but consumed by sending mail servers, which use it to know where to send statistics whenever a TLS connection to your domain fails.
- The rua field can list a mailto: address, an https: endpoint, or both, separated by commas, so you can route reports to a mailbox and an automated collector at the same time.
- Reports arrive as JSON (application/tlsrpt+json, often gzip-compressed), so it helps to set up a dedicated parser or mailbox rather than expecting to read them by eye.
- Right after rolling out MTA-STS or DANE, keep an eye on TLS-RPT reports for a while to catch any misconfiguration you might have missed.
- Major mail providers such as Google, Microsoft, and Yahoo all send TLS-RPT reports, so domains that exchange a lot of mail with them benefit the most from adopting it.
FAQ
Side Note — The "silent failure" gap that TLS-RPT closed
TLS-RPT (TLS Reporting, RFC 8460) was published in 2018, almost alongside MTA-STS (RFC 8461). The two were developed in the same working group and share a lot in common — both build on a DNS TXT record, and both were jointly pushed forward by Google, Microsoft, Yahoo and others — but they play very different roles. MTA-STS is the enforcement layer that forces TLS; TLS-RPT is the observability layer that reveals what actually happened once you did.
Before TLS-RPT existed, a failed TLS handshake during SMTP delivery was, in most cases, logged only on the sending server and never surfaced to the receiving domain's administrator at all. An expired certificate or a misconfigured MTA-STS policy could silently break mail delivery, and nobody would notice until mail actually stopped arriving — a real operational blind spot.
With TLS-RPT in place, a daily aggregate report is sent to whatever destination you list in rua. The report is structured JSON (application/tlsrpt+json, often gzip-compressed) containing success/failure counts and, for failures, the underlying cause (a certificate mismatch, a failed STARTTLS negotiation, and so on) — built to be ingested by monitoring tooling rather than read by a human.
In practice, TLS-RPT is usually set up together with MTA-STS or DANE. Deploying enforcement alone gives you no way to notice if a misconfiguration is silently blocking legitimate mail; watching TLS-RPT reports lets you roll out enforcement safely.