What Is TLS-RPT?
TL;DR
TLS-RPT, or SMTP TLS Reporting, is a standard that asks sending servers to send you a daily report of the TLS connections they made to your mail hosts, including the ones that failed. It is the feedback channel that makes an MTA-STS rollout safe to enforce.
How do you publish a TLS-RPT record?
One DNS TXT record, published at _smtp._tls.yourdomain.com. The value carries the version and a destination: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com. The rua field also accepts an https URI, and several comma separated destinations.
There is nothing else to configure. Reporting is entirely on the sending side, so the record is a request rather than a switch, and any sending platform that implements the standard starts posting reports to the address you named.
What is in a TLS-RPT report?
A JSON document, normally gzip compressed, covering a full day from 00:00 to 24:00 UTC. It counts the successful sessions to each of your hosts and then itemises the failures by type, so you see the reason rather than only a number.
The failure types are the useful part. starttls-not-supported, certificate-expired, certificate-host-mismatch and the MTA-STS policy failures each point at a different fix, and every one of them is invisible to you otherwise, because the failure happened on a server you do not run.
Why publish TLS-RPT before enforcing MTA-STS?
Because MTA-STS in enforce mode refuses delivery, and you cannot see that from your own logs. The message never arrives, so nothing in your systems records that it was attempted.
TLS-RPT closes that blind spot. Publish both records, leave the MTA-STS policy in testing mode, and the reports tell you which senders would have been blocked before you make the switch.
Frequently asked questions
No, they are independent records. TLS-RPT on its own still reports certificate and STARTTLS problems on connections into your domain, which is useful diagnostic data whether or not you ever publish a policy.