TLS-RPT Record Generator

Generate a TLS-RPT (_smtp._tls TXT) record so you receive JSON reports when sending servers fail to negotiate TLS with your mail infrastructure. TLS-RPT (SMTP TLS Reporting, RFC 8460) is the visibility layer for MTA-STS and DANE — it tells you when and why TLS is failing so you can fix it before or after switching to enforce mode.

How to use the TLS-RPT Record Generator

Enter your domain and one or more reporting endpoints — either mailto:email@domain addresses or https:// URIs pointing to a report collector endpoint. Each endpoint goes on its own line.

Click Generate Record. The output shows the DNS Host and TXT Value to add in your DNS zone as a TXT record. The record name is always _smtp._tls.<domain>.

After publishing:

  1. Sending servers that support TLS-RPT will send daily JSON reports (RFC 8460 format) to your reporting endpoints whenever they encounter TLS failures when delivering mail to your MX hosts.
  2. Reports include: the sending MTA, the receiving MX host, the type of failure (certificate expired, policy mismatch, handshake failure, etc.), the count of affected sessions, and the date range.
  3. Monitor reports during your MTA-STS testing phase — if you see unexpected failures, investigate before switching to enforce mode.

TLS-RPT works independently of MTA-STS. Even if you are not deploying MTA-STS, TLS-RPT reports reveal TLS configuration problems on your MX servers that you might not otherwise know about.

What is SMTP TLS Reporting?

SMTP TLS Reporting (TLS-RPT), defined in RFC 8460, is a mechanism that lets domain owners receive machine-readable reports about TLS failures when external mail servers attempt to deliver email to their infrastructure. It is published as a TXT record at _smtp._tls.<yourdomain> and is the observability companion to MTA-STS — just as DMARC aggregate reports give you visibility into authentication failures, TLS-RPT gives you visibility into transport-layer encryption failures.

The failure categories TLS-RPT covers include: STARTTLS not supported or not offered by the receiving server, certificate validation failures (expired, wrong hostname, untrusted CA), MTA-STS policy mismatches (the MX hostname is not in the policy), and DANE/TLSA validation failures. Each category appears in the daily JSON report with a count of affected messages and the specific failure reason. This is data you cannot easily obtain otherwise — TLS failures are typically silent from the sender's perspective, with messages either delivered insecurely or silently queued.

TLS-RPT reports are sent by supporting mail providers — Gmail and Microsoft 365 both send them — and arrive as JSON attachments at the address you specify in the rua= tag. The JSON schema is standardised so you can parse them programmatically or use any TLS-RPT report aggregator. Unlike DMARC aggregate reports, TLS-RPT data does not contain message content — only connection-level metadata — so there are fewer privacy concerns with the forensic approach. Deploying TLS-RPT before MTA-STS enforcement is strongly recommended: know what is failing before you start rejecting deliveries.

Common use cases

  • MTA-STS rollout companion — deploy TLS-RPT alongside MTA-STS in testing mode to receive reports of any TLS failures before switching to enforce mode, preventing unintended mail loss.
  • MX certificate monitoring — TLS-RPT reports will alert you when your MX server’s TLS certificate is about to expire or has configuration issues before they cause delivery failures.
  • DANE validation feedback — if you publish TLSA records for DANE, TLS-RPT reports failures when the sending server’s TLSA lookup results do not match your certificate, helping you catch misconfigurations.
  • Third-party mail processor visibility — route TLS-RPT reports to a monitoring service or SIEM to track TLS delivery health across all your sending domains from a single dashboard.
  • Compliance evidence — TLS-RPT provides documented evidence that you monitor transport security for email, useful for security audits and regulatory reporting.

Frequently asked questions

Do I need MTA-STS to use TLS-RPT?
No. TLS-RPT can be deployed independently. Even without MTA-STS, you will receive reports about TLS failures from senders that support TLS-RPT (including Gmail and Outlook). However, TLS-RPT reports are most actionable when paired with MTA-STS because MTA-STS defines the enforcement policy that generates policy-mismatch failures.

What format are TLS-RPT reports in?
TLS-RPT reports are JSON files defined in RFC 8460 Appendix A. They contain an array of policies (MTA-STS or DANE) and for each policy, a summary of successful and failed session counts, plus a failure details array with the failure type, count, and receiving MX host.

Can I use an https: endpoint instead of mailto:?
Yes. RFC 8460 allows https: URIs as reporting endpoints. The sending server will POST the JSON report as an application/tlsrpt+gzip body. This is useful if you have a custom report aggregation service or want to avoid filling an inbox with report emails.

How are multiple endpoints specified?
In the DNS TXT value, multiple endpoints are comma-joined with no spaces: rua=mailto:[email protected],https://b.example/report. This tool joins them correctly when you enter multiple lines.

Which mail providers send TLS-RPT reports?
Google (Gmail/Workspace) and Microsoft (Outlook/Exchange Online) both send TLS-RPT reports. Fastmail and several other providers also support it. Smaller mail providers may not implement TLS-RPT yet, so you will not receive reports from every sender — but the major providers cover the majority of inbound mail volume for most domains.