Skip to content
iBlockSpam
Get started
Check your domain Get started Log in
How it works
Platforms
Microsoft 365 Google Workspace cPanel / WHM Exchange Server
Solutions
Small business MSPs Hosting providers Law firms Accounting firms Healthcare practices Real estate & title
Free tools Pricing
Blog
All guides
By topic
Email security basics Phishing & threats SPF, DKIM & DMARC Setup guides Running email day to day Switching & migration Choosing a filter
Reference
Glossary Research: top 1,000 sites
Free tool

TLS-RPT Report Analyzer

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.

Open your TLS-RPT reports

Choose or drop one or more report files: .json, .json.gz or .gz, as attached to the reports senders email to the address in your _smtp._tls record. Everything is read in your browser — nothing is uploaded. Up to 50 MB of files at a time.

Drop report files here

or

RFC 8460 aggregate reports, one JSON file per report.

What the TLS-RPT Report Analyzer does

When your domain publishes a TLS-RPT record (_smtp._tls), sending mail systems that support RFC 8460 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) has a testing mode for exactly this: senders deliver as usual but report failures. Google recommends starting there (Google Workspace Admin Help). A sensible path:

  1. Publish your MTA-STS policy in testing mode with a TLS-RPT record. The MTA-STS & TLS-RPT Record 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, and read our guide to MTA-STS and TLS-RPT for the background. For the encryption basics, see how STARTTLS protects email 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

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.

Related guides

SPF, DKIM & DMARC

MTA-STS and TLS-RPT explained: how to set them up safely

What MTA-STS and TLS-RPT protect against, the DNS records and policy file you need, testing vs enforce mode, and safe rollout behind a filtering gateway.

9 min read Email security basics

Is my email encrypted in transit? STARTTLS, MTA-STS and DANE explained

What STARTTLS does for email, why opportunistic TLS can be downgraded, how MTA-STS and DANE enforce it, what Gmail's lock icons mean, and where TLS stops.

9 min read SPF, DKIM & DMARC

How to read DMARC reports

A field-by-field guide to DMARC aggregate (rua) reports under RFC 9990: spot your real senders, tell forwarding from spoofing, and know when you can enforce.

9 min read