TLS-RPT checker
Checks whether your domain publishes a TLS-RPT record, so servers that deliver mail to you can report when TLS to your mail servers fails.
Next
What the TLS-RPT checker does
TLS-RPT, from RFC 8460, is a TXT record at _smtp._tls.yourdomain.com. It tells sending servers where to report problems they hit while setting up TLS to deliver mail to your domain. The record looks like v=TLSRPTv1; rua=mailto:[email protected].
The checker fetches the record, validates the version and the rua addresses, which can be mailto: or https: URIs, and flags a second record, which makes senders ignore both. A record that does not start with v=TLSRPTv1 does not count, so it shows as missing.
What the reports contain
Senders that support TLS-RPT, Google among them, send a JSON report once a day, usually gzipped. It covers a date range and lists, per policy, how many sessions succeeded and failed and why.
Failure types include certificate-expired, certificate-host-mismatch, certificate-not-trusted, starttls-not-supported and sts-policy-fetch-error. Each one points at a specific fix on your MX hosts or your MTA-STS setup.
How to set it up
Pick an address that someone or something reads, or a reporting service. Publish the TXT record and check it here.
If you're adding MTA-STS, publish TLS-RPT first and run MTA-STS in testing mode while reports come in. Switch to enforce only when the reports show no failures.
Why it matters for cold email
Like MTA-STS, TLS-RPT is about mail coming in to your domain, so it doesn't change where your cold email lands.
It matters for replies. If you enforce MTA-STS on a domain that receives replies, a TLS problem on your MX means senders refuse to deliver, and TLS-RPT is how you find out before prospects tell you their replies bounced.