What Is TLS-RPT? — Email Encryption Reports
The Problem: You Cannot See TLS Failures
When another mail server sends an email to your domain, the connection should be encrypted with TLS. But what happens when TLS negotiation fails? The sending server might fall back to plaintext, or — if you have MTA-STS in enforce mode — it might refuse to deliver the message entirely.
Either way, you have no visibility. There are no bounce messages, no error logs on your side. The failure happens on the sender’s infrastructure, and you never find out about it.
TLS-RPT fixes this blind spot.
What Is TLS-RPT?
TLS-RPT (TLS Reporting), defined in RFC 8460, enables domain owners to receive daily reports about TLS connection failures when other servers send email to their domain. A single DNS TXT record at _smtp._tls.yourdomain.com activates reporting from major providers including Google, Microsoft, and Yahoo.
TLS-RPT (SMTP TLS Reporting, defined in RFC 8460) is a standard that lets you receive reports from sending mail servers about TLS connection failures when they deliver email to your domain.
Think of it as DMARC reporting, but for TLS encryption. Just as DMARC reports tell you who is sending email on behalf of your domain and whether it passes authentication, TLS-RPT reports tell you which senders are experiencing TLS problems when connecting to your mail servers.
How It Works
TLS-RPT is simple to set up — it only requires a single DNS record.
The DNS Record
You publish a TXT record at _smtp._tls.yourdomain.com:
_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"The rua tag specifies where reports should be sent. You can use:
- mailto: — reports are sent as email (JSON format, often gzipped)
- https: — reports are POSTed to an HTTPS endpoint
You can specify multiple destinations by separating them with commas.
What the Reports Contain
TLS-RPT reports are JSON documents that include:
- Reporting organization — which mail server sent the report (e.g. Google, Microsoft, Yahoo)
- Date range — the period the report covers (usually 24 hours)
- Policy type — whether MTA-STS or DANE was in effect
- Success count — number of sessions that negotiated TLS successfully
- Failure count — number of sessions where TLS failed
- Failure details — the specific type of failure for each incident
Common Failure Types
| Failure Type | Meaning |
|---|---|
starttls-not-supported | Your server does not advertise STARTTLS |
certificate-expired | Your TLS certificate has expired |
certificate-not-trusted | Certificate is self-signed or from an untrusted CA |
certificate-host-mismatch | Certificate does not match the MX hostname |
validation-failure | General TLS validation failure |
sts-policy-fetch-error | MTA-STS policy file could not be fetched |
sts-webpki-invalid | MTA-STS policy file has an invalid certificate |
| Failure Type | Meaning | Action Required |
|---|---|---|
| starttls-not-supported | Receiving server does not offer STARTTLS | Enable TLS on your mail server |
| certificate-expired | TLS certificate has expired | Renew the certificate immediately |
| certificate-host-mismatch | Certificate does not match the MX hostname | Issue a certificate matching your MX records |
| validation-failure | Certificate chain cannot be verified | Fix certificate chain or use a trusted CA |
| sts-policy-fetch-error | MTA-STS policy file could not be retrieved | Check HTTPS hosting of .well-known/mta-sts.txt |
Setting It Up
Step 1: Choose Your Reporting Destination
Decide where you want to receive reports:
- Email address — simple, but you will need to parse JSON attachments
- HTTPS endpoint — more suitable for automated processing
- A monitoring tool — services like DMARCPulse can process TLS-RPT reports automatically
Step 2: Publish the DNS Record
Add the TXT record to your domain’s DNS:
_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"Step 3: Wait for Reports
Reports are typically sent daily by major email providers (Google, Microsoft, Yahoo). It may take 24-48 hours before the first reports arrive after you publish the DNS record.
Step 4: Analyze the Reports
Review the reports for failures. Key things to look for:
- Certificate issues — expired or mismatched certificates are the most common cause of TLS failures
- Missing STARTTLS — if your server does not advertise STARTTLS, all connections will be unencrypted
- MTA-STS fetch errors — if you use MTA-STS, ensure the policy file is accessible
TLS-RPT and MTA-STS: The Complete Picture
TLS-RPT and MTA-STS are designed to work together:
- MTA-STS tells senders: “You must use TLS to deliver email to my domain”
- TLS-RPT tells senders: “If TLS fails, send me a report about it”
Without TLS-RPT, deploying MTA-STS in enforce mode is risky — you would not know if legitimate senders are unable to deliver email because of TLS issues. TLS-RPT gives you the feedback loop you need to deploy MTA-STS safely.
Who Sends TLS-RPT Reports?
Major email providers that send TLS-RPT reports include:
- Google (Gmail)
- Microsoft (Outlook.com, Office 365)
- Yahoo Mail
- Comcast
The coverage is growing as more organizations implement the standard.
Common Pitfalls
- Wrong DNS location — The record must be at
_smtp._tls.yourdomain.com, not at the domain root or any other subdomain - Invalid email address — Make sure the email address in
rua=mailto:exists and can receive mail - Mailbox overflow — Large domains can receive many reports. Consider using an HTTPS endpoint or a dedicated processing tool instead of a personal mailbox
- Ignoring reports — Publishing the record is only the first step. The reports are only valuable if you actually read and act on them
What to Do When Reports Show Failures
- Certificate expired — Renew your TLS certificate immediately and set up automatic renewal
- Certificate mismatch — Ensure your certificate covers all hostnames listed in your MX records
- STARTTLS not supported — Enable STARTTLS on your mail server (most modern mail servers support it)
- MTA-STS policy errors — Verify that
https://mta-sts.yourdomain.com/.well-known/mta-sts.txtis accessible and correctly formatted
Conclusion
TLS-RPT is a lightweight but essential standard for email security monitoring. A single DNS record gives you visibility into TLS failures that you would otherwise never know about.
If you are using MTA-STS, TLS-RPT is practically mandatory. But even without MTA-STS, knowing about TLS failures helps you maintain the encryption health of your email infrastructure.
Key Takeaways
- TLS-RPT provides visibility into TLS failures you cannot see otherwise
- Setup requires only a single DNS TXT record
- Reports are sent daily by major providers like Google, Microsoft, and Yahoo
- Use TLS-RPT together with MTA-STS for complete transport security
- DMARCPulse automatically processes TLS-RPT reports and alerts on failures
DMARCPulse processes your TLS-RPT reports automatically, visualizes success rates and failure trends, and alerts you when issues need attention. Start monitoring your email encryption today.