TLS-RPT monitoring: watch TLS reporting before failures go silent
TLS-RPT monitoring is how you notice the TLS reporting pointer drifted—deleted after a zone rebuild, republished without a reachable rua, or never restored after a mail-host move—before MTA-STS failures stop landing in anyone’s inbox. CrowWake’s check is a public _smtp._tls TXT resolve, not a full report-mailbox parser.
What TLS-RPT monitoring means here
Operators searching for TLS-RPT monitoring, TLS reporting, or a TLS-RPT checker usually want an early rooster: is v=TLSRPTv1 still published at _smtp._tls, and does it still point at a rua someone reads? CrowWake answers with a public TXT lookup and a short summary of the rua destination. It sits beside MTA-STS so “policy published” and “reports still arrive somewhere” show up in the same flock.
What CrowWake checks
We resolve TXT at _smtp._tls.yourdomain for v=TLSRPTv1. Missing record → warn. Present → ok, with a summary of the rua mailbox or HTTPS endpoint. The free TLS-RPT checker uses the same DNS lookup with no login—the same signal the hourly probe uses. CrowWake does not parse inbound TLS report emails in v1; it watches whether the reporting pointer still exists.
Monitoring vs “what is TLS-RPT”
The TLS-RPT guide explains TLS reporting, the _smtp._tls name, and how to publish a rua in plain English. Monitoring is the repeat job: catch a deleted record after a panel cleanup, a zone copy that dropped underscore hosts, or a mailbox cutover that left rua pointing nowhere useful. Both use the same free TLS-RPT checker; CrowWake just repeats the pulse every hour. Pair with MTA-STS so reports mean something when TLS to your MX fails.
What “good enough” looks like
A single TLSRPTv1 record with a mailto: or https: rua your team actually monitors (or that your ESP parses). Pair it with a working MTA-STS policy so failure reports are not noise. Intentional “no TLS-RPT yet” is fine while you are still shaping MTA-STS; accidental empty after a migration is not—especially once mode moves toward enforce.
Quick triage when TLS-RPT goes yellow or red
1) Re-run the free TLS-RPT checker and confirm missing vs present rua. 2) If missing, restore TXT at _smtp._tls with v=TLSRPTv1 and a mailbox or HTTPS endpoint someone reads. 3) If present but reports never arrive, verify the rua mailbox/spam rules or HTTPS endpoint. 4) Confirm MTA-STS DNS + policy with the free MTA-STS checker—reports matter most when a policy is live. 5) Wait for DNS TTL, re-check. 6) Add the domain so CrowWake crows on the next wipe instead of discovering silence months later.
If CrowWake crows
Treat the failing check as source of truth: empty _smtp._tls vs a stale rua you no longer monitor are different jobs. Use the TLS-RPT how-to for record shape, re-run the free TLS-RPT checker, then keep watching. CrowWake monitors the public reporting pointer—it does not open your TLS report emails or fix MX certificates for you.
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 monitoring / TLS reporting checker with no login.
Related: what is TLS-RPT / TLS reporting / how to check TLS-RPT, MTA-STS monitoring, MTA-STS, MX monitoring, and the free MTA-STS checker (policy + reports belong together).