TLS-RPT: Monitoring Email Encryption Failures
TLS-RPT (SMTP TLS Reporting) provides visibility into email encryption failures between mail servers. This guide explains what TLS-RPT is, how to set it up, and how to interpret the reports you receive.
What is TLS-RPT?
TLS-RPT (defined in RFC 8460) is a reporting mechanism that allows receiving mail servers to send reports about TLS connection failures back to domain owners. When another server tries to deliver email to your domain and encounters a TLS-related problem, TLS-RPT ensures you get notified about it.
How TLS-RPT Works with MTA-STS
TLS-RPT is designed to work hand-in-hand with MTA-STS (Mail Transfer Agent Strict Transport Security). While MTA-STS enforces TLS encryption requirements, TLS-RPT provides the feedback loop that tells you when those requirements cannot be met.
MTA-STS tells sending servers "you must use TLS with a valid certificate to deliver mail to my domain." It prevents downgrade attacks and ensures encryption.
TLS-RPT tells sending servers "if you encounter any TLS problems when connecting to my servers, send me a report." You get visibility into failures.
Pro tip: While TLS-RPT can work independently, it provides the most value when deployed alongside MTA-STS. The reports will tell you about any failures to meet your MTA-STS policy requirements.
Setting Up the _smtp._tls TXT Record
To enable TLS-RPT for your domain, you need to publish a DNS TXT record at the _smtp._tls subdomain. This record tells sending servers where to send TLS reports.
Basic TLS-RPT Record
The simplest TLS-RPT record specifies an email address for receiving reports:
Host: _smtp._tls
Type: TXT
Value: v=TLSRPTv1; rua=mailto:tls-reports@example.comRecord Syntax Explained
| Tag | Required | Description |
|---|---|---|
| v=TLSRPTv1 | Yes | Version identifier (must be TLSRPTv1) |
| rua= | Yes | Reporting URI - where to send reports (mailto: or https:) |
Multiple Reporting Destinations
You can specify multiple destinations by separating them with commas:
v=TLSRPTv1; rua=mailto:tls-reports@example.com,https://reporting.example.com/tlsUsing HTTPS Endpoints
For high-volume domains, an HTTPS endpoint may be preferable to email for receiving reports:
v=TLSRPTv1; rua=https://tls-rpt.example.com/reportHTTPS endpoints must support POST requests and return a 2xx status code. Reports are sent as JSON with Content-Type application/tlsrpt+json or application/tlsrpt+gzip.
Reading and Understanding TLS Reports
TLS-RPT reports are JSON documents sent daily (typically) by mail servers that attempted to deliver email to your domain. Here is an example report structure:
{
"organization-name": "Example Sender Inc",
"date-range": {
"start-datetime": "2024-01-15T00:00:00Z",
"end-datetime": "2024-01-15T23:59:59Z"
},
"contact-info": "postmaster@sender.example",
"report-id": "2024011500001",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 604800"],
"policy-domain": "example.com"
},
"summary": {
"total-successful-session-count": 15234,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "203.0.113.45",
"receiving-mx-hostname": "mail.example.com",
"failed-session-count": 3
}
]
}
]
}Key Report Fields
The organization that generated the report (the sending mail server operator).
The time period covered by the report, typically a 24-hour window.
Number of successful TLS connections - emails that were delivered securely.
Number of failed TLS sessions - these require investigation.
Specific information about what went wrong, including the result type and affected servers.
Common Issues Revealed by TLS Reports
TLS reports can reveal several types of issues. Here are the most common failure types and how to address them:
Your mail server's TLS certificate has expired. This is a critical issue that can cause mail delivery failures.
Fix: Renew your SSL/TLS certificate immediately. Set up automated renewal with Let's Encrypt or your certificate provider.
The certificate is not signed by a trusted Certificate Authority or the chain is incomplete.
Fix: Ensure your server presents the full certificate chain. Use a certificate from a widely trusted CA.
The certificate does not match the hostname of the mail server. This often happens when MX records point to a different hostname than what the certificate covers.
Fix: Ensure your certificate includes all hostnames listed in your MX records. Use a SAN (Subject Alternative Name) certificate if needed.
The sending server could not retrieve your MTA-STS policy file. This indicates a problem with your policy hosting.
Fix: Verify that https://mta-sts.yourdomain.com/.well-known/mta-sts.txt is accessible and returns a valid policy.
Your MTA-STS policy file exists but contains syntax errors or invalid directives.
Fix: Review your MTA-STS policy for correct syntax. Ensure all MX hostnames are listed and the mode is valid (testing, enforce, or none).
Your mail server is not advertising or properly supporting STARTTLS.
Fix: Enable STARTTLS on your mail server and ensure it is advertised in the SMTP banner.
A general validation error occurred during TLS negotiation. Check the additional details in the report for more context.
Fix: Review your TLS configuration, cipher suites, and protocol versions. Ensure you support TLS 1.2 or higher.
Summary
- 1.TLS-RPT provides visibility into email encryption failures that would otherwise go unnoticed
- 2.Deploy TLS-RPT alongside MTA-STS for complete email transport security monitoring
- 3.Add a _smtp._tls TXT record with your reporting address to enable TLS-RPT
- 4.Monitor reports regularly and investigate any failures, especially certificate-related issues
- 5.Use the failure types in reports to prioritize fixes and maintain secure email delivery
Resources
Check Your TLS-RPT Configuration
Use our scanner to verify your domain has TLS-RPT configured correctly, along with MTA-STS, SPF, DKIM, and DMARC records.
Scan Your Domain