MTA-STS (RFC 8461) tells sending servers to require TLS when they deliver mail to you. It's a good control with one blind spot: when a sender can't establish TLS, you don't hear about it. TLS-RPT closes that gap, and it costs nothing to run: it's one DNS record, and the senders do the reporting.
What TLS-RPT is
TLS-RPT (RFC 8460) is a TXT record at _smtp._tls.yourdomain:
v=TLSRPTv1; rua=mailto:tlsrpt@yourdomainSending servers that support it send you JSON reports listing:
the policy they evaluated: MTA-STS, DANE, or none
the failure type: an expired certificate, a hostname mismatch, STARTTLS not supported
how many sessions failed, per sending server
What the reports catch
The common ones: a certificate that expired over a weekend, an MX hostname that no longer matches the certificate after a migration, or an MTA-STS policy file that's no longer served. Each one shows up in the reports with the reason, instead of as mail that quietly didn't arrive.
TLS-RPT isn't tied to MTA-STS. It also covers DANE, and sessions where no policy was found at all.
One gotcha: the rua address can be a mailto: or an https: URL, and reports arrive gzip-compressed. A person's inbox is the wrong place for them; point the address at something that parses them.
The order I'd use
Publish TLS-RPT.
Publish MTA-STS in testing mode. Senders report failures but still deliver.
Read the reports for a couple of weeks and fix what they show.
Switch MTA-STS to enforce.
What to do: check whether your domain publishes TLS-RPT. Look up the TXT record at _smtp._tls.yourdomain; if nothing comes back, you have no TLS reporting. If you already enforce MTA-STS without it, add it today.
How TLS-RPT works, in more detail: https://dmarcguard.io/learn/tls-rpt/?utm_source=buymeacoffee&utm_medium=social&utm_campaign=social-2026-w45&utm_content=1108-eu-tlsrpt