Free TLS-RPT monitoring and report analyzer

Why monitor TLS-RPT reports?

TLS-RPT monitoring surfaces the SMTP encryption failures your server never logs. It is the only standardized channel (RFC 8460) where sending servers report back what broke at the transport layer. Without it, an email refused over TLS leaves no trace on the receiving side. Your reputation slips. Your users wait for nothing, because they never knew a message existed.

Three failures show up in almost every report. An expired certificate on the MX breaks the encrypted handshake, and strict senders reject the message rather than fall back to plaintext. An MTA-STS policy pointing at a vanished MX produces the same outcome: connection refused, mail never delivered. The worst is the STARTTLS downgrade, where a network appliance strips the STARTTLS advertisement out of the SMTP dialogue and the mail crosses the public internet in the clear. Nobody notices. The TLS-RPT report does.

How to set up TLS-RPT monitoring in 3 steps

Step 1: Add your domain

Sign in and register the domain you want to monitor. CaptainDNS generates a unique HTTPS reporting endpoint and the corresponding TLS-RPT DNS record.

Step 2: Verify domain ownership

Add the verification TXT record to your DNS. Validation happens automatically once the record is detected.

Step 3: Publish the TLS-RPT record

Add the provided _smtp._tls TXT record to your DNS. Sending servers will start delivering TLS failure reports to your CaptainDNS endpoint.

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) is a standard defined by RFC 8460 that reports TLS negotiation failures back to the receiving domain. Sending servers flag every encrypted connection that fails. A single DNS record triggers them.

Example DNS record:

_smtp._tls.captaindns.com.  IN  TXT  "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"

The _smtp._tls record tells senders where to deliver JSON failure reports. Any TLS error connecting to your domain triggers a report to the URL specified in rua=.

What does a TLS-RPT report contain?

A TLS-RPT report is a JSON document that aggregates 24 hours of TLS connection attempts from a single sender to your domain. It counts the sessions that succeeded and the ones that failed, and breaks each failure down by type. CaptainDNS decodes that JSON and shows it in plain language.

TLS-RPT failure types (RFC 8460)

TLS-RPT vs DMARC

Both protocols are complementary. Deploy DMARC monitoring alongside TLS-RPT for full email security visibility.

Who sends TLS-RPT reports?

Major providers emit reports the moment they attempt a TLS connection to your domain. Between them, Google and Microsoft carry the majority of inbound mail for a typical business domain. If you receive mail from either one, a published TLS-RPT record already gives you useful coverage.

• Google (Gmail, Workspace): Sends daily aggregate reports covering all connection attempts
• Microsoft (Outlook, Exchange Online): Reports TLS negotiation failures for Microsoft 365 tenants
• Yahoo: Delivers TLS-RPT data for Yahoo Mail and AOL infrastructure
• Apple (iCloud Mail): Reports TLS failures for iCloud Mail delivery
• Comcast: One of the first ISPs to implement TLS-RPT reporting

Publish a TLS-RPT record and these providers start reporting automatically. No registration with each provider is needed.

Real-world use cases

Most TLS incidents resolve in an hour when you can see them, and drag on for weeks when you can't. Here are two real outages that TLS-RPT monitoring brought to light.

Incident 1: Undetected expired certificate

Symptom: Google and Microsoft report certificate-expired failures in their TLS-RPT reports.

Diagnosis: The CaptainDNS dashboard shows a failure spike over the last 24 hours. All errors point to an expired Let's Encrypt certificate on the primary MX. Strict senders silently dropped messages instead of delivering over a broken TLS session. Users stopped receiving emails from these providers. No error on their end.

Action: Renew the TLS certificate on the mail server. Subsequent reports confirm encrypted delivery has resumed.

Incident 2: Out-of-sync MTA-STS policy

Symptom: Reports show sts-policy-invalid failures despite a published MTA-STS policy.

Diagnosis: The MTA-STS policy references an MX server removed during a migration. Senders in enforce mode reject the connection. The email never arrives. No bounce reaches the sender.

Action: Update the MTA-STS policy to list current MX servers. Increment the policy id. Next reports confirm the fix.

In both cases the trigger is the same: a report read at the right moment. Add your domain to CaptainDNS, publish the _smtp._tls record, and these signals land in your dashboard with no server to run.

FAQ - Frequently asked questions

Q: What is a TLS-RPT record?

A: A TLS-RPT record is a DNS TXT entry placed at _smtp._tls.yourdomain.com. It contains a rua= directive that tells sending servers where to deliver TLS failure reports (RFC 8460). Without this record, no server reports its connection errors to your domain.

Q: Is CaptainDNS TLS-RPT monitoring free?

A: Yes, the TLS-RPT monitoring service is completely free. We believe every domain should be able to monitor its TLS security without technical barriers.

Q: How do I configure my domain to send reports here?

A: Add a TXT record at _smtp._tls.yourdomain.com with the value v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{your-token}. The exact record is provided when you add your domain.

Q: What report formats are supported?

A: We accept TLS-RPT reports in JSON format as defined by RFC 8460, compressed (gzip) or uncompressed. Reports are accepted via HTTPS POST.

Q: How does domain verification work?

A: You add a verification TXT record provided by CaptainDNS to your DNS. Once detected, domain ownership is confirmed and report monitoring is activated.

Q: What are the risks of running without TLS-RPT?

A: Without TLS-RPT, you are blind. TLS failures happen silently: no bounce, no notification, no log you can access. Days or weeks can pass before you realize emails from major providers are being dropped or delivered unencrypted.

Q: Do I need MTA-STS to use TLS-RPT?

A: No, TLS-RPT works independently. MTA-STS enforces an encryption policy. TLS-RPT tells you when senders cannot comply with it. Deploy both for full coverage.

Q: How often do reports arrive?

A: Reports are analyzed and available in your dashboard within seconds of reception. Most email providers send reports daily.

Q: What TLS failure types does TLS-RPT report?

A: TLS-RPT covers all failure types defined in RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, and dane-required. Each type pinpoints a specific problem in TLS negotiation or policy validation.

Q: What is the difference between TLS-RPT and DMARC?

A: TLS-RPT and DMARC protect different layers. DMARC (RFC 7489) verifies sender authentication via SPF and DKIM alignment to fight spoofing and phishing. TLS-RPT (RFC 8460) monitors transport encryption and reports TLS failures, expired certificates, and STARTTLS downgrades. DMARC ensures the sender is legitimate. TLS-RPT ensures the transport is encrypted. Deploy both.

Complementary tools

Useful resources

• RFC 8460: SMTP TLS Reporting: Official TLS-RPT specification
• RFC 8461: MTA-STS: Complementary standard for enforcing SMTP encryption
• Google: Configure TLS Reporting: Google Workspace guide for TLS-RPT