Free TLS-RPT Checker Tool

TLS-RPTChecker

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.

What Your Results Mean

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

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.

  • No TXT record at _smtp._tls.yourdomain.com
  • Sending servers have nowhere to report TLS failures
  • Fix: publish a TLS-RPT TXT record with your report destination

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.

  • Without MTA-STS, most senders silently fall back to plaintext
  • Fix: configure MTA-STS to enforce encrypted delivery

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.

  • The mailto: or https: destination is not accepting reports
  • Reports are being generated but you are not receiving them
  • Fix: verify the destination mailbox or endpoint is active

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.

  • Missing version tag (v=TLSRPTv1)
  • Malformed rua= URI (must be mailto: or https:)
  • Fix: verify record matches the v=TLSRPTv1; rua=mailto:... format

Why TLS-RPT Matters for Your Business

TLS-RPT is the reporting layer for encrypted email delivery. Without it, TLS failures are invisible and you have no way to verify that your encrypted connections are working.

Encrypted Delivery Fails Silently

When a sending server cannot establish a TLS connection with your mail servers, the failure is invisible to you. Without TLS-RPT, you have no way to know that emails are being delivered in plaintext or not delivered at all. TLS-RPT gives you the reports you need to catch these failures.

Certificate Problems Go Undetected

Expired, misconfigured, or mismatched TLS certificates on your mail servers break encrypted delivery. Without TLS-RPT, you only discover certificate problems when someone reports a missing email or a security audit flags the issue. TLS reports surface these problems the day they happen.

MTA-STS Becomes Guesswork Without It

If you have MTA-STS configured, TLS-RPT is essential for knowing whether it is working. Without TLS reports, you cannot see how many connections are succeeding, how many are failing, or why. You are enforcing a policy with no visibility into its effects.

Compliance Requires Visibility

Security frameworks and compliance audits increasingly expect organizations to demonstrate encrypted email delivery. TLS-RPT provides the evidence: daily reports from major senders showing that your TLS connections are working and that failures are being tracked.