TLS-RPT

TLS-RPT (SMTP TLS Reporting) is a TXT record asking the servers that send you mail to report whether their connections to your mail servers were encrypted and verified. Like MTA-STS, and unlike DMARC, it is about mail arriving at your domain — the reports come from other people’s outbound servers, describing how delivery to you went.

The record lives at _smtp._tls under your domain:

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

rua= is required here, which is the one syntax difference worth remembering: a DMARC record without rua= is still a valid policy, but a TLS-RPT record without a destination does nothing at all. Both mailto: and https: destinations are allowed, and you can give a comma-separated list.

What the reports contain

Gzipped JSON, one report per sender per UTC day, with success and failure counts per MX host — and, when something failed, a named reason. That list is the reason to publish it:

Note what that buys you: not “TLS is broken” but which of your MX hosts is broken, and how — the diagnosis, not just the symptom.

It reports; it does not enforce

TLS-RPT changes nothing about how mail is delivered. MTA-STS is the half that makes a sending server refuse to fall back to an unencrypted connection; TLS-RPT is how you find out it is doing so. Publish TLS-RPT before moving MTA-STS from testing to enforce, because after that switch a certificate problem stops mail rather than degrading it, and the reports are your only warning.

No authorization record needed

Pointing a DMARC rua= at a mailbox on another domain requires that domain to publish a _report._dmarc record authorising it — see reports won’t arrive if rua= is wrong. TLS-RPT has no equivalent: you can send TLS reports to any destination without a second record. Convenient, and worth knowing, because the two look so similar that people assume the DMARC rule applies here too and go hunting for a record that was never required.

Use a different mailbox from your DMARC reports

TLS reports arrive as mail with an attachment, exactly like aggregate reports, so the obvious move is to point both at one inbox. Don’t. A TLS-RPT report is not a DMARC aggregate report, so anything that reads that mailbox for DMARC data — DMARC Analyzer included — counts it as a parse failure. The count stops meaning “something is wrong” and starts meaning “TLS reports arrived again”, which is how a real problem hides. One mailbox per report type keeps both signals readable.

TLS-RPT and MTA-STS are the transport-security story you start after DMARC reaches enforcement — the two solve different problems, and DMARC is the one that stops people sending as you. If you are not there yet, start with monitoring to enforcement.