Dr.Who

tls-rpt checker

look up a domain's TLS-RPT (SMTP TLS Reporting) policy at _smtp._tls.<domain> — version tag and reporting URIs. part of the drwho.me domain dossier.

Overview

TLS-RPT (RFC 8460) is the reporting companion to MTA-STS and STARTTLS-Everywhere. it lets domain owners receive machine-readable reports from sending MTAs about TLS connection failures on inbound mail delivery — analogous to what DMARC's `rua=` does for email authentication, but for transport-layer TLS failures. the policy is published as a TXT record at `_smtp._tls.<domain>` containing `v=TLSRPTv1` and one or more `rua=` reporting URIs. the uri can be a `mailto:` address or an `https:` endpoint that accepts JSON reports in the format defined by RFC 8460. senders aggregate daily counts of connection attempts, successful TLS negotiations, and failures (by failure type and MX pattern) and POST the report to each rua uri. this tool queries the TXT rrset via cloudflare's doh resolver, validates the `v=TLSRPTv1` prefix, and parses the `rua=` list. TLS-RPT gives you visibility into whether your MTA-STS policy is being enforced correctly in the wild — you won't see silent delivery failures without it.

How to use

  1. enter a bare domain — public fqdn only. no scheme, no port.
  2. check for the TXT record — the tool queries `_smtp._tls.<domain>` TXT. a valid record starts with `v=TLSRPTv1`.
  3. read the rua list — each `rua=` uri is a reporting destination. `mailto:` uris receive email reports; `https:` uris receive JSON POSTs. most operators use a specialised reporting service or a monitored alias.

Examples

example 1 — google's TLS-RPT policy — they report to their own inbox for aggregation.
input
gmail.com
output
v=TLSRPTv1; rua=mailto:smtp-tls-report@google.com
example 2 — most domains haven't published TLS-RPT. absence is a finding, not a test failure.
input
domain without TLS-RPT
output
no TXT record at _smtp._tls.<domain> — check returns not_applicable

Common mistakes

  • TLS-RPT without MTA-STS is still useful — even if you haven't deployed MTA-STS, TLS-RPT reports capture opportunistic-TLS failure rates from major senders. this is the cheapest way to find out whether a misconfigured mail server or a certificate expiry is silently breaking TLS for inbound mail.
  • reports are sent by the SENDER's MTA, not yours — you publish the `_smtp._tls` record; senders send the reports to your rua. this means you only get reports from MTAs that support TLS-RPT — smaller or legacy senders may never send you anything. google, microsoft, and protonmail send TLS-RPT reports.
  • the reporting URI must be publicly reachable — if your `rua=mailto:` address bounces, or your `rua=https:` endpoint returns non-2xx, the sending MTA will drop the report silently. test the rua address exists and the https endpoint is up before publishing the policy.

FAQ

what does a TLS-RPT report look like?

a JSON document (RFC 8460 §4) delivered daily. it lists the reporting org, the policy domain, the date range, and per-mx-pattern summaries of total session counts, successful TLS negotiations, and failures broken down by failure-type (starttls-not-supported, certificate-expired, validation-failure, etc.).

how is TLS-RPT different from DMARC's rua?

DMARC rua reports cover email authentication (SPF/DKIM alignment failures). TLS-RPT reports cover transport-layer TLS failures during SMTP delivery. they're complementary. a domain with both gets failure visibility at two different layers of the mail stack.

can I use the same address for both DMARC rua and TLS-RPT rua?

technically yes — both deliver JSON. in practice the report schemas differ enough that most operators use a dedicated address or a reporting service that handles both formats separately (e.g. Postmark DMARC Digests, DMARC Advisor).

does TLS-RPT require MTA-STS to be useful?

no. TLS-RPT works independently. even on a domain with only opportunistic STARTTLS and no MTA-STS policy, senders that support TLS-RPT will send reports about any TLS failures they encounter. the report's `policy-type` field will be `no-policy-found` in that case.

can ai agents call this?

yes — dossier_tlsrpt on the mcp endpoint at drwho.me/mcp/mcp.

Related tools

  • mta-sts checker — fetch and validate a domain's MTA-STS policy (mode, mx, max_age).
  • mx lookup — list the mail exchangers (MX records) a domain advertises, sorted by priority.
  • tls certificate checker — inspect a domain's TLS certificate: subject, issuer, validity, SANs, fingerprint.

References

  1. RFC 8460 — SMTP TLS Reporting
  2. RFC 8461 — MTA-STS (context for TLS-RPT deployment)
ad slot · tool-tlsrpt-checker