TLS-RPT — SMTP TLS Reporting
How TLS-RPT gives you visibility into TLS encryption failures during email delivery.
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting) is an email standard defined in RFC 8460. It enables receiving domains to request that sending mail servers report any TLS negotiation failures encountered when trying to deliver email to that domain. These reports help domain operators detect configuration errors, policy issues, and potential attacks on their email infrastructure.
How TLS-RPT Works
1. The receiving domain publishes a TLS-RPT DNS TXT record at _smtp._tls.{domain} that specifies where reports should be sent.
2. When a sending server (like Gmail or Outlook) attempts to deliver email and encounters a TLS issue, it logs the failure.
3. Once per day, the sending server generates a JSON report summarizing all TLS connection attempts and failures for that domain.
4. The report is sent to the email address or HTTPS endpoint specified in the TLS-RPT record.
5. The domain operator reviews these reports to identify and fix TLS problems.
TLS-RPT DNS Record Format
TLS-RPT records are published as TXT records at _smtp._tls.{domain}.
Example:
_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"You can also use an HTTPS endpoint:
_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=https://tls-reports.example.com/submit"Key fields:
• v=TLSRPTv1 — version
• rua= — reporting URI (mailto: or https:)
Multiple destinations are supported separated by commas.
TLS-RPT Report Format
TLS-RPT reports are JSON files delivered as gzip-compressed email attachments. Each report includes:
• Organization name of the sending server
• Date range covered
• Policies applied (MTA-STS or DANE)
• Total successful vs. failed delivery sessions
• Failure details: failure type, sending/receiving MX, count
Common failure types: starttls-not-supported, certificate-expired, certificate-not-trusted, validation-failure, policy-mismatch.
TLS-RPT and MTA-STS
TLS-RPT is most valuable when paired with MTA-STS. While MTA-STS enforces TLS, TLS-RPT gives you visibility into whether enforcement is causing delivery failures. The recommended deployment order is:
1. Deploy TLS-RPT first.
2. Deploy MTA-STS in testing mode.
3. Monitor TLS-RPT reports for failures.
4. Fix any TLS certificate or configuration issues.
5. Switch MTA-STS to enforce mode.
TLS-RPT reports will also show failures from DANE policies if your domain uses DNSSEC.
TLS-RPT Best Practices
1. Deploy TLS-RPT before MTA-STS so you have visibility from day one.
2. Use a dedicated mailbox or report aggregation service to handle incoming reports.
3. Check reports weekly during MTA-STS rollout.
4. Look for recurring failures — they often indicate expired certificates or misconfigured MX hosts.
5. TLS-RPT has no performance or delivery impact — it's safe to deploy at any time.