TLS-RPT Record Checker
Check whether a domain has a TLS-RPT record, verify the reporting addresses, and see if MTA-STS is also deployed.
Try an example: google.com · paypal.com · fastmail.com · mailbox.org
Validation results
How this TLS-RPT checker works
TLS-RPT (RFC 8460) is the feedback channel for SMTP TLS. When a sender refuses to deliver because your MTA-STS policy went stale, your certificate expired, or a middlebox stripped STARTTLS, TLS-RPT is how you hear about it. Without it, mail goes quiet and you guess at the cause. Type a domain above and the tool resolves the TXT record at _smtp._tls.<domain>, checks the version tag, parses every rua= destination, and confirms each one actually parses as a deliverable URI.
A typical TLS-RPT record looks like this:
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"What goes in a TLS-RPT report?
Reports are aggregate, not live. Google, Microsoft, Yahoo and Comcast batch every TLS failure they saw talking to your MX hosts over a 24-hour window into one JSON document, then deliver it once a day to every destination you publish. Each entry records the sending IP, the policy that was in force, the failure type (starttls-not-supported, certificate-expired, certificate-name-mismatch, certificate-not-trusted, and the rest of the IANA list), and the session count that hit it. That's enough to tell apart a one-off rogue relay from a real MX problem.
Mailbox or a processor?
The spec allows two destination types. mailto:<address> sends the JSON as an email attachment, which is fine on a quiet domain. https://<endpoint> POSTs application/tlsrpt+gzip straight to a collector. You can list several destinations separated by commas, and every well-behaved sender tries them all.
Our take: point at a third-party processor (URIports, Red Sift, Postmark, Valimail, dmarcian) once volume picks up. Parsing daily JSON by hand stops being reasonable somewhere past a few hundred messages a day. The checker labels each destination so you can see whether yours is a mailbox or a processor.
TLS-RPT needs something to report on
TLS-RPT is the reporting layer. It only produces output if there is a TLS enforcement policy for senders to fail against. That means an MTA-STS policy in testing or enforce mode, a DANE TLSA record on each MX, or both. Publish TLS-RPT without either and the record resolves correctly but no reports ever arrive. The checker flags which of the two prerequisites is missing.
What to do: if MTA-STS and DANE are both off, start with MTA-STS in testing mode. That's the policy Gmail and Microsoft 365 actually enforce, and testing mode lets you watch a week of reports before switching to enforce. DANE picks up the Postfix and Exim side that validates DNSSEC. Run both if you can. Either one on its own still gives TLS-RPT something to report on.
Parse traps the checker catches
The record is short, so most TLS-RPT bugs are copy-paste accidents. Smart quotes from a Word document, a stray semicolon left over from a DMARC template, a mailto: with no domain after the @, or a version tag misspelled as TLSRPT1. Receivers won't warn you. They skip the malformed destination and reports go quiet. The checker walks the tags one at a time and shows which one is broken.
Where to go next
TLS-RPT is half of a pair. Pair it with the MTA-STS checker for the enforced-by-Google side, and the DANE checker for the enforced-by-DNSSEC side. For the underlying TXT record format and how these tags sit alongside SPF, DKIM and DMARC, see the DNS record types reference.
Frequently Asked Questions
Common questions about TLS-RPT and SMTP transport encryption reporting.
What's actually inside an aggregate report?
A JSON file delivered once a day, either as a mail attachment or POSTed to your HTTPS endpoint. It summarises every TLS attempt against your MX hosts in the previous 24 hours: total successful sessions, plus a per-failure-type count of anything that broke (expired cert, name mismatch, missing STARTTLS, untrusted chain). Each failure block carries the sending IP, so you can tell apart a misconfigured customer's relay from a real problem on your MX.
The first report after you publish is usually quiet. The interesting ones show up the day your certificate auto-renew misses, or the day an upstream replaces the MX without telling you.
Why isn't anything arriving?
Three usual suspects. First, no enforcement policy: TLS-RPT only reports on failures against MTA-STS or DANE, and if neither is published there is nothing for receivers to fail against. Second, malformed rua=: smart quotes, missing schemes, or a stray semicolon will get the destination silently skipped. Third, low volume: aggregate reports are once a day per sender, and a quiet domain may only see weekly traffic from Google or Microsoft.
If the checker grades the record A or B and a week passes with nothing, confirm there is mail flowing in and check the MTA-STS or DANE side is actually enforcing.
Should I use mailto: or https:?
Start with mailto:. It's the option every receiver supports, and a JSON-per-day to a shared inbox is easy to ignore until something breaks. Move to https: when you outsource processing to a TLS-RPT vendor, because their collectors prefer the direct POST.
You can publish both, separated by a comma. Senders are meant to try every destination, so dual-publishing buys you a fallback if one endpoint fails. The checker validates each destination independently and tells you which one parsed and which one didn't.