TLS-RPT Record Generator

TLS-RPT: visibility into outbound SMTP encryption failures

TLS-RPT (SMTP TLS Reporting) is the reporting counterpart to MTA-STS and DANE, defined in RFC 8460 by the IETF in 2018. Where MTA-STS tells senders "use TLS or refuse delivery", TLS-RPT tells receivers "and here is where to send me a daily JSON report whenever something goes wrong". Without it, you announce a TLS policy and stay blind to certificate mismatches, downgrade attempts, MX changes that broke trust, or a sender misconfigured against your policy — usually until a customer complains.

The DNS record itself is minimal:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

The rua tag (Reporting URI of Aggregate reports) accepts mailto: addresses or https:// endpoints, separated by commas. Sending MTAs that respect TLS-RPT will POST or email a daily aggregate report to those URIs.

What is inside a TLS-RPT report

Reports are JSON documents, typically gzipped, that summarize one calendar day of attempted deliveries to your domain. Each record describes the policy applied (MTA-STS or TLSA), the count of successful sessions, the count of failures, and per-failure detail: failure type (starttls-not-supported, certificate-expired, certificate-host-mismatch, validation-failure, etc.), the receiving MX hostname, and the sending IP. Reading this stream is how you find out that a single hyperscaler suddenly stopped trusting your certificate yesterday.

Where reports go and how to process them

Hand-parsing TLS-RPT JSON is unpleasant, so most teams point rua at a SaaS aggregator: dmarcian, Valimail, Postmark TLS Reports, EasyDMARC and Mimecast all ingest reports, normalize the data and surface dashboards with trend lines and failure breakdowns. Open-source parsers exist (the tls-rpt Python package, parsedmarc) for teams that prefer to keep the data in-house.

How it fits the email security stack

The classic stack is now SPF + DKIM + DMARC for authentication, BIMI for inbox branding, and MTA-STS + TLS-RPT for transport encryption. TLS-RPT borrows DMARC's pattern almost verbatim — a tiny DNS record pointing to where to mail the reports — which makes it easy to roll out alongside an existing DMARC deployment. Large enterprises (Google, Microsoft, the major US and EU banks, and Brazilian banks like Itaú, Bradesco and Santander) are increasingly making MTA-STS+TLS-RPT a prerequisite for B2B suppliers.

FAQ

Does TLS-RPT replace DMARC reports? No — they are complementary. DMARC reports cover authentication (SPF/DKIM alignment); TLS-RPT covers the transport layer (was the connection actually encrypted and the certificate trusted).

Is it mandatory? Not formally, but if you have already deployed MTA-STS in testing mode without TLS-RPT, you are throwing away the only feedback channel that tells you whether enforce is safe to enable.

Will my marketing platform support it? The ones that route through their own MX do — SendGrid, Mailgun, AWS SES, Postmark and Mailchimp/Mandrill. Klaviyo and similar that send from your domain inherit your DNS configuration anyway.

Where can I check the record? dig +short TXT _smtp._tls.example.com from a shell, or use the validator at mxtoolbox.com/tls-rpt-record-lookup.aspx.