TLS-RPT

TLS-RPT (SMTP TLS Reporting, defined in RFC 8460) is a standard that lets a domain owner receive aggregate reports about problems establishing encrypted TLS connections when email is delivered to them. Thanks to it, an administrator learns whether their mail servers are being reached over an encrypted channel, or whether some messages arrive over an unsecured path or hit certificate errors.

How TLS-RPT works

The mechanism is published as a special TXT record in DNS, placed under the name _smtp._tls.yourdomain.com. The record contains an address — most often an email (mailto:) or an HTTPS endpoint — to which sending servers should submit their reports. When a remote sender's server tries to deliver mail to a domain covered by TLS-RPT, it collects information about the success or failure of the TLS negotiation and then, once a day, sends an aggregated report in JSON format. The report contains the number of successful and failed sessions and categories of errors — for example, an expired certificate, no encryption support, or a policy mismatch. TLS-RPT does not enforce encryption; it is purely an observability layer that gives insight into what happens "in transit."

Practical application

TLS-RPT is almost always deployed together with MTA-STS — the standard that actually enforces encrypted mail delivery. The division of roles is natural: MTA-STS protects the transmission, while TLS-RPT reports whether that protection is working and where problems appear. Thanks to the reports, an administrator quickly spots a misconfigured partner server, an expiring certificate, or downgrade attempts. Combined with email authentication through DMARC, this creates a complete picture of a domain's mail security — from sender authenticity to the confidentiality of the SMTP transmission itself. Deployment comes down to adding two DNS records and pointing the reports at a service that can collect and analyse them.