TLS-RPT (TLS Reporting) is configured by adding a single TXT record to _smtp._tls.yourdomain.com with a reporting address. Sending servers that support TLS-RPT will send you daily JSON reports about TLS connection successes and failures when delivering to your domain. It's the companion to MTA-STS — you need TLS-RPT to know if MTA-STS is working correctly.
TLS-RPT Setup: How to Enable TLS Reporting for Your Domain
The DNS Record
Add this TXT record:
Type: TXT
Host: _smtp._tls
Value: v=TLSRPTv1; rua=mailto:[email protected]
That's the entire setup. Sending servers that support TLS-RPT will now send daily reports to your specified address.
You can also use HTTPS reporting:
v=TLSRPTv1; rua=https://reporting.example.com/tls-rpt
Or both:
v=TLSRPTv1; rua=mailto:[email protected],https://reporting.example.com/tls-rpt
What TLS-RPT Reports Contain
Reports arrive as JSON files (usually gzipped) and include:
- Reporting organization — which sending server generated the report
- Policy applied — your MTA-STS or DANE policy
- Successful connections — count of TLS connections that worked
- Failed connections — count and failure details
- Failure types — certificate expired, hostname mismatch, STARTTLS not supported, etc.
Example Failure Types
| Failure Code | Meaning |
|---|---|
starttls-not-supported | Your MX doesn't advertise STARTTLS |
certificate-expired | Your MX certificate is expired |
certificate-host-mismatch | Cert doesn't match MX hostname |
certificate-not-trusted | Cert chain validation failed |
validation-failure | MTA-STS policy validation failed |
Practitioner note: The first time you enable TLS-RPT, expect to find at least one surprise. Expired intermediate certificates are the most common — your mail works fine because most senders don't enforce TLS, but the reports reveal the underlying problem.
Parsing TLS-RPT Reports
Like DMARC aggregate reports, raw TLS-RPT JSON isn't fun to read manually. Options:
- Postmark — includes TLS-RPT in their free DMARC monitoring
- dmarcian — parses TLS-RPT alongside DMARC reports
- EasyDMARC — combined dashboard for DMARC and TLS-RPT
- Custom script — the JSON format is straightforward if you want to parse it yourself
TLS-RPT and MTA-STS Together
TLS-RPT is the monitoring layer for MTA-STS. The workflow:
- Deploy MTA-STS in testing mode
- Enable TLS-RPT to receive failure reports
- Monitor reports for 2-4 weeks
- Fix any TLS issues on your mail servers
- Switch MTA-STS to enforce mode
- Continue monitoring via TLS-RPT
Without TLS-RPT, deploying MTA-STS is flying blind.
Practitioner note: TLS-RPT adoption among senders is still growing. Google, Microsoft, Yahoo, and major ESPs send reports. Smaller mail servers may not. Don't assume zero reports means zero problems — it might mean the sender doesn't support TLS-RPT.
If you're deploying MTA-STS and TLS-RPT as part of a full email security implementation, let me handle the setup.
Sources
- RFC 8460: SMTP TLS Reporting
- RFC 8461: SMTP MTA Strict Transport Security
- Google: TLS Reporting Setup
- Postmark: TLS-RPT Monitoring
v1.0 · April 2026
Frequently Asked Questions
What is TLS-RPT?
TLS Reporting (RFC 8460) is a mechanism for receiving reports about TLS connection failures during email delivery. Sending servers report whether they could establish encrypted connections with your mail servers.
How do I set up TLS-RPT?
Add a TXT record at _smtp._tls.yourdomain.com with: v=TLSRPTv1; rua=mailto:[email protected]. That's it — one DNS record.
Do I need TLS-RPT if I have MTA-STS?
Yes. TLS-RPT is essential for monitoring MTA-STS. Without it, you won't know if senders are failing TLS connections. It's especially critical during MTA-STS testing mode when you're deciding whether to enforce.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.