TLS-RPT Checker

What TLS-RPT does

TLS-RPT (RFC 8460) is a reporting channel. A domain publishes a TXT record at _smtp._tls.DOMAIN that begins v=TLSRPTv1 and names one or more destinations in rua=. Sending mail systems that support the standard then send daily JSON summaries stating how many delivery attempts to your servers succeeded over TLS, and which failed and why.

It is the feedback half of MTA-STS and DANE. Those mechanisms say what senders should do. TLS-RPT tells you what happened. It also helps without either mechanism, because it reveals certificate and negotiation problems that senders encounter when they try to deliver to you.

How to read the result

The tool looks up the TXT record and reports one of four situations: the lookup failed, no record exists, more than one record exists, or a single record exists. For a single record it parses the rua list and shows each destination with its type. Valid destinations are mailto: addresses and https: endpoints. The finding passes when the record is valid and at least one destination is usable.

When no record exists the result is an improvement item with low severity. If MTA-STS is published, the finding says that reports would be especially useful, since the policy is otherwise operated blind.

Common problems

• Several TLS-RPT records. RFC 8460 tells senders to ignore them when there is more than one. Merge destinations into one comma-separated rua list.
• Wrong prefix. [email protected] without mailto: is invalid.
• Version typo. The record must start with v=TLSRPTv1.
• Mailbox that nobody reads. The record is valid but reports pile up or bounce.
• Reports arrive as compressed JSON. Many people expect readable mail; a mailbox filter may discard attachments.
• Record published at the wrong name. It must be at _smtp._tls, not _tls or _smtp.

How to publish safely

Prerequisites: a mailbox or HTTPS endpoint dedicated to reports, with a way to read gzip-compressed JSON attachments. Operational risk is low because the record only requests reports, but a destination with insufficient capacity can fill or bounce. Be aware that reports contain your MX host names and counts of failures, so use a destination under your control. Rollback: delete the TXT record.

1. Create a dedicated mailbox such as [email protected].
2. Publish v=TLSRPTv1; rua=mailto:[email protected] at _smtp._tls.example.com.
3. Wait for reports. Senders typically deliver them once per day, and only senders that support the feature send them.
4. Read failure summaries before you enable MTA-STS enforcement.
5. Re-run this check to confirm a single valid record.

How TLS-RPT fits with MTA-STS and DANE

MTA-STS and DANE are the mechanisms that make a sender require validated TLS. Introducing either one without visibility is risky, because a failure turns into delayed or bounced mail rather than a warning. TLS-RPT is the instrument panel for that decision. A typical sequence is to publish TLS-RPT first, read a few weeks of reports on a healthy baseline, then add MTA-STS in testing mode and watch whether the failure counts change.

The report fields to look for are the policy type, the counts of successful and failed sessions, and the failure result types, such as certificate expired, certificate host mismatch, STARTTLS not supported, or validation failure. Each points at a different fix, and the STARTTLS checker can reproduce most of them from outside.

What is not checked

Destinations are validated for syntax only. The tool does not test that the mailbox exists or accepts compressed attachments, that an https endpoint accepts reports, or that any sender actually delivers reports. Absence of reports does not prove all deliveries succeed, because only some senders send them. Unlike DMARC, no cross-domain authorisation record exists for TLS-RPT destinations in the base specification, so none is tested.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09