TLS-RPT report reader
Open SMTP TLS reports and see which senders couldn’t reach your mail servers over TLS, why, and whether mail was likely held back. Files are read in your browser and never uploaded.
By using these tools you accept the Terms and the Privacy page.
How the TLS-RPT report reader works
The TLS-RPT report reader turns the JSON reports that sending servers mail to your TLS-RPT address into totals, findings and tables. It is for domain owners who run MTA-STS or DANE, or plan to, and want to know which senders could not reach their MX servers over a checked TLS connection.
What it reads
The reader decides what a file is from its content, not its name: a ZIP or gzip signature, JSON that starts with a brace, or an email with headers. In an email it opens parts of type application/tlsrpt+gzip or application/tlsrpt+json, and attachments named .json, .gz or .zip. Only stored and deflate ZIP entries are supported; password-protected entries and ZIP64 archives are listed with the reason.
Fields are read by the names RFC 8460 gives them: organization-name, date-range, contact-info, report-id, and for each policy its policy-type, policy-string, policy-domain, mx-host, summary counts and failure-details. Real reports vary, so counts sent as text and an mx-host sent as one string are accepted. A count that is negative, a fraction or not a number is counted as 0 and the report gets a note. The MTA-STS mode comes from the mode: line of the policy-string.
What the summary shows
- Totals across every report: sessions, successful and failed sessions, the failure rate, policy domains and sending organizations, with the dates covered in UTC.
- Findings, most serious first: each result type that appears, what it means, how to fix it and which checker helps.
- A table per policy domain and policy, with MX patterns, counts and failure rate, and a failures table you can sort by result, sending IP, receiving host or sessions.
- Two CSV files: the failures and the per-policy summary.
How the delivery effect is judged
A failure under a DANE policy, or under MTA-STS in enforce mode, is marked as likely delayed or not delivered, since senders must not deliver to that host. A failure in testing mode is marked as delivered anyway. A failure to fetch, authenticate or parse the MTA-STS policy, or a failure with no policy found, does not block delivery by itself, but the mail may not have been protected. The report doesn’t say what happened to each message, so these marks follow the RFCs, not the sender’s logs.
Limits that keep your browser responsive
- Up to 500 files and archive entries, and 128 MB, in one go. Each file or entry may be or expand to 16 MB, and archives inside archives open up to four levels deep.
- JSON may nest 32 levels. Up to 1,000 policies per report are read, and failure details are kept up to 10,000 per policy and 100,000 in one go; totals still come from each report’s summary.
- Text values longer than 1,000 characters are cut short, names and IDs at 255. Tables show the first 500 rows; the CSV has the rest.
What it doesn’t check
The reader doesn’t prove a report is genuine, look anything up in DNS or connect to your servers. Test the fixes with the TLS checker and the DANE checker, check MTA-STS and your TLS-RPT record with the domain score, and read DMARC reports with the DMARC report reader.
Updated · Maintained by Hertza L.L.C.
Questions
What is TLS-RPT?
SMTP TLS Reporting (RFC 8460) lets servers that send mail to your domain tell you whether they could set up an encrypted connection to your MX servers. Each report is a JSON file, usually covering one UTC day, with session counts per policy and details of the failures. It goes with MTA-STS (RFC 8461) and DANE (RFC 7672), which tell senders to require TLS.
How do I start getting TLS reports?
Publish a TXT record at _smtp._tls. in front of your domain, for example v=TLSRPTv1; rua=mailto:tlsrpt@example.com. The rua address can also be an https URL. Senders that support TLS-RPT then send reports there. The domain score checks the record and your MTA-STS policy.
Who sends TLS reports?
Mail providers that support TLS-RPT, such as Google and Microsoft, send them for the mail they sent to your domain. Each report comes from one organization and lists its sessions to your MX hosts. Senders without TLS-RPT support send nothing, so the reports show only part of your inbound mail.
What do the result types mean?
starttls-not-supported means your server didn’t offer STARTTLS. The certificate types (host mismatch, expired, not trusted) mean the certificate check failed; validation-failure is any other failure that fits none of the types. tlsa-invalid, dnssec-invalid and dane-required are DANE problems. sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid mean the sender couldn’t fetch or use your MTA-STS policy. The reader explains each one and what to fix.
Was my mail lost when a session failed?
It depends on the policy. Under DANE, or MTA-STS in enforce mode, senders don’t deliver to a host that fails the checks: they try another MX host or queue the mail and retry, and return it if the failure lasts. In testing mode, or with no policy, senders still deliver. The reader marks each failure with its likely effect.
Are my report files uploaded?
No. Unzipping, decompressing and reading the JSON all happen in your browser. Nothing from the files is sent to zerobounce.ai or anywhere else.
Which files can I open, and how large?
The .json report, the .json.gz or .gz it arrived as, a .zip of reports, the whole report email as .eml, or pasted JSON. Up to 500 files and 128 MB in one go; each file or archive entry may expand to 16 MB. Reports from the same organization with the same report ID are counted once.