TLS-RPT checker:
who gets the failure report?
Enter a domain — we read the TXT record at _smtp._tls, validate every rua= destination as a real URI, then POST a test report at an https endpoint instead of admiring its syntax. And the check most tools skip: is there an MTA-STS or DANE policy for those reports to describe?
Four setups that report nothing
TLS-RPT is one TXT record, which makes it look hard to get wrong. Every one of these is in production somewhere right now, silently delivering zero reports.
The bare address
rua=tls@example.com — a mailbox where a URI must go. Senders skip invalid URIs without a word. One missing mailto: kills the whole record.
scheme requiredReports with no policy
TLS-RPT live, MTA-STS and DANE absent. Some senders still send thin raw-STARTTLS digests — but there's no policy whose failures they could describe, and nothing is protected while you read them.
an alarm, no lockThe dead endpoint
An https: rua pointing at a service that 404s or refuses the POST. Unlike mail there's no queue and no retry guarantee — the report is simply gone.
POST → 404The unread mailbox
Daily gzipped JSON since 2024; opens: zero. Reports only work if something parses them — route them to a tool or a vendor, not a graveyard folder.
*.json.gz × 730Six shapes a TLS-RPT record takes
One record, two URI schemes, and a handful of ways to quietly get zero reports forever.
The mailbox destination: daily reports arrive as gzipped JSON attachments. Human-inspectable, vendor-forwardable — the sane default.
The endpoint destination: senders POST the gzipped JSON directly. Machine-first — and probe-able, which is exactly what we do below.
A bare address is not a URI. Senders don't guess, don't warn, don't bounce — they skip it. The classic TLS-RPT failure.
Same rule as DMARC and MTA-STS: multiple records at _smtp._tls don't merge — discovery is ambiguous and senders see nothing.
A version tag with no destination: a subscription to nowhere. Syntactically it exists; operationally it's indistinguishable from no record.
Valid TLS-RPT with no MTA-STS and no DANE. Publishing reports-first is actually the correct order — as long as step 2 arrives.
The feedback loop behind strict TLS
DMARC has aggregate reports; transport security has TLS-RPT (RFC 8460). Same job: make strictness survivable by telling you what would break before you break it.
- Each reporting sender posts a daily JSON digest: sessions attempted, TLS successes, and every failure classed by cause — starttls-not-supported, certificate errors, policy-fetch failures.
- MTA-STS testing mode is useless without it — a rehearsal nobody watches.
- Unlike DMARC, there is no consent record for external destinations — nothing validates where reports go, so a typo'd destination fails silently, forever. One more reason we probe instead of parse.
- Google has sent these since 2018 — the single largest sender is already offering you the data. The record is how you say yes.
Reading a report
the daily digest, decodedWhat you can check yourself
The record is a dig away. Whether the destinations actually accept a report is the part worth automating.
Common TLS-RPT questions
Type your domain above. We fetch the TXT record at _smtp._tls.yourdomain and confirm exactly one v=TLSRPTv1 with the version tag first. Then we validate every rua= destination as a proper mailto: or https: URI, POST a test report at an https endpoint, and check whether an MTA-STS or DANE policy exists for the reports to describe. Free, no signup, seconds.
TLS-RPT first — it's the rare case where the monitoring goes in before the thing it monitors. MTA-STS testing mode exists to show what would break under enforcement, and that learning arrives only through TLS-RPT reports. Publish the reporting record today. Let a week of baseline data accumulate, then publish the MTA-STS policy in testing and watch what the reports say. A TLS-RPT record with no policy yet isn't a mistake — it's step one, done in the right order.
Both, ideally — the record takes a comma-separated list. mailto: delivers reports as email attachments: readable in a pinch, easy to forward to a vendor, and zero infrastructure to run. https: is a direct machine feed — senders POST the gzipped JSON to your endpoint. That suits dashboards and parsers, but you now run a tiny web service whose failures lose data silently. That last property is why we probe an https destination with a real POST rather than admiring its syntax.
In order of likelihood: the rua is a bare address missing its mailto: scheme, and senders skip invalid URIs silently. Or there are two TXT records at _smtp._tls, so discovery is ambiguous. Or the https endpoint refuses POSTs. Or your domain receives too little mail from reporting senders. And the structural gotcha: TLS-RPT has no DMARC-style consent mechanism, so nothing validates your destination — a typo doesn't error, it erases the feedback loop. Forever.
A gzipped JSON file, one per reporting sender per day. The summary counts sessions that negotiated TLS successfully versus not; the failure-details array is the payload that matters — each entry names the failure type (starttls-not-supported, certificate-expired, sts-policy-fetch-error…), how often it happened, and the IPs involved. It's the difference between "mail feels slow from some senders" and "our backup MX has offered a broken STARTTLS since Tuesday".
Different layer entirely. DMARC aggregate reports are about authentication — who sent mail claiming to be you, and whether SPF/DKIM aligned. TLS-RPT is about transport — whether the encrypted channel to your servers could be established at all. DMARC reports arrive as XML, TLS-RPT as JSON; DMARC has the §7.1 external-destination consent check, TLS-RPT has none. A mature mail domain reads both: one watches who speaks in your name, the other watches whether anyone can speak to you privately.
Google has sent daily TLS reports since 2018, and Gmail carries enough of most domains' inbound mail to give you a usable feed on its own. Microsoft honors MTA-STS outbound, and other large platforms have been adding reporting. Coverage doesn't need to be universal to be useful. A broken STARTTLS config, an expiring MX certificate, a policy-file 404: these show up in any large sender's reports.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.