TLS-RPT Report Analyzer

Why this is a browser tool

A TLS report names your MX hosts and their addresses, the senders connecting to them, and which of those connections failed. It is a map of your mail infrastructure and, in part, of who writes to you. There is no good reason to upload that to a stranger to have a JSON file pretty-printed.

So the parsing happens here, in the page: the gzip is decompressed with the browser’s own DecompressionStream, the JSON is read, and the analysis is rendered — with no request to any server. The optional shareable link is the only thing that sends anything, and what it sends is a handful of counts and result-type names. The server rebuilds the shared page from those counts rather than storing what your browser sent, so a hostname or an IP cannot end up in the database even by accident.

Several vendors put this behind a subscription and require you to upload the file. The analysis is not the hard part; the packaging is.

Not receiving reports yet?

You need one TXT record. Setting up TLS-RPT covers what to publish and what arrives — and publishing an MTA-STS policy safely is the sensible next step once you can see the failures, since enforcing a policy before you can see them is how inbound mail disappears quietly.

Every result type explained

All eleven failure types RFC 8460 §4.3 defines, each with what it means and what to do.

Common questions

Is my report uploaded anywhere?

No. The file is decompressed and parsed entirely in your browser, including the gzip step. You can disconnect from the network after the page loads and the analysis still works. The only request this page can make is the optional shareable link, and that sends counts and result-type names only — no IP addresses, no hostnames, and no part of the report itself.

What is TLS-RPT?

SMTP TLS Reporting, defined by RFC 8460. You publish a _smtp._tls TXT record naming an address, and mail providers send you a daily JSON report of how their TLS connections to your servers went. It is how you find out that your certificate expired or your MTA-STS policy stopped being fetchable — failures that happen at the sender’s end, so nothing bounces to you and nobody tells you.

Why are the reports gzipped JSON?

RFC 8460 specifies gzip, so every reporter sends .json.gz attachments. Most mail clients cannot open them, which is the whole reason these reports go unread — the data is fine and the packaging is the barrier.

A failure appears in my report. Is my mail bouncing?

Not necessarily, and the difference matters. Certificate and negotiation failures mean senders enforcing a policy did not deliver to you at all — and you see no bounce, because the failure happened at their end. An MTA-STS policy that cannot be fetched usually means mail still arrived, just unencrypted. This tool separates the two rather than reporting everything as a failure.

Whose failures are these — mine or the sender’s?

Yours, almost always. You publish TLS-RPT for your own domain, and senders report the failures they hit while delivering to you. So policy-domain and receiving-mx-hostname in your reports are your own mail server, and sending-mta-ip belongs to whoever sent the report. An expired certificate in your report is your certificate. This catches people out constantly, which is why every result type here says explicitly whose it is.

Can I analyse several days at once?

Yes. Drop as many files as you like and they are merged into one view, grouped by reporter, with the date range widened to cover all of them. That is usually more useful than reading a week of dailies one at a time.

Related

The SPF, DKIM and DMARC checker reports whether your domain publishes MTA-STS and TLS-RPT at all, and hands back the records to add. If your reports show authentication problems rather than TLS ones, the bounce decoder explains what receivers are telling you.