TLS-RPT (SMTP TLS reporting)
TLS-RPT is a way for a domain to ask other mail servers to report how their encrypted connections to it went. You publish a TXT record naming an address to send reports to, and senders that support it post a daily summary of successful and failed sessions. It is the feedback channel that makes MTA-STS and DANE deployable without guessing.
At a glance
- Category
- Transport security
- Published at
- A TXT record at _smtp._tls.<domain>
- Reports go to
- A mailto or https destination named in the record
- Frequency
- Daily aggregates, from senders that implement it
- Reports on
- Successful sessions, and each kind of negotiation failure
- Specified in
- RFC 8460
How it works
The record names one or more destinations for reports. A sending organisation that supports the standard keeps counts of its connections to your domain over a day — how many negotiated TLS successfully, how many failed a certificate check, how many found no policy — and posts a structured summary to the destination you named. The reports are aggregate rather than per message, so they describe your inbound transport security without revealing who wrote to whom.
Why it matters
Transport security is the one area where a misconfiguration is completely silent: an expired certificate on one of your MX hosts causes strict senders to fail while everyone else quietly downgrades, and nothing in your own logs says so. Reporting is what makes that visible from the outside in. It is also the reason MTA-STS can be rolled out safely, because testing mode is only useful if somebody tells you what failed during it. A week of clean reports is the evidence that turns enforcement from a gamble into a formality.
Example
A domain publishes a TXT record at the reporting name pointing at a mailbox its operations team reads, then publishes an MTA-STS policy in testing mode. Over the following week the reports show a few thousand successful sessions and a handful of certificate mismatches, all against one secondary MX host whose certificate covers the wrong name. That host is fixed, the next week's reports are clean, and the policy moves to enforce.
Common mistakes
- 01Enabling MTA-STS without reporting, which leaves you enforcing a policy whose failures nobody can see.
- 02Pointing reports at a mailbox nobody reads, which is the same as not publishing the record at all.
- 03Expecting reports from every sender, when only organisations that implement the standard send them.
- 04Reading a small number of failures as a crisis, when some are unrelated hosts probing rather than real mail being lost.
Related terms
Frequently asked questions
Do I need TLS-RPT to use MTA-STS?
Not technically, but deploying without it is unwise. Testing mode exists to surface failures before you enforce, and reporting is how those failures reach you.
What is in a report?
Aggregate counts per sending organisation per day: successful sessions and each category of failure, with the hosts involved. There is nothing about individual messages or recipients.
Who sends these reports?
Sending organisations that have implemented the standard, which includes several of the largest mailbox providers. Smaller senders often do not, so the reports are a sample rather than a complete picture.
Sources
- RFC 8460: SMTP TLS Reporting — IETF
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.