TLS-RPT: visibility into email TLS issues
TLS-RPT (SMTP TLS Reporting, RFC 8460) is a mechanism that allows sending email servers to send reports to the recipient domain when they encounter TLS connection problems. These problems can be: expired or invalid certificates, lack of STARTTLS support, TLS negotiation failure, or violations of the MTA-STS or DANE policy. Without TLS-RPT, these issues go completely unnoticed because sending servers typically silently fall back to unencrypted connections.
The value of TLS-RPT lies in visibility: it tells you how many emails arrive at your server over unencrypted connections and why. This is crucial for regulatory compliance (GDPR requires adequate security measures for personal data) and for the security of business communications. An expired certificate on your mail server could cause hundreds of unencrypted connections per day without your knowledge.
TLS-RPT configuration
The configuration is straightforward: a single TXT record at _smtp._tls.yourdomain.com with the version (v=TLSRPTv1) and the report address (rua=). Reports can be received via email (mailto:) or at an HTTPS endpoint (https://). For most organizations, the email option is simpler to set up. The HTTPS endpoint is preferable for high volumes or for integration with automated monitoring systems.
Interpreting TLS-RPT reports
TLS-RPT reports are in JSON format and are typically sent every 24 hours. Each report contains: the sending domain, the period covered, the type of policy applied (MTA-STS, DANE, or none), and for each policy a count of successful and failed sessions with the error type. The most common error types are: certificate-expired, certificate-not-trusted, starttls-not-supported, and sts-policy-invalid.
Use our TLS-RPT Lookup to verify that the record is configured correctly. If the report shows certificate-expired errors, check your mail server's certificate with SSL Check. For starttls-not-supported errors, verify the server's SMTP configuration with SMTP Diagnostics to ensure that STARTTLS is enabled and functioning.
TLS-RPT in the context of email security
TLS-RPT is the natural complement to MTA-STS: while MTA-STS defines the TLS security policy, TLS-RPT provides the monitoring. Implementing MTA-STS without TLS-RPT is like installing a security system without notifications: it works, but you do not know when it blocks something or when there are problems. The combination of both protocols provides the protection and visibility needed to ensure that emails in transit are always encrypted.
For a domain with a complete and secure email configuration, the checklist includes: working MX records, valid SPF, active DKIM, DMARC with policy enforcement, MTA-STS in enforce mode, and TLS-RPT for continuous monitoring. Each protocol adds a layer of security and visibility, and the absence of even one leaves a gap in protection. TLS-RPT, while the most recent addition, is the protocol that closes the loop by providing the telemetry needed to keep everything else healthy.
Implementing TLS-RPT is among the simplest in the entire email security stack: a single DNS record and a dedicated email address. There is no reason not to configure it. The reports you receive may reveal security issues in the email delivery chain that you were not aware of, allowing you to act proactively before they become critical.