What is TLS-RPT (SMTP TLS reporting)?
TLS-RPT is the record that asks providers worldwide to send you, every day, a report of what worked and what failed when delivering email to your domain over an encrypted channel. It protects nothing on its own: it is the measuring instrument for the transport layer, and it is what makes requiring mandatory encryption safe, because it shows who was failing before the requirement starts refusing messages. Defined in RFC 8460, published in an _smtp._tls record.
How TLS-RPT works
Whoever tries to deliver email to your domain is the one who can see whether the encryption worked. TLS-RPT is the formal request for those providers on the other side to report what they saw.
You publish the destination address
A text record at _smtp._tls.yourdomain.com, holding v=TLSRPTv1 and a rua=mailto: followed by the address that will receive the reports, tells the world where to send them. The destination can also be a web address.
Every sending provider measures its deliveries
When delivering to you, the sender's server records whether it managed to establish the encrypted channel, whether the certificate validated, and whether your policy was found and applied.
The report arrives once a day
Providers aggregate the whole day's result and send a file with the success and failure counts, the type of each failure and the addresses involved.
You read it and fix things before requiring
That content is what tells you whether the policy can move to enforcement without refusing legitimate senders, and it is what flags a certificate about to become a problem.
Source: RFC 8460, the official SMTP TLS Reporting specification published by the IETF, which defines the _smtp._tls record, the report format and the failure types it names, gathered there in two blocks: negotiation failures and policy failures.
Why so many publish it and never read it
- The report is built for machines, not people. The file is structured data, usually compressed, and it lands in a mailbox. Without a tool to turn that into readable text, it piles up unread.
- Reading the TLS report tends to sit behind a paid tier. The authentication report, from DMARC, has plenty of free services that return a readable summary; on those same platforms, reading the TLS report often appears only on the paid plans. Free options and open tooling do exist, but you have to go looking for them, and that pushes the subject to the back of the queue.
- It only sees those who implement it. A provider that never adopted the standard sends no report, so silence from a source does not prove it is delivering well: it proves only that it does not report.
- It looks backwards, not at the present. The report closes a full day on UTC time and is then sent with a few hours of deliberate delay, so as not to overload whoever receives it. It serves diagnosis and trend, not a real-time alarm about a delivery that just failed.
The three families of failure the report lets you tell apart
- Negotiation failure The most direct case: the server on the other side never offered the switch to an encrypted channel. In the report it shows up under the name starttls-not-supported, and it is the sign that delivery went, or would have gone, in plain text.
- Certificate failure The channel could be encrypted, but the identity did not check out: the report separates each case by name, certificate-expired for the expired one, certificate-host-mismatch for the one issued under another name and certificate-not-trusted for the untrusted issuer. It is the family that causes the most alarm on the eve of enforcing, and the easiest to fix in advance.
- Policy failure The sender could not fetch your protected-channel policy, or found it invalid: those are the names sts-policy-fetch-error and sts-policy-invalid. The report separates here the two routes to a requirement that the standard allows: the one that publishes the policy on a website, where the cause is usually that site's certificate or availability, and the one that publishes it in signed DNS (DANE), where the cause sits in the record. In neither case is the problem the mail server.
- And the other side of the coin This is not a fourth family, it is the counterpart to the three: the report also counts successes. It is that count, rather than the absence of complaints, that authorizes tightening the requirement: you come to know how many deliveries a day are already happening the right way.
Requiring without measuring is gambling
The order in which these three pieces arrive is what separates a calm hardening from a self-inflicted incident. Requiring an encrypted channel with no reporting is deciding in the dark: you do not know which partners, customers or systems still deliver in a way the requirement will refuse, and the first news of the problem comes by phone, with someone saying the email bounced. With reporting on first, the same decision becomes bookkeeping: for weeks you see who fails, for what reason and at what volume, you fix what is yours, warn whoever needs warning, and only then tighten. And the damage in that version is not technical: it is the order that never reached the customer, the invoice nobody received, and the partner who concluded your company had stopped replying. It is the same principle as sender authentication, where the monitoring policy exists to measure before blocking. The instrument does not protect, but it is what lets you protect without breaking anything.
How to get value from TLS reporting
Publishing the record is the easy part and where most people stop. The value sits in the four steps that follow:
- Point the report at a destination someone actually watchesA mailbox nobody opens turns the measurement stage into waiting. Use a monitored mailbox or a service that receives and processes it, never the personal email of whoever configured it.
- Make sure someone can actually read what arrivesThe file is structured, compressed data. Before publishing, decide how it will be turned into something readable, whether by a tool or by an internal process. Without that, the record is decorative.
- Look at the certificate family firstIt is the one that shows up most and the one that most blocks delivery once the requirement is live. A certificate expiring, or with a name that does not match, is a known problem with a date on it.
- Use the success count to decide when to requireThe question is not whether failures appeared, it is whether the remaining failures come from sources you recognize and accept losing. When there are no more surprises, enforcement stops being a risk.
- Keep reporting on after you enforceIt stops being preparation and becomes monitoring: certificates expire, servers change, partners reconfigure. The report is what warns you before the customer does.
In practice
TLS reporting is the flight instrument of email delivery: it does not make the plane fly, but flying without it in the dark is what brings one down. Publishing an encrypted-channel requirement before reporting is working is exactly that blind flight, and the cost shows up in the most expensive form there is, the legitimate message that stops arriving with nobody knowing why.
How Zamak handles TLS reporting
Zamak Technologies switches reporting on before any requirement, points the destination somewhere it is genuinely read, and uses the success and failure counts to decide when enforcement stops being a risk, alongside the team that already administers the environment. STARTTLS explains why the measurement is needed and MTA-STS is the requirement it makes safe. The email spoofing check gives the opening picture of what your domain publishes today. That watch is part of Managed Email Security and of Managed Cybersecurity in the Zamak Method.