TLS-RPT report explained — what “result-type” and “failure-details” mean

Your TLS-RPT reporting address is receiving files, but they arrive as gzip-compressed JSON full of unfamiliar fields like “result-type” and “failure-details”, and you don't know what counts as a real problem.

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

A TLS-RPT report is a JSON document (media type application/tlsrpt+json, typically delivered gzip-compressed as application/tlsrpt+gzip) summarizing, per sending domain and per day, how many connections succeeded and how each failure was classified. The key field is result-type inside each failure-details entry, and RFC 8460 defines a fixed set of values — three of the most common in practice are starttls-not-supported (the receiving server doesn't offer STARTTLS at all), certificate-host-mismatch (the TLS certificate doesn't match the hostname being connected to) and validation-failure (a general certificate-chain or negotiation problem). Each points to a different fix on the receiving side, which is why the raw failure count alone isn't actionable. Source: RFC 8460 §4.3 “Result Types” · verified 2026-07-17.

What to do about it

Step 1. Decompress the report (it's gzip) before trying to read it as plain JSON — most “broken report” complaints are just an unzipped-gzip step.
Step 2. Treat starttls-not-supported failures as informational if they point at a receiving server you don't control — the fix isn't on your side.
Step 3. Treat certificate-host-mismatch or validation-failure reported against your own outbound mail as something to raise with your outbound mail infrastructure provider.
Step 4. Watch the daily failure-count trend, not a single day's snapshot — one-off failures during a receiver's own maintenance are normal; a sustained rise against one receiving domain is the signal worth acting on.

Frequently asked

Do TLS-RPT and MTA-STS replace DMARC?

No. DMARC authenticates who is allowed to send as your domain; TLS-RPT and MTA-STS protect how mail travels in transit between servers. They're complementary, independent DNS records — not substitutes for each other.

Do I need both TLS-RPT and MTA-STS, or just one?

They work well together but are independent: TLS-RPT is reporting-only (you find out about failures), MTA-STS is enforcement (failing connections get blocked in enforce mode). Most domains set up TLS-RPT first to see what's actually happening before committing to MTA-STS enforce mode.

Will either of these break mail delivery if I get it wrong?

TLS-RPT can't break anything — it's report-only. MTA-STS in enforce mode can, if your policy file lists the wrong MX hosts or your mta-sts. subdomain's certificate is invalid — which is exactly why RFC 8461 and every practical guide recommend a testing-mode period first.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →