Why monitor TLS-RPT reports?
TLS-RPT (SMTP TLS Reporting, RFC 8460) is the only standard that surfaces TLS connection failures on your inbound mail. Without it, failed encryption leaves no trace on the receiving side. You lose emails silently. Your domain reputation degrades invisibly.
Three common issues detected through TLS-RPT:
- Expired certificates: Your MX server presents an expired TLS certificate. Encrypted sessions fail. Senders retry in plaintext or drop the message entirely.
- Misconfigured MTA-STS: Your MTA-STS policy references MX servers that no longer exist. Strict senders reject the connection. Those emails never arrive.
- STARTTLS downgrade: Network intermediaries strip the STARTTLS extension. Mail transits in plaintext across the public internet. Neither you nor your users receive any warning.
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 (Transport Layer Security Reporting) is a standard defined by RFC 8460. It lets sending mail servers report TLS negotiation failures to the receiving domain. One DNS record is all it takes.
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?
| 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 |
TLS-RPT failure types (RFC 8460)
| 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 |
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 |
tlsa-invalid | The DANE TLSA record is invalid or does not match |
dane-required | DANE is required but could not be validated |
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?
Major email providers send TLS-RPT reports when they detect TLS failures connecting to your domain. If you receive mail from any of these, you are already covered:
- 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
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.
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
| 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 for free |
| 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