TLS-RPT Checker
Look up and validate a domain's TLS-RPT record at _smtp._tls so senders can report failed TLS connections to your mail servers, checked against RFC 8460 syntax.
About TLS-RPT Checker
The TLS-RPT Checker reads the _smtp._tls TXT record on a domain and tells you whether senders have anywhere to send their TLS failure reports. It confirms the record declares v=TLSRPTv1, extracts every rua destination, and checks that each one is a usable target. Without this record you receive nothing when a sender fails to negotiate TLS with your mail servers, which means a downgrade attempt, an expired MX certificate or a broken MTA-STS policy produces no signal at all on your side.
RFC 8460 defines a daily reporting channel: a sending domain aggregates its TLS sessions with your MX hosts and sends a JSON summary of successful and failed connections, with failure types such as starttls-not-supported, certificate-expired, certificate-host-mismatch or validation-failure. It is to transport security what DMARC aggregate reporting is to SPF and DKIM. The failure mode it exposes is quiet and expensive: an MTA-STS policy in enforce mode, or a stale TLSA record, can make large senders stop delivering to you, and without reports the first evidence is a user complaint.
The lookup is a TXT query through our sovereign European resolver, followed by strict syntax checks. The version must be exactly TLSRPTv1, there must be at least one rua destination, and every destination must carry a mailto: or https: scheme, because a bare email address, the most common mistake in this record, is invalid and silently yields no reports. Findings are graded by severity and the raw record is shown in full, so you can compare what is published with what you intended to publish.
How to use it
- 1Enter the mail domain you want to check and select Check TLS-RPT.
- 2Read the published or not published badge.
- 3Inspect the raw record and confirm it begins with v=TLSRPTv1.
- 4Check the report destinations list: every rua entry must start with mailto: or https:.
- 5Resolve any errors, publish the corrected TXT record and re-run the check.
Common use cases
- -Confirming a mailbox or reporting service really receives TLS reports before you move MTA-STS to enforce.
- -Troubleshooting silent delivery failures from large senders by enabling the only feedback channel that reports them.
- -Auditing a domain for the full set of mail security records: SPF, DKIM, DMARC, MTA-STS, DANE and TLS-RPT.
- -Verifying an rua address survived a mail provider migration rather than pointing at a mailbox nobody reads.
- -Reviewing a supplier's or an acquired domain's transport security posture during due diligence.
Frequently asked questions
- What is a TLS-RPT record?
- A TLS-RPT record is a TXT record at _smtp._tls.<domain> naming where sending mail servers should deliver their daily TLS reports. It looks like v=TLSRPTv1; rua=mailto:tlsrpt@example.eu. Defined in RFC 8460, it is the feedback channel for SMTP transport security: it tells you when senders could not negotiate TLS with your MX hosts, or could not validate the certificates those hosts presented.
- What is the difference between TLS-RPT and DMARC reports?
- DMARC aggregate reports describe message authentication: which sources sent mail as your domain, and how SPF and DKIM evaluated. TLS-RPT reports describe the connection: whether senders could establish authenticated TLS to your MX hosts, and why they failed when they could not. They cover different layers of the same delivery path, so publishing both gives you the complete picture.
- Can TLS-RPT reports be sent to an HTTPS endpoint?
- Yes. RFC 8460 allows an rua destination with either a mailto: or an https: scheme, and reports are then POSTed as gzipped JSON to that URL. Most operators choose mailto: because it needs no infrastructure, while https: suits anyone parsing reports at scale. A destination with neither scheme, such as a bare email address, is invalid and will receive nothing.
- Do I need MTA-STS or DANE before publishing TLS-RPT?
- No, and publishing TLS-RPT first is the sensible order. Reports arrive from senders whether or not you enforce a policy, so you learn how often TLS to your MX hosts already fails, and why. That evidence is what makes it safe to move an MTA-STS policy from testing to enforce, or to deploy TLSA records, without quietly losing mail.