What is TLS-RPT? TLS reporting + free TLS-RPT checker
TLS-RPT answers “where should other mail servers send a report when TLS to my MX fails?” Without it, MTA-STS can look published while certificate and hostname mismatches stay invisible. CrowWake’s free TLS-RPT checker is a public _smtp._tls lookup—not a full report-mailbox parser.
What is TLS-RPT (TLS reporting)?
Operators searching for TLS-RPT, what is TLS-RPT, TLS reporting, or tls rpt usually mean SMTP TLS Reporting: a DNS TXT at _smtp._tls.yourdomain that starts with v=TLSRPTv1 and names a rua (mailto: or https:) where senders post failure reports. It is the mail-TLS cousin of DMARC’s aggregate rua—feedback when encryption to your MX did not work the way policy expected.
How to check TLS-RPT (TLS-RPT checker)
1) Run the free TLS-RPT checker on the bare domain (same pulse CrowWake uses). 2) Confirm a v=TLSRPTv1 TXT exists at _smtp._tls—not a random TXT elsewhere. 3) Read the rua mailbox or HTTPS endpoint and verify someone on your team still monitors it (or that your ESP parses it). 4) If MTA-STS is live or moving toward enforce, confirm both halves with the free MTA-STS checker—reports matter most when a policy exists. 5) After any zone edit, re-check; underscore hosts are easy to drop in panel rebuilds.
What CrowWake checks
We resolve TXT at _smtp._tls.yourdomain for v=TLSRPTv1. Missing → warn. Present → ok, with a short summary of the rua destination. The free TLS-RPT checker uses the same DNS lookup with no login. CrowWake does not parse inbound TLS report emails in v1—just whether the reporting pointer is still published. For the repeat “watch this hourly” job, see the dedicated TLS-RPT monitoring guide.
TLS-RPT vs TLS-RPT monitoring
This guide is the definition and publish/triage job: what TLS-RPT is, how TLS reporting works, and how to check TLS-RPT with a free TLS-RPT checker. TLS-RPT monitoring is the earlier rooster—catch a silent wipe or stale rua every hour before MTA-STS failures go unread. Both use the same free checker; CrowWake just repeats the pulse.
Why it matters
Without reports you fly blind: MTA-STS may be published while senders still hit certificate or hostname mismatches. TLS-RPT closes that feedback loop the same way DMARC rua helps for spoofing. Agencies lose _smtp._tls during zone rebuilds and only notice months later when nobody is reading TLS failures—especially once mode moves toward enforce.
What “good enough” looks like
A single TLSRPTv1 record with a mailto: or https: rua you actually read (or that your ESP parses). Pair it with a working MTA-STS policy so the reports mean something. Prefer a mailbox or endpoint your team already monitors—not a throwaway address you will never open.
Publish checklist (order matters)
1) Confirm MX points at the hosts you intend to protect (free MX checker). 2) Publish MTA-STS DNS + HTTPS policy (free MTA-STS checker). 3) Choose a rua mailbox or HTTPS endpoint someone monitors. 4) Add TXT at _smtp._tls with v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain (or https:). 5) Re-check with the free TLS-RPT checker, then add the domain so CrowWake crows if the record disappears.
If CrowWake crows
No TLS-RPT → publish _smtp._tls with your reporting address. Present but reports never arrive → verify the rua mailbox, spam rules, or HTTPS endpoint. After DNS edits, re-run the free TLS-RPT checker and confirm the dashboard turns green. If MTA-STS is also missing or partial, fix that first with the free MTA-STS checker, then re-check TLS-RPT.
Watch this on CrowWake
Add the domain, leave the boxes checked, and the flock will crow when this drifts.
Or try the free TLS-RPT / TLS reporting checker with no login.
Deep dive: TLS-RPT monitoring — watch _smtp._tls so a silent wipe or stale rua crows early, with the same free TLS-RPT / TLS reporting checker.
The free TLS-RPT checker lists the live _smtp._tls pointer. Pair with MTA-STS monitoring, the MTA-STS guide, and the free MTA-STS checker — reports matter most when a policy is published.