TLS-RPT explained: daily reports on whether mail to you is encrypted
What a TLS-RPT record is, what the daily reports contain, the result types you will see, and what to do when they show failures.
When another mail server sends you email, it tries to encrypt the connection with TLS. If that fails, many servers fall back to plain text and nobody notices. TLS-RPT (RFC 8460) is a record in your DNS that asks those servers to send you a short report each day: how many connections worked and how the others failed.
The record
It is a TXT record at _smtp._tls under your mail domain. The rua value says where reports go: a mailto: address or an https: endpoint, or both, separated by a comma.
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
TLS-RPT stands on its own: you do not need MTA-STS to receive reports, although the two are used together. The reports cover plain STARTTLS and, where you publish them, MTA-STS and DANE policies.
What a report contains
A report is a JSON file, usually compressed, that large mail providers send once a day. It names the reporting organization and the time window and, for each policy that was applied, counts the successful and failed sessions. For failures it lists the result type, the sending server’s address, the receiving mail host and how many sessions failed. It never holds message content, subjects or recipient addresses.
Result types
starttls-not-supported: your mail server did not offer encryption.
certificate-expired, certificate-not-trusted and certificate-host-mismatch: the certificate on the mail server is out of date, was signed by a CA the sender does not trust, or was issued for a different name than the mail host.
validation-failure: the TLS connection failed for a reason that is none of the above.
sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid: the MTA-STS policy file could not be fetched, is malformed, or its web host has a bad certificate.
tlsa-invalid and dnssec-invalid: problems with DANE records or their DNSSEC signatures.
What to do about failures
Start with the receiving mail host in the report. Failures against one host point to that server: renew or replace its certificate, make sure the certificate names the mail host (not your domain), and turn on STARTTLS. Failures from one sender against all of your hosts usually come from that sender’s side, and a few failed sessions among thousands of good ones are normal noise.
Failures that start right after you publish an MTA-STS policy mean that the policy and your servers disagree. Check the mx lines and the certificates with the MTA-STS tool.
Reading reports in practice
Reports arrive as compressed attachments, so a normal mailbox fills with files nobody opens. Use a dedicated address or let a service read them. ProbeKit gives each hosted domain its own report address, adds the daily totals up by day, receiving mail server and failure type, and opens an alert when failures jump. If a TLS-RPT record already exists, ProbeKit shows it with its address added and keeps yours. Large providers report once a day, so the first numbers appear within a day or two.
Common questions
- Do I need TLS-RPT if I do not use MTA-STS?
- It is still useful: it shows whether senders can encrypt mail to your servers at all, and it is the safest way to prepare for MTA-STS.
- Who sends TLS-RPT reports?
- Mainly large mail providers. Small senders usually do not, so a quiet week from one provider does not mean that everything is fine.
- Do the reports contain my mail?
- No. They hold counts and technical details of connections, never message content.
- Where does the record go?
- Publish it as a TXT record at the name _smtp._tls under your mail domain, for example _smtp._tls.example.com.
Try it on your own setup:
Check your TLS-RPT record