TLS-RPT Checker
Check whether a domain receives reports on TLS delivery failures.
TLS-RPT is the feedback channel for SMTP transport security. Sending servers that fail to establish the TLS session your MTA-STS or DANE policy requires collect those failures and send you a daily aggregate report. It is a single TXT record and it exists because enforcement without visibility is dangerous.
The failure mode it prevents is specific and expensive. Switch MTA-STS to enforce with an mx list that misses one of your mail hosts, and senders start refusing delivery to it. Without TLS-RPT nothing tells you — the mail simply does not arrive, the sender sees a temporary failure, and you find out when someone mentions they never got a reply. With TLS-RPT, the reports name the host and the failure reason.
Reports are JSON, compressed, and delivered daily to whatever the rua tag names. A mailbox works, though the volume argues for a parsing service or a dedicated address. The point is to have somewhere the reports land before you turn enforcement on, not after.
What this tool does
Record lookup
Reads the TXT record at _smtp._tls and validates the version tag and every reporting destination.
Destination validation
Each rua must be a mailto: address or an https: URL. An invalid destination means reports are silently discarded.
Plain HTTP flagged
An http: destination sends failure reports unencrypted — leaking exactly the delivery details the reports exist to protect.
The companion to MTA-STS
Enforcement without reporting means a broken policy rejects real mail with nothing to tell you.
Frequently asked questions
What is TLS-RPT?
SMTP TLS Reporting, defined in RFC 8460. A TXT record at _smtp._tls.yourdomain names an address that receives daily aggregate reports from sending servers about TLS negotiation and policy validation failures when delivering to your domain.
Do I need it if I have MTA-STS?
Effectively yes. MTA-STS in enforce mode makes senders refuse delivery when TLS cannot be established, and TLS-RPT is the only thing that tells you it is happening. Enforcing without reporting means a policy mistake becomes silent mail loss.
What do the reports contain?
A JSON summary per sending organisation per day: how many sessions succeeded, how many failed, the failure types, and the receiving MX hosts involved. No message content and no recipient addresses — it is delivery telemetry, not mail.
Can I send reports to a normal mailbox?
Yes, and for a small domain that is fine. The reports are compressed JSON attachments arriving daily from each major sender. At scale, point rua at a service or an address feeding a parser, because reading them by hand stops being practical quickly.
Does TLS-RPT slow down or affect mail delivery?
No. It changes nothing about how mail is delivered. Reporting happens out of band, after the fact, from the sending organisation to your reporting address.
Why does the record need to be at _smtp._tls?
Because the specification says so, and senders look there and nowhere else. It follows the same underscore-prefixed convention as _dmarc and _mta-sts, which keeps policy records from colliding with ordinary TXT records on the domain itself.
Monitor it, don't just check it
One-off checks catch what is broken today. CertNotify watches your certificates, domains, DNS and code continuously and tells you before something breaks.