What is TLS-RPT?
TLS-RPT — SMTP TLS Reporting, RFC 8460 — is the reporting half of mail transport security. It does not change how anyone delivers mail to you. It asks sending servers to tell you when encrypting their connection to your mail servers went wrong.
If DMARC reports are "who is sending mail as my domain, and did it pass?", TLS-RPT reports are "who tried to deliver mail to my domain, and could they do it securely?".
Why you would want it
Encryption between mail servers fails quietly. A certificate expires, a new MX host is added with the wrong certificate, a network device on the path interferes — and the sending server either delivers anyway, without encryption or to a server whose certificate it could not verify, or, if you publish MTA-STS in enforce mode, refuses to deliver. Neither outcome reaches you on its own.
TLS-RPT closes that gap. It is the standard first step before MTA-STS or DANE: publish it, read what senders report, fix what they find, and only then start enforcing.
The record
One TXT record at _smtp._tls.<your domain>:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"- The record must begin exactly
v=TLSRPTv1;— the version tag is case-sensitive. rua=names where reports go: amailto:address, anhttps:address that accepts the report by POST, or several of either separated by commas.- Publish one record. With more than one, senders treat the domain as not asking for reports at all.
Real records look exactly like this. google.com sends its reports to a mailto: address; microsoft.com uses an https: endpoint.
What a report contains
A sender that supports TLS-RPT sends at most one report per day, as a JSON file (usually gzip-compressed). It covers one 24-hour window and lists, per policy it applied (MTA-STS, DANE, or none):
- how many connections succeeded and how many failed, and
- for failures, the reason — for example an expired or mismatched certificate, a failed STARTTLS, or a policy that could not be fetched — with the sending and receiving server addresses.
A report with zero failures is good news, not an empty one: it tells you that sender reached you securely every time that day.
Who uses it
Most of the large mailbox providers both send TLS-RPT reports and publish the record for their own domains. Among ordinary business domains the record is uncommon, which mostly means nobody is looking at those failures — not that there are none.
What the Domain health card shows
| Result | What it means |
|---|---|
| not published | No v=TLSRPTv1 record exists. Optional: nobody will tell you when encrypted delivery to you fails. |
| reporting | Exactly one valid record; the note shows where reports go. |
| multiple records | More than one record; senders send no reports. Keep one. |
| no valid rua | The record has no rua=, or one of its destinations is neither mailto: nor https:. Fix the destinations so every sender can deliver its report. |
| malformed | A record is there but does not begin exactly v=TLSRPTv1;, so senders discard it. |
| couldn't read | Our DNS lookup failed. This says nothing about your domain — press Re-check. |
On the Starter, Scale and Enterprise plans, the Domain health card checks that the record is published correctly, and DMARCmetric can also collect the reports for you: your domain's Encrypted delivery (TLS-RPT) card shows the address to add to rua=, and then the last 30 days — how many connections were secure, which senders sent reports, and the reasons senders gave for any that failed. On the Free plan both are locked; if reports for your domain already reach us, the card shows how many arrived in the last 30 days.
The mail transport security rows — MTA-STS, TLS-RPT, DNSSEC and DANE — are part of the Starter, Scale and Enterprise plans; on the Free plan they are shown locked, marked Upgrade.