TLS report decoder — read TLSRPT aggregate reports in plain English
Paste a TLSRPT JSON aggregate report — the daily file Gmail, Outlook, and other major senders send to your rua address when MTA-STS or DANE is configured on your inbound domain. The decoder parses the policy section, totals the successful versus failed sessions, breaks failures down by result-type (certificate expired, STARTTLS not supported, STS policy fetch error, and the rest of the RFC 8460 catalog), identifies the sending MTAs that experienced the failures, and renders the whole thing as a readable table instead of a screen of raw JSON. No upload; the parsing happens entirely in your browser.
Paste a TLSRPT JSON report
Copy the JSON from any report you have received — Gmail, Microsoft, Yahoo, or any RFC 8460 sender. The parser runs in your browser; nothing leaves your machine.
100% client-side · Nothing is uploaded · Compatible with RFC 8460 reports from Gmail, Outlook, Yahoo, and self-hosted MTAs
TLSRPT is the daily aggregate report mechanism for SMTP TLS — the feedback loop that tells you when senders are failing to deliver mail to your domain over encrypted channels
RFC 8460 — SMTP TLS Reporting, published in September 2018 — defines a JSON aggregate report format that sending mail servers use to tell receiving domains about TLS negotiation failures. The flow is straightforward: you publish a TXT record at _smtp._tls.yourdomain.com containing v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com (or an https endpoint). Major senders — Gmail, Microsoft, Yahoo, and most modern MTAs — read that record when they attempt to deliver mail to your domain, log every TLS event for the day, and send you an aggregate JSON report covering 00:00-23:59 UTC, typically delivered a few hours later. If everything is working, the reports either do not arrive at all (the sender saw no failures) or arrive showing 100% successful sessions.
The report itself is structured. The top-level fields are organization-name (the sender, e.g., "Google Inc."), date-range (start-datetime and end-datetime, both ISO 8601), contact-info (an email at the sender for follow-up), report-id (a unique identifier for the report), and policies (an array of policy objects, one per policy the sender evaluated against your domain). Each policy object carries the policy itself (type sts/tlsa/no-policy-found, the policy string lines, the policy domain, the MX hosts covered), a summary (total-successful-session-count, total-failure-session-count), and a failure-details array with one entry per distinct failure type — result-type (the RFC 8460 enumerated failure code), sending-mta-ip (which of the sender's MTAs hit the failure), receiving-mx-hostname (which of your MX hosts the failure happened at), failed-session-count (how many sessions hit this specific failure), additional-information (a free-text URL with more context, often empty), and failure-reason-code (additional sender-defined detail).
Why this matters in 2026: a TLS failure on inbound mail does not break delivery by default — STARTTLS is opportunistic, so a sender that cannot negotiate encryption typically falls back to plaintext rather than refusing to send. The failure is invisible from your side; mail keeps arriving, and you have no idea your certificate expired or your MTA-STS policy is unreachable. TLSRPT is the only feedback loop that makes that invisibility visible. If you have MTA-STS in enforce mode and your certificate expires on a Sunday afternoon, the TLSRPT report on Monday morning is the only thing that tells you. By the time the report arrives, you have already lost a day of mail; without the report, you would lose every day until someone happens to notice the SMTP errors in their outbound queue.
The reports also matter for compliance posture in 2026. NIS2 and GDPR both emphasize encryption in transit as part of appropriate technical measures; HIPAA explicitly requires it for PHI. A documented TLSRPT-monitored configuration is part of the evidence a security auditor wants to see when reviewing email infrastructure. The decoder above turns the daily JSON into something you can actually read — and forward to the auditor or the on-call engineer who needs to understand it without parsing the RFC themselves.
Every RFC 8460 failure code the decoder may surface, what it means, and what to do about it
starttls-not-supported The sender attempted STARTTLS on the SMTP connection; your MTA did not advertise STARTTLS support in EHLO. Either your MTA is misconfigured (no TLS certificate, TLS module disabled) or the sender connected to the wrong host. Fix: confirm STARTTLS is enabled on every MX listed in your MX record.
certificate-host-mismatch The TLS certificate your MTA presented does not include the hostname the sender connected to (typically your MX hostname). Either the certificate's Subject Alternative Names are missing the MX hostname, or the wrong certificate is bound to the listener. Fix: reissue the certificate to include every MX hostname; verify with openssl s_client -connect mx.example.com:25 -starttls smtp.
certificate-expired The TLS certificate is past its notAfter date. Senders with MTA-STS enforce will refuse to deliver; senders in opportunistic mode may fall back to plaintext or refuse entirely depending on policy. Fix: renew the certificate immediately, automate renewal (Let's Encrypt + certbot, ACM, etc.), and put expiry monitoring in place that alerts 30 days before.
certificate-not-trusted The certificate is valid for the hostname and not expired, but it is signed by an authority the sender does not trust — typically a self-signed cert or a cert issued by an internal CA. Fix: replace with a certificate from a publicly-trusted CA (Let's Encrypt is free and works for SMTP).
validation-failure General TLS validation failure not covered by the more specific codes above — protocol negotiation errors, cipher mismatches, handshake aborts. Less actionable from the report alone; if you see a spike of these, capture packet traces of the failing connection to diagnose.
tlsa-invalid The DANE TLSA record exists for your MX host but does not match the certificate your MTA presented. Specific to DANE; not relevant if you only use MTA-STS. Fix: regenerate the TLSA record after every certificate renewal (or use ACME-TLSA automation).
dnssec-invalid DNSSEC validation failed during DANE TLSA lookup. Either your zone's DNSSEC signatures are expired/invalid, or the path between you and your DNS provider is misconfigured. Fix: confirm DNSSEC validation passes via dnsviz.net or a similar tool; re-sign the zone if needed.
sts-policy-fetch-error The sender attempted to fetch your MTA-STS policy at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and the request failed — HTTP error, certificate problem, DNS resolution failure, or timeout. Fix: confirm the policy URL returns 200 with the correct content-type; check that the mta-sts subdomain resolves; verify the HTTPS certificate on that endpoint is valid.
sts-policy-invalid The MTA-STS policy was fetched but is malformed — missing required fields, invalid mode value, or syntax that violates RFC 8461. Fix: validate the policy with an MTA-STS checker; the policy must start with version: STSv1 and contain valid mode (enforce/testing/none), mx entries, and max_age.
sts-webpki-invalid The HTTPS certificate for mta-sts.yourdomain.com failed validation (expired, wrong hostname, self-signed, untrusted CA). Fix: this is a regular web certificate — renew or reissue from a publicly-trusted CA. The mta-sts subdomain certificate is independent of your MX hostname certificate; both need to be valid.
Single failures rarely matter. Patterns across reports matter. Here is what to look for
Sudden spike of certificate-expired or certificate-not-trusted
Almost always indicates a renewal that did not propagate correctly — the new cert was issued but the MTA was not reloaded, or the cert was deployed to one node of a cluster but not the others. Sudden onset, clear cause; restart the affected service and watch the next day's report show the count drop to zero.
Persistent sts-policy-fetch-error
The mta-sts subdomain has a problem — either it does not resolve, the HTTPS endpoint is down, or the policy file is missing. Persistent because each sender re-fetches the policy at its own cache expiry, so a problem one day shows in the next day's reports across multiple senders. Fix the endpoint; the failures will clear over several days as senders' caches refresh.
Single MTA IP showing failures while others are clean
One of your MX hosts has a different config from the others. Usually a stale node in a cluster — a server that did not get the cert update, a replica that runs an older Postfix version, a backup MX with a different policy file. Look at the receiving-mx-hostname field in the failure details to identify the specific host.
starttls-not-supported from a major sender after months of clean reports
Almost always a sign of a recent operational change — Postfix upgrade, OS patch, cipher policy change that broke TLS negotiation, firewall rule that started dropping the encrypted handshake. The major senders did not change; you did. Look at deploys in the 24 hours before the failures started.
Empty reports — zero failures consistently
The desired state. The TLSRPT record is working (you receive reports), TLS is negotiating successfully (no failure details), and you have visibility into the channel. Keep the reports flowing; the day you start getting non-empty reports is the day you have an actionable signal.
Reading one report is what this tool does. Reading every report every day, alerting on regressions, and triaging the failures to root cause is what the managed workflow does
A TLSRPT report a week is what most inbound domains see when the configuration is healthy. Multiply by every sender, multiply by every domain you operate, and the parsing work scales past what a single person can sustain manually. Our managed deliverability workflow includes automated TLSRPT ingest, daily diff against the previous report to catch regressions, alerting on specific result-types (certificate-expired and sts-policy-fetch-error always page; others depend on volume), and the remediation work — coordinating cert renewals, fixing MTA-STS policy hosting, debugging the failing receiving-mx-hostname — that turns a report into a fix.
The decoder above gives you the one-shot view of one report. If you are seeing failures and want to understand whether they are noise or a real regression, the next conversation is reading the report in context with the previous week of reports — and that conversation goes faster with someone who has already done the diff and identified the change.
Questions teams ask when first reading a TLSRPT report
My report arrives gzipped — how do I decompress it?
+
RFC 8460 specifies application/tlsrpt+gzip for the typical compressed format. On the command line: gunzip report.json.gz. On macOS or Windows, double-clicking the file in the mail attachment typically expands it. Once expanded, paste the resulting JSON into the decoder above. The filename usually follows the pattern sender.example!yourdomain.com!1234567890!1234567891.json.gz — the two numbers are start and end Unix timestamps for the report window.
I receive zero TLSRPT reports. Is that good or bad?
+
Depends on whether you publish the TXT record. If _smtp._tls.yourdomain.com resolves and returns a valid TLSRPTv1 record, zero reports means zero failures — the desired state. If the TXT record is missing or malformed, you receive zero reports because no sender knows where to send them, which is the worst state because you have no visibility either way. Run an MTA-STS / TLSRPT checker against your domain to confirm the record resolves; if it does and reports still do not arrive after 48 hours, send yourself test mail from a Gmail account (or another major sender) and check the inbound spool — if mail arrives but no TLSRPT does, your rua endpoint is the problem.
Should I run MTA-STS in enforce mode or testing mode?
+
Start in testing mode, watch TLSRPT reports for 2-4 weeks to confirm zero failures from major senders, then move to enforce. The risk with going straight to enforce is that any misconfiguration — wrong MX in the policy file, certificate validity issue, mta-sts subdomain unreachable — causes legitimate senders to reject mail to your domain. Testing mode gives you the visibility without the rejection consequence. Once reports are consistently clean, flip to enforce; the additional protection against downgrade attacks and certificate-validation bypasses is worth the operational discipline of monitoring TLSRPT thereafter.
Why don't I receive failure-details for every failed session?
+
TLSRPT is aggregate by design — each failure-details entry summarizes multiple sessions sharing the same result-type, sending-mta-ip, and receiving-mx-hostname, with the count in failed-session-count. Senders are not required to report individual session details to limit report size and protect privacy. If you need session-level detail, correlate the report with your own MTA logs: the date-range field tells you the window, and the receiving-mx-hostname field tells you which of your MX servers to check.
Can senders send fake TLSRPT reports to my rua endpoint?
+
Yes — TLSRPT does not have a built-in delegation verification like DMARC's reporting domain authorization. RFC 8460 specifies that reports sent via SMTP must be DKIM-signed by the reporting domain, so you can validate the signature to confirm the report came from the claimed sender. Reports sent via HTTPS POST are authenticated only by the certificate of the endpoint. Treat report content as untrusted input — do not eval JSON, do not pass values to shell or SQL without sanitization, and rate-limit the endpoint to prevent DoS. The decoder above runs entirely in your browser, so even maliciously-crafted JSON in the input cannot affect anything outside the tab.
Is TLSRPT the same as DMARC RUA reports?
+
No — different protocols, different layers. DMARC RUA reports cover authentication outcomes (SPF and DKIM results, alignment with the From domain) and are sent as XML. TLSRPT reports cover transport encryption outcomes (TLS negotiation success or failure) and are sent as JSON. You typically want both: DMARC tells you who is signing as your domain and whether they pass alignment; TLSRPT tells you whether the senders are reaching you over an encrypted channel. The two reports are complementary, and most senders that emit one also emit the other.