Free TLS-RPT Checker
Enter any domain below to check whether a TLS-RPT (SMTP TLS Reporting) record is published. We verify the DNS TXT record at _smtp._tls and parse the reporting destinations.
New to TLS-RPT? Read how MTA-STS and TLS-RPT work on the MTA-STS Checker.
On 16 October 2026, 33 of the 192 UK MSPs in ShieldMarc's quarterly audit (17%) had a valid TLS-RPT record.
What is TLS-RPT?
TLS-RPT (RFC 8460) allows domain owners to receive reports about TLS negotiation failures from sending mail servers. When a sender tries to deliver email to your domain and encounters a TLS problem (expired certificate, wrong hostname, failed MTA-STS validation), they can send a structured JSON report to the address specified in your TLS-RPT record.
Why should you enable TLS-RPT?
- Visibility: Without TLS-RPT, you have no way of knowing when senders fail to establish a secure connection to your mail servers.
- MTA-STS Companion: TLS-RPT is designed to work alongside MTA-STS. If you enforce TLS via MTA-STS, TLS-RPT tells you when enforcement causes delivery failures.
- Certificate Monitoring: TLS-RPT reports can alert you to certificate issues on your MX servers before they cause widespread delivery problems.
- Simple to Deploy: A single DNS TXT record is all you need. No server-side changes required.
How this tool works
We query the DNS TXT record at _smtp._tls.example.com and parse the v=TLSRPTv1 record to extract the reporting destinations (rua). Results are instant and completely free.
How to set up TLS-RPT
Setting up TLS-RPT requires a single DNS TXT record. Create a record at _smtp._tls.example.com with the value:
Replace the email address with wherever you want to receive reports. You can also use an HTTPS endpoint instead of mailto: if you want to process reports programmatically. Reports are sent as JSON (RFC 8460) and typically arrive daily.
What do TLS-RPT reports contain?
- Policy type: Whether the failure was against MTA-STS, DANE, or no policy.
- Failure details: The specific TLS error (certificate expired, hostname mismatch, handshake failure, etc.).
- Sending MTA: The IP address and hostname of the server that attempted delivery.
- Receiving MX: Which of your MX servers was involved in the failure.
- Count: How many sessions experienced this failure during the reporting period.
Need automated monitoring?
This free tool is great for one-off checks. If you need continuous monitoring across all your domains, start a 30-day free trial with no card needed.
Want the full picture?
Our Security Grade checks TLS-RPT alongside MTA-STS, DMARC, SPF, DNSSEC, CAA, SSL, and domain registration in one scan.
Frequently asked questions
Do I need MTA-STS to use TLS-RPT?
No, TLS-RPT works independently. However, they are designed as companions. TLS-RPT without MTA-STS will still report on opportunistic TLS failures, but adding MTA-STS gives you enforcement and makes the reports easier to act on.
How often are TLS-RPT reports sent?
RFC 8460 recommends daily reporting. Most major email providers (Google, Microsoft, Yahoo) send reports once every 24 hours, though the exact timing varies.
Will TLS-RPT reports flood my inbox?
For most domains, you will receive one report per sending provider per day. High-volume domains may receive more. Consider using a dedicated mailbox or an HTTPS reporting endpoint to handle volume.
Does TLS-RPT affect my Security Grade?
Yes. TLS-RPT is a check in the Security Grade framework. Passing it counts towards a strong Security Grade.