TLS-RPT Explained: How to Monitor TLS Connection Failures for Your Domain

MTA-STS tells receiving mail servers that your domain requires TLS for inbound delivery. But MTA-STS alone doesn't tell you whether those TLS connections are actually succeeding — or failing silently for certain senders. That visibility gap is exactly what TLS-RPT fills.

TLS Reporting (TLS-RPT), defined in RFC 8460, is a mechanism that lets you receive diagnostic reports about TLS connection failures when other mail servers try to deliver to your domain. If a sending server can't establish a TLS connection, TLS-RPT ensures you find out rather than those messages failing with no signal reaching you at all.

How TLS-RPT Works

The mechanism is similar to DMARC aggregate reporting. You publish a single DNS TXT record for your domain that tells sending mail servers where to send TLS connection reports. Participating senders then aggregate connection data for your domain daily and deliver a JSON report to the address you specify.

The DNS record takes this form:

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

The rua field specifies the reporting URI — an email address or HTTPS endpoint. You can list multiple URIs separated by commas. Reports are sent once per day and cover the prior 24-hour window of delivery attempts to your domain.

What TLS-RPT Reports Contain

Each report is a JSON document that includes:

• The sending organization submitting the report
• The date range the report covers
• For each of your MX hosts: the total number of delivery sessions attempted and how many succeeded
• For failures: the failure type, specific error code, and which policy was being applied (MTA-STS or DANE)

A report with zero failures means all TLS connections for that period succeeded as expected. Failures appear with descriptive error codes — expired TLS certificate, unsupported TLS version, certificate hostname mismatch, and so on — that tell you specifically what went wrong and on which server.

TLS-RPT and MTA-STS: Why They Work Together

TLS-RPT is designed to complement MTA-STS. When you deploy MTA-STS in enforce mode, you're instructing senders that they must successfully establish a TLS connection or refuse delivery. That's a strong guarantee of encryption in transit, but it also introduces a risk: misconfigured or expired certificates will cause legitimate email to be rejected by compliant senders.

Without TLS-RPT, these rejections are invisible. A sender might be failing to deliver to your domain because of an expired certificate you forgot to renew, and the only signal you'd see is users not receiving messages they expected. TLS-RPT surfaces those failures directly so you can identify and fix the problem before it affects meaningful mail volume.

If you're considering upgrading an MTA-STS policy from testing mode to enforce mode, TLS-RPT data is the right input for that decision. If reports show consistent TLS failures from specific senders, resolve those issues before enabling enforcement — otherwise you'll start rejecting real mail on day one.

TLS-RPT and DANE

DANE (DNS-Based Authentication of Named Entities) is an alternative to MTA-STS that uses TLSA records in DNSSEC-signed DNS zones to specify which certificates your mail server should present. TLS-RPT covers DANE policy failures in addition to MTA-STS — the report will indicate which policy type was being applied when a failure occurred. For a broader look at how DANE and STARTTLS relate, see our guide to STARTTLS and DANE explained.

Setting Up TLS-RPT

Deployment requires only the single DNS record above. The main decision is where to route reports.

Email inbox

The simplest option: specify a mailto: URI and have reports delivered to an email address. The raw JSON isn't easily human-readable, but you can create email filters to flag any report containing non-zero failure counts for follow-up review. This is adequate for most deployments.

DMARC or TLS reporting service

Several reporting services that handle DMARC aggregate data also parse TLS-RPT reports and present them in a visual interface. If you're already using one of these services for DMARC monitoring, check whether TLS-RPT is included. Many offer it as part of the same plan, which means you get a readable dashboard without building anything custom.

HTTPS endpoint

For organizations that want programmatic access to report data, you can specify an https: URI. The reporting server will POST the JSON directly to that endpoint, giving you full control over parsing, alerting thresholds, and long-term storage.

What to Monitor in Your Reports

Once TLS-RPT reports are flowing, the key things to watch:

• Certificate expiry errors: If your TLS certificate expires, reports will show validation failures from every compliant sender. Run certificate renewal automation and treat TLS-RPT as a secondary safety net to catch anything the automation misses.
• Sudden increases in failure rate: A jump in failures from a sender that was previously succeeding often signals a configuration change — either on your end or theirs. Investigate promptly rather than waiting for user reports.
• Failures concentrated on one MX host: If failures are hitting one server but not others, the problem is likely specific to that server's certificate, TLS configuration, or hostname. Compare the failing host's config against your working servers.

TLS-RPT is one of those mechanisms that takes fifteen minutes to deploy and pays for itself the first time it surfaces a certificate problem before your users notice mail is bouncing. Deploy it alongside MTA-STS as standard practice.

For help with your domain's full DNS and security configuration, including MTA-STS policy files and DMARC setup, visit MailDog's DNS security tools. Our documentation covers the complete setup process from DNS record to monitoring workflow.