TLS-RPT check: is SMTP TLS reporting published?
Enter a domain and AdminKit's free tool checks whether it publishes a live TLS-RPT record, reading back the real report destination (mailto or https) it declares, because without TLS-RPT a failing TLS delivery — including one blocked by this domain's own MTA-STS policy — stays invisible to whoever owns the domain.
Part of the Email authentication cluster — more tools, guides and terms on email authentication.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
What the result means
"Not published" just means no _smtp._tls record exists yet — nothing is broken. "No 'rua'
destination" means the record exists but can't actually deliver any reports, which is a real gap worth
fixing: any TLS failure a sender hits while delivering to this domain has nowhere to be reported.
Next step
See how BIMI, MTA-STS and TLS-RPT fit together, check whether this domain's MTA-STS policy is the one generating the failures TLS-RPT would report, or check its DMARC policy next.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
This tool calls AdminKit’s live Check API (POST /v1/check/mail) and reads back the TLS-RPT
sub-check: a real DNS lookup for the _smtp._tls.<domain> TXT record, done by AdminKit’s backend, not by code
running in your browser. TLS-RPT (SMTP TLS Reporting) is defined in
RFC 8460.
How it works
TLS-RPT is a single DNS TXT record at _smtp._tls.<domain>, with a v=TLSRPTv1 tag identifying it and an rua
tag listing where to send reports:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"rua can list one or more destinations, each either a mailto: address or an https: endpoint — a sending
server that encounters a TLS failure while delivering to this domain (a certificate problem, a failed STARTTLS
negotiation, or a delivery blocked by this domain’s own MTA-STS policy, defined in
RFC 8461) periodically mails or posts a JSON report describing it there.
TLS-RPT is reporting-only: it does not itself require or enforce TLS on anything. If the record is missing,
the tool reports it as not published. If the record exists but its rua tag is missing or empty, the tool
reports it as published, but no ‘rua’ destination — a record that can’t actually deliver any reports even
though it technically exists.
Limits
- This checks whether the record itself is published and well-formed — it does not wait for or show you an actual TLS failure report, since those only arrive from real sending servers over time.
- No query is logged; see /legal/privacy/.
TLS-RPT is almost always deployed alongside MTA-STS rather than on its own — MTA-STS without TLS-RPT means a misconfigured policy can silently block legitimate mail with no way for the domain owner to find out. See BIMI, MTA-STS and TLS-RPT explained for how all three fit together, and check your DMARC policy next — DMARC, MTA-STS and TLS-RPT are independent records that each protect a different part of mail delivery.
Frequently asked questions
Does TLS-RPT itself enforce anything?
No — RFC 8460 §1 describes TLS-RPT purely as "a reporting mechanism" that lets a domain "publish a policy for receiving reports." It never blocks, delays or alters mail delivery on its own; it only tells senders where to mail a summary of TLS failures they encountered. Enforcement, if any, comes from a separate record — usually MTA-STS.
What's the difference between TLS-RPT's 'rua' and DMARC's 'rua'?
They're separate reports about separate things, even though both reuse the 'rua' tag name: DMARC's rua (RFC 7489 §6.3) requests aggregate reports about SPF/DKIM alignment and spoofing, while TLS-RPT's rua (RFC 8460 §3) requests aggregate reports about failed TLS negotiations during delivery. A domain publishing both gets two independent report streams at two independent DNS names.
Can TLS-RPT's 'rua' point to a URL instead of an email address?
Yes — RFC 8460 §3 defines 'rua' as a comma-separated list of URIs, explicitly allowing both 'mailto:' and 'https:' schemes for where the JSON report is delivered. A domain can collect reports at an HTTPS endpoint instead of an inbox, which is what this tool's 'https:' example demonstrates.
If MTA-STS is already set to mode=testing, do I still need TLS-RPT?
Yes, more than ever at that stage — RFC 8461 §5 says testing mode asks senders to apply the policy's checks but "SHOULD NOT act with regard to policy violations," meaning failures are reported, not blocked, and TLS-RPT is the only channel that reporting actually travels over. Running MTA-STS in testing without TLS-RPT published means no failure ever reaches the domain owner, defeating the point of a testing phase.