Why monitor TLS-RPT reports?
TLS-RPT (SMTP TLS Reporting, RFC 8460) gives you visibility into TLS connection failures affecting your inbound mail. Without it, you have no way to know when sending servers fail to encrypt mail destined for your domain.
Three common issues detected through TLS-RPT:
- Expired certificates -- Your MX server presents an invalid or expired TLS certificate, blocking encrypted connections. Encrypted sessions fail. Senders retry in plaintext or drop the message entirely.
- Misconfigured MTA-STS -- Your MTA-STS policy doesn't match your actual MX servers. Strict senders reject the connection outright. Those emails never reach your inbox.
- STARTTLS downgrade -- Network intermediaries strip the STARTTLS extension, forcing mail into plaintext. Sensitive messages travel unencrypted across the public internet, with no warning to you or your users.
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 allows sending mail servers to report TLS negotiation failures to the receiving domain.
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 sending servers where to deliver their JSON reports when a TLS connection to your domain fails.
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 |
Real-world use cases
Incident 1: Undetected expired certificate
Symptom: Major senders (Google, Microsoft) report certificate-expired failures in their TLS-RPT reports.
Diagnosis: The CaptainDNS dashboard shows a spike in failures over the last 24 hours, all linked to an expired Let's Encrypt certificate on the primary MX. During that window, strict senders silently dropped messages rather than deliver over a broken TLS session. Your users stopped receiving emails from these providers without any error on their end.
Action: Renew the TLS certificate on the mail server. Subsequent reports confirm the issue is resolved.
Incident 2: Out-of-sync MTA-STS policy
Symptom: Reports show sts-policy-invalid failures despite a published MTA-STS policy.
Diagnosis: TLS-RPT reports reveal that the MTA-STS policy references an MX server that no longer exists. Senders enforcing the policy reject the connection. Affected users see no delivery failure -- the email simply never arrives.
Action: Update the MTA-STS policy to reflect the current MX servers.
FAQ -- Frequently Asked Questions
Q: What is a TLS-RPT record?
A: A TLS-RPT record is a DNS TXT record placed at _smtp._tls.yourdomain.com. It contains a rua= directive that tells sending servers where to deliver TLS failure reports (RFC 8460).
Q: Are TLS-RPT and MTA-STS related?
A: They are complementary but independent. MTA-STS enforces an encryption policy. TLS-RPT tells you when senders cannot comply with it. Deploying both together gives you enforcement and visibility.
Q: What are the risks of running without TLS-RPT?
A: You are blind. TLS failures happen silently -- no bounce, no notification, no log you can reach. Days or weeks can pass before you notice that emails from Google, Microsoft, or other major providers are being dropped or delivered unencrypted.
Q: How many domains can I monitor?
A: You can monitor up to 10 domains from a single account. Each domain has its own verified endpoint.
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 |
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