Definition
TLS reporting (TLSRPT), defined in RFC 8460, allows domain owners to receive reports about TLS connection failures that occur when other mail servers attempt to deliver email to their domain. The reporting mechanism is configured by publishing a DNS TXT record at _smtp._tls.example.com that specifies one or more rua URIs where reports should be sent. Reports are delivered as compressed JSON files via email or HTTPS POST.
A TLSRPT report contains aggregate data about TLS connection attempts, including the sending MTA's IP address, the session-level TLS failure reason, the transport type (SMTP or SMTP with MTA-STS), and timestamps. This data is essential for diagnosing configuration problems in MX servers, TLS certificates, or MTA-STS policies. Without TLSRPT, domain owners are blind to how other mail servers experience their TLS configuration.
Best Practices
Deploy TLSRPT before or simultaneously with MTA-STS. TLS reporting gives you visibility into TLS connection issues before enforcement begins. If you deploy MTA-STS in enforce mode without TLSRPT, you will not know if legitimate email is being blocked due to TLS problems.
Use a dedicated reporting endpoint that can handle JSON report parsing and aggregation. Several commercial services offer TLSRPT parsing with dashboards and alerting. You can also self-host an open-source parser if you have the infrastructure to manage report ingestion.
Monitor TLSRPT reports closely in the first few weeks after deployment. Look for repeated failure codes that indicate the same problem across multiple senders. Common issues include expired TLS certificates, incorrect MX hostnames in MTA-STS policies, and cipher suite mismatches.
Set up alerting on TLSRPT failure rates. A sudden spike in TLS failure reports may indicate a certificate that has expired, an MX server that has been misconfigured, or a network-level TLS inspection appliance that is interfering with connections.
Respond to TLSRPT reports by correlating the sending MTA IP addresses with known sending organisations. This helps distinguish between legitimate senders affected by your configuration and potential attackers probing your infrastructure.
Related Glossary Terms
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Email Active Subscriber
An active email subscriber has opened or clicked an email within a defined recency period, typically 30-90 days by industry. Active subscriber rate of 40-60% is typical for healthy email lists.
Email Attribution Window
Email attribution window defines how far back conversions are credited to an email send or campaign. Typical windows are 7 days for promotional, 30 days for transactional, and 90 days for B2B nurture.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bounce
The return of an undelivered email to the sender, categorized as hard, soft, or transient with distinct handling rules for each.
Frequently Asked Questions
DMARC reports (rua) contain aggregate data about SPF and DKIM authentication results, including alignment and policy disposition. TLSRPT reports contain data about TLS connection-level failures, such as certificate validation errors and protocol negotiation failures. They serve different purposes and are configured independently.
No, TLSRPT is useful even without MTA-STS. It provides visibility into TLS failures during standard SMTP delivery. Any sending MTA that supports TLSRPT will send reports when TLS connections fail, regardless of whether the receiving domain has an MTA-STS policy.
Reports can be delivered via email (SMTP) to a specified mailbox or via HTTPS POST to a web endpoint. The `rua` URI in the DNS record specifies the delivery method and destination. Email-delivered reports are typically sent as compressed JSON attachments.
A TLSRPT report includes the sending MTA's identifier, the session timestamps, the TLS failure type (such as certificate expired, hostname mismatch, or protocol negotiation failure), the transport type, and the policy domain being tested. Reports are usually aggregated over a 24-hour period.
No, TLSRPT is purely a DNS configuration. You publish the TXT record on your domain, and any compliant sending MTA will automatically send reports to the specified URI. No changes to your receiving mail server are required.