TLS-RPT (SMTP TLS Reporting) Record Checker

Fetches a domain's _smtp._tls TXT record to diagnose whether the report destination (rua) for failed TLS connections is configured correctly per RFC 8460. Useful alongside MTA-STS/DANE.

Diagnosing reports of failed TLS connections (TLS-RPT)

Adopting MTA-STS or DANE leaves one thing out of view: **whether delivery is actually failing is known only to the sending side.** TLS-RPT is the arrangement that fills that gap. Write a reporting address into the `_smtp._tls` TXT record and **sending servers will send you a daily report.** This tool fetches that record and reports whether its form conforms to RFC 8460.

**TLS-RPT is not itself a defence but a means of observation.** It does nothing to stop an attack; it merely tells you how often establishing TLS failed. **Without that observation, however, there is no way to judge when to move MTA-STS to `enforce`.** Should delivery stop the moment enforcement begins, you would not learn of it until someone complained. **The settled order in practice is therefore to set up TLS-RPT first, run MTA-STS at `testing` while reading the reports, and move to `enforce` only once you are satisfied nothing is failing.**

How to use it

  1. Enter the domain Give the domain alone, in the form `example.com`.
  2. Check the TXT record **Look for `v=TLSRPTv1` and a `rua=`.**
  3. Confirm the form of the reporting address It is written with `mailto:` or `https:`. **Confirm too that the address can actually receive.**
  4. Settle who will read the reports **Setting it up and never reading them comes to nothing.** Decide who looks, and when.

Tips for getting more out of it

  • TLS-RPT is declared by the receiving domain but consumed by sending mail servers, which use it to know where to send statistics whenever a TLS connection to your domain fails.
  • The rua field can list a mailto: address, an https: endpoint, or both, separated by commas, so you can route reports to a mailbox and an automated collector at the same time.
  • Reports arrive as JSON (application/tlsrpt+json, often gzip-compressed), so it helps to set up a dedicated parser or mailbox rather than expecting to read them by eye.
  • Right after rolling out MTA-STS or DANE, keep an eye on TLS-RPT reports for a while to catch any misconfiguration you might have missed.
  • Major mail providers such as Google, Microsoft, and Yahoo all send TLS-RPT reports, so domains that exchange a lot of mail with them benefit the most from adopting it.

Where it comes in useful

Before moving MTA-STS to enforcement

**You can measure whether anything is failing while still at `testing`**, which gives you grounds for the decision.

Noticing delivery trouble early

You learn that failures are occurring without waiting for someone to tell you.

Monitoring after adopting DANE

**A mismatch between certificate and TLSA record shows up in the reports as a failure.**

Confirming the form of your record

A mistake in how `rua` is written shows itself as no report ever arriving.

TLS-RPT terms

_smtp._tls TXT
**The DNS record carrying the reporting address.** It is written in the form `v=TLSRPTv1; rua=mailto:...`.
Rua
Where the reports are to go. **State an email address or an HTTPS endpoint prepared to receive them.**
RFC 8460
The standard defining the format of TLS-RPT and the contents of a report.
Daily report
The report a sending server sends covering one day. It carries the counts of successes and failures and the reasons for the failures.
MTA-STS
The arrangement enforcing TLS. **TLS-RPT is combined with it to see how that enforcement is actually working out.**
DANE
The arrangement validating certificates on the premise of DNSSEC. **Trouble here surfaces in the TLS-RPT reports as well.**

FAQ

MTA-STS is the enforcement mechanism that forces TLS on inbound mail. TLS-RPT is the observability mechanism that reports back whether TLS connections are actually failing. They're configured independently, and you can adopt either one on its own.

Not necessarily — most domains still don't use TLS-RPT. But if you've adopted MTA-STS or DANE, setting up TLS-RPT alongside them is worth doing so you can catch misconfigurations.

To whichever mailto: address or https: endpoint is listed in the TXT record's rua field. You can list multiple destinations separated by commas.

The reports are structured JSON data, so most operators rely on a monitoring tool or script for automated aggregation rather than reading them by eye. Several vendors offer dedicated report-parsing services.

This tool only checks the syntax and required fields (v, rua) of the TXT record. It doesn't verify that reports actually arrive, so after setup, wait a few days and confirm a report email actually shows up.
Tool-kun

Side Note — The "silent failure" gap that TLS-RPT closed

TLS-RPT (TLS Reporting, RFC 8460) was published in 2018, almost alongside MTA-STS (RFC 8461). The two were developed in the same working group and share a lot in common — both build on a DNS TXT record, and both were jointly pushed forward by Google, Microsoft, Yahoo and others — but they play very different roles. MTA-STS is the enforcement layer that forces TLS; TLS-RPT is the observability layer that reveals what actually happened once you did.

Before TLS-RPT existed, a failed TLS handshake during SMTP delivery was, in most cases, logged only on the sending server and never surfaced to the receiving domain's administrator at all. An expired certificate or a misconfigured MTA-STS policy could silently break mail delivery, and nobody would notice until mail actually stopped arriving — a real operational blind spot.

With TLS-RPT in place, a daily aggregate report is sent to whatever destination you list in rua. The report is structured JSON (application/tlsrpt+json, often gzip-compressed) containing success/failure counts and, for failures, the underlying cause (a certificate mismatch, a failed STARTTLS negotiation, and so on) — built to be ingested by monitoring tooling rather than read by a human.

In practice, TLS-RPT is usually set up together with MTA-STS or DANE. Deploying enforcement alone gives you no way to notice if a misconfiguration is silently blocking legitimate mail; watching TLS-RPT reports lets you roll out enforcement safely.

Read related trivia

Browse all trivia

People who viewed this tool also viewed

Email Address Validator

Instantly check whether an email address matches a practical RFC 5322-style format, and verify whether its domain can actually receive mail (MX record lookup). Free tool for form validation and mailing list cleanup.

SPF/DKIM/DMARC Record Checker

Look up SPF, DMARC, and DKIM records for any domain in real time and diagnose your anti-spoofing email authentication setup.

DNS Record Type Reference Guide

A reference covering the DNS record types you need for running mail and websites — A, MX, TXT, SPF, DKIM, DMARC and more — with purpose, syntax examples, and gotchas for each.

DNS Propagation Checker (Free) - Check DNS Records Worldwide

Free tool to query a domain's DNS records against multiple public resolvers around the world (Google, Cloudflare, and more) at once, so you can instantly see whether a nameserver or record change has propagated globally.

DNSSEC Checker

Query a domain's DNSKEY record against multiple public DNS resolvers (Google, Cloudflare, and more) to check whether its DNSSEC signature chain validates correctly.

MTA-STS Policy Checker

Fetches a domain's _mta-sts TXT record and mta-sts.txt policy file to diagnose whether MTA-STS (mandatory TLS encryption for inbound mail) is configured correctly.