# TLS-RPT Report Analyzer

URL: https://iblockspam.com/tools/tls-rpt-analyzer
Last updated: 2026-10-23

> Drop in the TLS reports you receive and see how many connections to your mail servers were encrypted, which failed, why, and whether you're ready for MTA-STS enforce mode.

Free tool: Open TLS-RPT reports (JSON or .gz) to see successful and failed TLS sessions, failure types and sending servers — runs in your browser. Use it at https://iblockspam.com/tools/tls-rpt-analyzer

## What the TLS-RPT Report Analyzer does

When your domain publishes a TLS-RPT record (`_smtp._tls`), sending mail systems that support [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html) send you an aggregate report, normally covering one UTC day. Each report says how many connections to your mail servers negotiated TLS as your policy requires, and describes the ones that didn't. They arrive as JSON files, usually gzip-compressed, named like `sender!yourdomain!begin!end.json.gz`.

The analyzer opens any number of them and shows:

- **Overview:** total sessions, successful and failed, the period covered and the organizations that reported.
- **Policies the senders applied:** your domain, the policy type (MTA-STS, DANE TLSA, or "no policy found"), the MTA-STS mode and MX patterns they saw, with counts.
- **Failures by result type:** each failure type from RFC 8460 section 4.3, explained in plain English.
- **Failures by sending server** and a **failure details** table with the receiving MX host, its IP address and the reporter's reason code.
- **Next steps,** based on the failure types and your current mode.

**It runs in your browser. Nothing is uploaded.** Compressed files are unpacked with your browser's built-in gzip support, and duplicate copies of the same report (same organization and report ID) are skipped so nothing is counted twice.

## The result types, explained

| Result type | Kind | What it means and what to do |
|---|---|---|
| `starttls-not-supported` | Negotiation | The MX didn't offer STARTTLS. Turn it on before enforcing. |
| `certificate-host-mismatch` | Negotiation | The certificate doesn't fit the policy, for example the MX name isn't in it. Fix the certificate or the `mx` lines. |
| `certificate-expired` | Negotiation | The MX certificate has expired. Renew it. |
| `certificate-not-trusted` | Negotiation | An untrusted CA, a broken chain or similar. The reason code says which. |
| `validation-failure` | General | Anything else. Read the reason code. |
| `tlsa-invalid` | DANE | No TLSA record for the MX was valid. |
| `dnssec-invalid` | DANE | The sender's resolver got no valid DNSSEC records. |
| `dane-required` | DANE | The sender requires DANE for your domain, but found no validated TLSA records. |
| `sts-policy-fetch-error` | MTA-STS | The policy file couldn't be fetched. |
| `sts-policy-invalid` | MTA-STS | The policy file didn't validate. |
| `sts-webpki-invalid` | MTA-STS | The policy couldn't be authenticated with the usual certificate (PKIX) checks. |

RFC 8460 calls this an initial list that is "expected to grow", so the analyzer shows any other type it finds, marked as not defined in RFC 8460. It also notes that transient errors, such as busy networks and TCP timeouts, don't have to be reported, so a clean report doesn't prove every connection succeeded.

Failure types can overlap: one session that hits two problems may be counted under both. That's why the per-type numbers can add up to more than the failed total.

## From testing to enforce

MTA-STS ([RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html)) has a `testing` mode for exactly this: senders deliver as usual but report failures. Google recommends starting there ([Google Workspace Admin Help](https://support.google.com/a/answer/9276511)). A sensible path:

1. Publish your MTA-STS policy in testing mode with a TLS-RPT record. The [MTA-STS & TLS-RPT Record Generator](https://iblockspam.com/tools/mta-sts-generator) builds all three pieces.
2. Collect reports for a few weeks and open them here.
3. Fix each failure type: certificates, `mx` lines, or the policy host.
4. When reports show no failures for your real MX hosts, switch to `enforce` and change the policy id.
5. Keep reading reports. In enforce mode, a failure means a sender that supports MTA-STS didn't deliver over that connection.

Check the live setup at any time with the [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker), and read our guide to [MTA-STS and TLS-RPT](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) for the background. For the encryption basics, see [how STARTTLS protects email in transit](https://iblockspam.com/blog/starttls-email-encryption-in-transit).

## What's in a report

The fields follow RFC 8460 section 4.4: `organization-name`, `date-range`, `contact-info` and `report-id` at the top, then a `policies` array. Each policy entry has the `policy` (type, `policy-string`, `policy-domain`, MX hosts), a `summary` with `total-successful-session-count` and `total-failure-session-count`, and `failure-details` with `result-type`, `sending-mta-ip`, `receiving-mx-hostname`, `receiving-ip`, `failed-session-count` and an optional `failure-reason-code`.

RFC 8460 requires reports sent by email to carry a valid DKIM signature from the reporting domain, and tells recipients to ignore ones that don't. The analyzer can't check the email's signature, only the file you give it, so anything strange in a report deserves a second look.

## Limitations

- It reads `.json` and gzip files (`.json.gz`, `.gz`). Extract reports from zip archives first.
- Up to 50 MB of files at a time, and up to 20 MB per report once decompressed.
- It shows what reporters sent. Senders that don't support TLS-RPT never appear.
- Results disappear when you leave the page.

## Sources

- [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html)
- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 7672: SMTP Security via Opportunistic DANE TLS](https://www.rfc-editor.org/rfc/rfc7672.html)
- [Google Workspace Admin Help: Create an MTA-STS policy](https://support.google.com/a/answer/9276511)
- [Google Workspace Admin Help: About MTA-STS and TLS reporting](https://support.google.com/a/answer/9261504)

## Frequently asked questions

### What is a TLS-RPT report?

A daily JSON summary that a sending mail system emails or posts to the address in your _smtp._tls record. It counts how many connections to your mail servers negotiated TLS successfully under your MTA-STS or DANE policy, and lists failures by type, sending server and receiving MX host. RFC 8460 defines the format.

### Are my TLS reports uploaded anywhere?

No. The analyzer runs entirely in your browser. Files are read, decompressed and parsed on your device, and nothing is sent to our servers. Report contents are shown as plain text only. When you close the page, the data is gone.

### What does sts-policy-fetch-error mean in a TLS report?

The sender couldn't retrieve your MTA-STS policy file, for example because the mta-sts host didn't answer. Check that https://mta-sts.yourdomain/.well-known/mta-sts.txt loads over HTTPS with a valid certificate and returns the file directly, without a redirect.

### Why do failure counts add up to more than the failed total?

RFC 8460 says failure types aren't exclusive: one connection attempt that hits two problems, such as an expired certificate that also doesn't match the host name, can be counted under both. Use the summary's total failure count for the number of failed sessions.

### When are my TLS reports good enough to switch to enforce mode?

When several weeks of reports in testing mode, from all the organizations that send them, show no failures for your real MX hosts. Fix certificate and policy-file errors first. Then change the mode to enforce and publish a new policy id.

---

Source: iBlockSpam, https://iblockspam.com/tools/tls-rpt-analyzer (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt