TLS-RPT Checker
Enter any domain to check its TLS-RPT configuration. We validate the DNS record, inspect report destinations, and confirm that sending servers know where to send encrypted delivery failure reports.
Understanding Your TLS-RPT Check
Here's what each result means and what to do next.
TLS-RPT Pass
Your TLS reporting is properly configured
A passing result means your TLS-RPT record is published correctly and sending servers know where to deliver TLS failure reports. To get the most value from TLS-RPT, make sure MTA-STS is also configured. Without MTA-STS, most senders will not generate reports because they silently fall back to plaintext instead of enforcing TLS.
- Valid TLS-RPT record found
- Report destination is configured
- Record syntax is correct
- Report URI is reachable
TLS-RPT Warning
Your record works but has issues worth addressing
A warning means your TLS-RPT record exists and is syntactically valid, but there are issues that may limit the reports you receive or how useful they are. The most common warning is having TLS-RPT configured without MTA-STS, which means most senders will not generate failure reports. Other warnings include unreachable report destinations or using only email delivery without an HTTPS endpoint for automated processing.
- Report destination may not be receiving reports
- MTA-STS is not configured (limits report generation)
- Using only email delivery (no HTTPS endpoint)
- Record has non-critical syntax issues
TLS-RPT Fail
Your TLS reporting is not configured
A failing result means sending servers have nowhere to report TLS connection problems with your domain. Without TLS-RPT, you have no visibility into whether encrypted delivery is working or failing. The most common causes are a missing DNS record, a record with syntax errors, or a missing report destination URI. Publishing a TLS-RPT record takes minutes and immediately gives you visibility into your encrypted delivery.
- No TLS-RPT record found
- Record has syntax errors
- No report destination specified
- Version tag is missing or incorrect
Common TLS-RPT Problems and How to Fix Them
These are the TLS-RPT problems we see most often. If your check flagged any of these, here's what they mean and how to fix them.
No TLS-RPT Record Found
No visibility into encrypted delivery
Without a TLS-RPT record, sending servers that encounter TLS connection problems with your mail servers have nowhere to report them. You will not know when encrypted delivery fails, when certificates expire, or when configuration changes break TLS. Publishing a record is straightforward: add a TXT record at _smtp._tls.yourdomain.com with your version and reporting URI.
TLS-RPT Without MTA-STS
Reports without enforcement
TLS-RPT tells senders where to send reports, but most senders only generate reports when a policy (MTA-STS or DANE) requires encrypted delivery. Without MTA-STS, a sender that encounters a TLS error will silently fall back to plaintext and deliver the email unencrypted. No failure means no report. To get meaningful TLS-RPT data, you need MTA-STS telling senders that TLS is required.
Unreachable Report Destination
Reports sent but never received
Your TLS-RPT record points to a report destination, but that destination may not be receiving reports. This happens when the email address has a full mailbox, the HTTPS endpoint returns errors, or the domain in the mailto: address has its own delivery issues. The result is the same: senders generate reports but you never see them. Check that your report destination is active and capable of receiving JSON-formatted TLS reports.
Record Syntax Errors
Small errors break the whole record
TLS-RPT records have a simple format, but even small syntax errors can make them unparseable. The record must start with v=TLSRPTv1 and include at least one rua= directive with a valid mailto: or https: URI. Common mistakes include missing semicolons, spaces in the wrong places, or using rua without the required URI scheme prefix. Most DNS providers also have character limits for TXT records, which can truncate long URIs.
Why TLS-RPT Matters for Your Business
Encrypted Delivery Fails Silently
Certificate Problems Go Undetected
MTA-STS Becomes Guesswork Without It
Compliance Requires Visibility
Check Your Full Email Authentication with iO™ DMARC
SPF is one piece of the puzzle. Use these tools to check the rest of your email authentication stack.
SPF Checker
Validate your SPF record and confirm which servers are authorized to send on your behalf. SPF handles sender authorization, TLS-RPT monitors the secure delivery path.
DKIM Checker
Verify your DKIM signature to make sure outgoing emails are cryptographically signed. DKIM ensures content integrity, TLS-RPT ensures connection security is reported.
DMARC Checker
Check your DMARC policy and alignment. DMARC aggregate reports cover authentication, TLS-RPT covers encryption. Together they give you full visibility.
BIMI Checker
See if your domain qualifies to display your brand logo in supported inboxes. BIMI is the visible payoff of a fully authenticated, securely delivered email stack.
MTA-STS Checker
Check whether your domain enforces encrypted email delivery. MTA-STS is the enforcement policy, TLS-RPT is the reporting layer that tells you when it fails.
Email Authentication Audit
Get a complete picture of your SPF, DKIM, DMARC, BIMI, and MTA-STS configuration in one report. See what’s working, what’s broken, and what to fix first.
Ready to secure your email domain?
TLS-RPT shows you where delivery security breaks. iO™ DMARC monitors that and every other layer for you.
Learn About TLS-RPT
Understanding TLS-RPT Reports
Why TLS-RPT Needs MTA-STS
Managed TLS Reporting
Ready to Monitor Your Encrypted Email Delivery?
Found issues with your TLS-RPT configuration? Or just want someone to turn raw JSON reports into actionable alerts? Let's talk.
Want Eyes on Every Encrypted Connection?
iO™ DMARC configures TLS-RPT on your domain, parses the incoming reports, and surfaces the TLS handshake failures hiding in your mail stream, so broken encryption does not quietly cost you mail.
See iO™ DMARC in Action