Patchkit

Free tool

TLS-RPT Report Analyzer

Open one SMTP TLS report to see how many connections to your mail servers negotiated TLS successfully, how many failed, and what each failure type means.

The report is read in your browser and never leaves it. Nothing is sent to Patchkit or stored.

By Ahmet Karaca · Updated · Checked against RFC 8460 (SMTP TLS Reporting) and RFC 8461 (MTA-STS) on

What a TLS-RPT report is

When servers deliver mail to each other they upgrade the connection with STARTTLS, but that upgrade is opportunistic, and RFC 8460 points out that an attacker who strips it or redirects the connection may go unnoticed by the receiving server. SMTP TLS Reporting (TLS-RPT) covers that blind spot from the other side: servers that send mail to your domain tell you how their TLS connections went.

A report is a JSON file. It names the organization that sent it, a contact address, a unique report ID and the date range it covers. For each policy the sender applied, it lists the policy type (sts for MTA-STS, tlsa for DANE, or no-policy-found), the policy itself, the count of successful and failed sessions, and a failure entry for each kind of problem it ran into. The success count matters even on a quiet day: the RFC calls it a heartbeat that shows reporting works.

Who sends reports, and how often

Reports come from the sending side: mail servers and providers that implement TLS-RPT and deliver mail to a domain that asks for reports. The RFC says a report should cover a full UTC day, from 00:00 to 24:00, and should be sent after a delay so the receiving system isn't flooded; its example waits a random time of up to 4 hours. If delivering a report fails, the sender should retry for up to 24 hours, but the RFC also calls the reports optional, so not every sender sends one and a missing report proves nothing.

Reports should be gzip-compressed. Sent by email, the report is an attachment with the media type application/tlsrpt+gzip, or application/tlsrpt+json when it isn't compressed, and the message must carry a valid DKIM signature from the reporting domain. The RFC notes that an uncompressed report may exceed what receivers accept, with 10 MB as a commonly observed limit.

How to start receiving reports

Publish a TXT record at _smtp._tls under your domain. It starts with v=TLSRPTv1 and names where reports go in rua=, as a mailto: or https: address, or a comma-separated list of several:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Publish exactly one such record: if senders find more than one record starting with v=TLSRPTv1, they must assume your domain doesn't use TLS-RPT. The MTA-STS generator writes this record together with an MTA-STS policy, and the MTA-STS checker confirms that it's published.

How to read the totals

  • Successful sessions are connections where the sender negotiated TLS that complied with the policy it applied (total-successful-session-count).
  • Failed sessions are connections the sender couldn't establish (total-failure-session-count). The failure details break them down by result type, sending and receiving IP and MX host.
  • Success rate is calculated by this tool: successful sessions divided by successful plus failed sessions, across every policy in the report. With no sessions at all there is no rate.
  • Failure types can overlap, so the failure rows can add up to more than the failed total. Transient problems such as busy networks or TCP timeouts don't have to be reported at all.

The mode in an MTA-STS policy string changes what a failure means. In testing mode, RFC 8461 lets senders deliver as though validation hadn't failed and report the failure. In enforce mode they must not deliver to a host that fails MX matching or certificate validation, or doesn't support STARTTLS; they move on to the next MX host and otherwise retry later, so enforce-mode failures can mean delayed or undelivered mail. For each result type in your report, the tool shows the RFC's meaning and where to look.

What this tool checks

  • The report's structure: the required fields, their types, whole non-negative counts and RFC 3339 dates.
  • Plain .json files and gzip-compressed .json.gz files, recognized by their content rather than their name.
  • Every policy with its type, domain, MX hosts, policy string and session counts.
  • Every failure row, with an explanation of each result type from RFC 8460.

What it doesn't check

  • It doesn't connect to your MX hosts or re-test anything; the numbers are the sender's.
  • It can't confirm who sent the report. For emailed reports that is the job of the DKIM signature RFC 8460 requires on the message.
  • It reads one report at a time, up to 10 MB as a file and 20 MB once decompressed.

New to MTA-STS? MTA-STS and TLS-RPT explains both records and a safe order for moving from testing to enforce.

Related tools and guides

Frequently asked questions

+Is my report uploaded to Patchkit?

No. The file or the pasted JSON is read by code running in your browser and never leaves it. Nothing is uploaded, stored or logged, the page address doesn't change, and analytics only counts that the tool was used and whether it worked. You can confirm it in your browser's network tab.

+Where do I find a TLS-RPT report?

Sending organizations deliver reports to the address in the rua= tag of your _smtp._tls record. By email, the report is an attachment; the RFC recommends a file name like sender!policy-domain!begin-timestamp!end-timestamp.json.gz. Save it and open it here as it is. If your rua= points to an HTTPS address, the reports arrive at that endpoint instead.

+What does no-policy-found mean?

RFC 8460 uses the policy type no-policy-found when the sender found neither an MTA-STS policy nor DANE TLSA records for your domain. The session counts are still reported for that domain.

+Why don't the failure rows add up to the failed-session total?

RFC 8460 says failure types are not exclusive: when one delivery attempt runs into several errors, the report can count it under more than one result type, so the rows can add up to more than the total. The RFC doesn't describe rows that add up to less; the reporter may not have listed every failure. The tool notes either case.

+No failures in testing mode: can I switch to enforce?

One clean report covers one sender over one period, usually a single UTC day. It says nothing about senders that didn't report. Read reports from several senders over several days before you change mode: in enforce mode RFC 8461 says senders must not deliver to a host that fails validation.

+Why isn't the additional-information link clickable?

RFC 8460 lets a reporter add a URI with more information about a failure, such as the certificate chain it saw. It comes from the report file, so the tool treats it as untrusted text and never turns it into a link. Copy it into your browser only if you recognize the reporter's domain.

We use Google Analytics cookies only if you accept. Privacy policy