TLS reporting

TLS-RPT is a TXT record at _smtp._tls.<domain> asking sending servers to report back when TLS negotiation for mail to your domain fails. The report is a daily aggregate in JSON, one per sending organisation, delivered to whatever the record's rua= tag names.

It is reported as information because it protects nothing on its own. Its value is entirely in what it tells you about the things that do — and those fail silently by design. A sender that cannot fetch your MTA-STS policy falls back to opportunistic TLS without comment; a sender enforcing a policy that no longer matches your MX set refuses delivery, and the message bounces at their end rather than yours.

That is the gap TLS-RPT fills. Without it, the first report of a broken MTA-STS deployment is a person telling you their mail bounced — which arrives late, and through a channel that may itself be the mail you broke.

Publish it before you turn MTA-STS on, not after. v=TLSRPTv1; rua=mailto:tls-reports@example.com is the whole record, and a few quiet weeks of reports before moving a policy to enforce mode is what makes that move safe.

Send the reports somewhere that will be read. They are machine-generated JSON and there are only a handful a day, so a mailbox works; a processing service works better if you would rather see a summary than a directory of attachments.

If you have neither an MTA-STS policy nor DANE records, this alone gains you very little — senders have nothing to fail at. Add it as the first step of deploying one of those rather than as a standalone item.