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 add your domain. CaptainDNS provides a report delivery email address for the monitor and an alternative HTTPS URL.
Step 2: Verify domain ownership
Add the verification TXT provided by CaptainDNS to prove domain ownership. Domain verification and activation do not confirm report receipt.
Step 3: Publish the TLS-RPT record
Open the monitor's setup to publish the recommended _smtp._tls TXT with its mailto destination. Review retained recipients before replacing an existing TXT. If the DNS lookup fails, add only the fragment to rua= without removing other recipients, or retry to get the full value.
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting), defined by RFC 8460, lets participating senders report TLS connection results. The TXT specifies where reports should go, without guaranteeing they will be sent.
Example DNS record:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Illustrative example only: replace TOKEN with the token in your monitor's setup. For an existing TXT, use the monitor's recommendation to review the recipients to retain. The mailto fragment alone is not a complete TXT record.
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.
| Field | Description |
|---|---|
| Sending organization | The email provider that sent the report |
| Period | Start and end timestamps of the reporting window |
| Applied policies | MTA-STS, DANE, or STARTTLS policies detected |
| Successful sessions | Number of TLS connections established successfully |
| Failed sessions | Number of TLS negotiation failures with error details |
The 11 TLS-RPT failure types (RFC 8460)
Section 4.3 of RFC 8460 defines 11 result-type values, and monitoring surfaces all of them. Some senders also emit starttls-not-offered, a non-RFC variant of starttls-not-supported, handled as such.
| Failure type | Description |
|---|---|
starttls-not-supported | The receiving server does not support STARTTLS |
certificate-expired | The TLS certificate presented by the MX has expired |
certificate-host-mismatch | The certificate does not match the MX hostname |
certificate-not-trusted | The certificate chain is not trusted by the sender |
validation-failure | General TLS validation failure |
tlsa-invalid | The DANE TLSA record is invalid or does not match |
dnssec-invalid | The DNSSEC chain required for DANE is broken or absent |
dane-required | DANE is required but could not be validated |
sts-policy-fetch-error | Unable to fetch the MTA-STS policy (HTTPS or DNS) |
sts-policy-invalid | The MTA-STS policy could not be validated |
sts-webpki-invalid | The MTA-STS policy host has an invalid Web PKI certificate |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protects | Transport encryption (SMTP TLS) | Sender authentication (SPF/DKIM) |
| Reports on | TLS connection failures, certificate errors | Authentication alignment failures |
| RFC | RFC 8460 | RFC 7489 |
| DNS record | _smtp._tls TXT | _dmarc TXT |
| Threats detected | Expired certificates, STARTTLS stripping, DANE/MTA-STS misconfigurations | Spoofing, phishing, domain impersonation |
Both protocols are complementary. Deploy DMARC monitoring alongside TLS-RPT for full email security visibility.
Who sends TLS-RPT reports?
Reports come from senders that support TLS-RPT and attempt to deliver mail to your domain. Availability and frequency depend on traffic and each sender's implementation. Publishing the TXT does not guarantee a report from any particular provider.
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.
CaptainDNS analyzes received reports without a server to manage or JSON to decode. Delivery depends on senders and traffic to your domain.
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: The first tool on your account is free. Each TLS-RPT domain is one tool: €3/month excl. VAT after that. No hidden fees, no trial.
Q: How do I configure my domain to send reports here?
A: Open the monitor's setup to publish the recommended _smtp._tls TXT with its mailto destination. Review retained recipients before replacing an existing TXT. If the DNS lookup fails, add only the fragment to rua= without removing other recipients, or retry to get the full value.
Q: What report formats are supported?
A: We accept TLS-RPT JSON reports defined by RFC 8460, with or without gzip compression, by email and HTTPS POST. Email is the recommended destination; HTTPS remains supported.
Q: How does domain verification work?
A: Add the verification TXT provided by CaptainDNS to prove domain ownership. Domain verification and activation do not confirm report receipt.
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: Senders that support TLS-RPT generally send reports for 24-hour periods. Receipt depends on those senders and on traffic. There is no guaranteed time for the first report; received reports are then analyzed in the dashboard.
Q: What TLS failure types does TLS-RPT report?
A: TLS-RPT covers the 11 failure types defined in RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, and sts-webpki-invalid. 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 checks authentication and alignment; it does not guarantee that the sender is legitimate. TLS-RPT reports TLS connection results; it does not guarantee encryption. Deploy both.
Complementary tools
| Tool | Purpose |
|---|---|
| TLS-RPT Syntax Check | Validate TLS-RPT record syntax |
| TLS-RPT Record Check | Check your domain's TLS-RPT DNS record |
| TLS-RPT Generator | Generate a TLS-RPT DNS record |
| TLS-RPT Report Reader | Manually analyze a TLS-RPT JSON report |
| MTA-STS Hosting | Host your MTA-STS policy (first tool free, then €3/month excl. VAT) |
| DMARC Monitoring | Monitor and analyze DMARC aggregate reports |
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