STARTTLS negotiation failures happen all the time. A misconfigured certificate, an expired root CA, a cipher suite mismatch, a downgrade attack. The sending server falls back to plaintext, the message goes through, and you never know it happened.
TLS-RPT (RFC 8460) gives you visibility into those failures. It's the STARTTLS equivalent of DMARC aggregate reports: sending mail servers that support TLS-RPT will send you JSON reports documenting when TLS negotiation with your MX hosts failed, what the failure mode was, and how many messages were affected.
Most organizations don't know it exists. If you're running email infrastructure, you should enable it.
How TLS-RPT Works
TLS-RPT is a feedback mechanism for SMTP TLS policy. When a sending mail server tries to deliver to your domain and encounters a TLS failure, it generates a report and sends it to the address you specify in your TLS-RPT DNS record.
The flow:
- Your domain publishes a TLS-RPT record at
_smtp._tls.yourdomain.comwith a reporting address. - A sending mail server attempts TLS negotiation with your MX host.
- If negotiation fails (certificate error, protocol mismatch, connection timeout, etc.), the sender logs the failure.
- The sender aggregates failures and sends a daily JSON report to your designated address.
Reports arrive as email messages with a JSON attachment. The JSON contains detailed failure data: which policy was being enforced (MTA-STS or DANE), what went wrong, how many attempts failed, and during what time window.
Publishing a TLS-RPT Record
The DNS record is simple:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
The rua (reporting URI aggregate) field specifies where reports should be sent. You can list multiple addresses separated by commas. HTTPS endpoints are also supported (rua=https://example.com/tls-rpt), but email is far more common.
Most organizations use a subdomain or dedicated mailbox for TLS reports. Parse the JSON with a script, log failures to your monitoring stack, or use a third-party service to aggregate and visualize the data.
You can verify your DNS record with the DNS lookup tool on mrdns.com, which supports TXT record queries for _smtp._tls records.
Reading the JSON Reports
TLS-RPT reports are verbose but structured. Here's a minimal example:
{
"organization-name": "Sending MTA Inc",
"date-range": {
"start-datetime": "2026-04-27T00:00:00Z",
"end-datetime": "2026-04-28T00:00:00Z"
},
"contact-info": "postmaster@sendingmta.example",
"report-id": "2026-04-27-abc123",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1","mode: enforce","mx: mail.example.com","max_age: 86400"],
"policy-domain": "example.com"
},
"summary": {
"total-successful-session-count": 1523,
"total-failure-session-count": 7
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "203.0.113.45",
"receiving-mx-hostname": "mail.example.com",
"receiving-ip": "198.51.100.10",
"failed-session-count": 4,
"additional-information": "Certificate expired on 2026-04-25"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "203.0.113.67",
"receiving-mx-hostname": "backup-mx.example.com",
"receiving-ip": "198.51.100.20",
"failed-session-count": 3
}
]
}
]
}
Key fields:
date-range: The reporting window (usually 24 hours).total-successful-session-count: Baseline for context. If you have 10,000 successful sessions and 2 failures, that's noise. If you have 50 successful and 200 failures, you have a problem.failure-details: The actionable data.result-typetells you what went wrong. Common values:certificate-expired,certificate-not-trusted,validation-failure,starttls-not-supported,tlsa-invalid(DANE).receiving-mx-hostnameandreceiving-ip: Which of your MX hosts had the problem.failed-session-count: Volume of affected delivery attempts.
What Failure Events Mean
certificate-expired: Your certificate expired. Renew it. If you're using Let's Encrypt or another ACME provider, check your renewal automation.
certificate-not-trusted: The certificate chain is broken. Common causes: missing intermediate certificate, untrusted root CA, self-signed certificate. Verify your chain with openssl s_client -connect mail.example.com:25 -starttls smtp, or use the SSL certificate checker on mrdns.com to inspect certificate details, expiry, SANs, and chain validation.
validation-failure: Broader certificate validation issue. Could be hostname mismatch, revoked certificate, or other X.509 validation error. Check the additional-information field for details.
starttls-not-supported: Your MX host didn't advertise STARTTLS. If you're enforcing TLS with MTA-STS, this is a serious misconfiguration.
tlsa-invalid: DANE validation failed. Your TLSA record doesn't match the certificate presented by your MX host. Verify your TLSA record and certificate fingerprint.
Transient errors like connection timeouts or TLS handshake timeouts are also reported. A few scattered timeouts are normal. Sustained timeouts suggest a network or server performance issue.
Why TLS-RPT Matters
STARTTLS is opportunistic by default. If negotiation fails, most MTAs silently fall back to plaintext. Without TLS-RPT, you have no visibility into those downgrades.
TLS-RPT gives you telemetry. It tells you when your certificate is about to expire before it breaks delivery. It tells you when a backup MX host isn't properly configured. It tells you when someone is attempting a downgrade attack (if you're using MTA-STS enforcement).
Combined with MTA-STS, TLS-RPT closes the feedback loop. MTA-STS tells sending servers "you must use TLS to deliver to my domain." TLS-RPT tells you "here's what happened when they tried."
If you're serious about email security, both should be deployed. If you're already monitoring your infrastructure with tools like RBL Monitoring, adding TLS-RPT to your observability stack is a natural extension.
Enable the DNS record, set up a mailbox, parse the JSON, and start watching for failures. Most of the time you'll see nothing. When you do see something, it's worth knowing about.