MTA-STS monitoring: watch mail TLS policy before cleartext returns
MTA-STS monitoring is how you notice the mail TLS policy drifted—DNS id gone after a zone rebuild, policy file 404 on mta-sts., or only one half still live—before supporting senders fall back to cleartext again. CrowWake’s check is a public _mta-sts TXT resolve plus an HTTPS fetch of /.well-known/mta-sts.txt, not a full SMTP TLS negotiation.
What MTA-STS monitoring means here
Operators searching for MTA-STS monitoring or an MTA STS checker usually want an early rooster: is v=STSv1 still published at _mta-sts, and does https://mta-sts.yourdomain/.well-known/mta-sts.txt still return a version: STSv1 policy? CrowWake answers both halves and summarizes mode, mx hosts, and max_age when the file is reachable. It sits beside TLS-RPT monitoring and MX monitoring so “policy published,” “reports still arrive,” and “mx: matches live hosts” show up in the same flock.
What CrowWake checks
We resolve TXT at _mta-sts.yourdomain for v=STSv1 id, and we fetch the HTTPS policy file for version: STSv1. Both present → ok (with decoded mode / mx / max_age). Only one side live → warn. Neither → warn (optional but recommended). The free MTA-STS checker uses the same two signals with no login—the same pulse the hourly probe uses. CrowWake does not open an SMTP session to your MX in v1; it watches whether the published policy pair still exists.
Monitoring vs “what is MTA-STS”
The MTA-STS guide explains the DNS id, the policy file shape, testing vs enforce, and the publish order in plain English. Monitoring is the repeat job: catch a deleted _mta-sts TXT after a panel cleanup, a CDN cutover that dropped mta-sts., a cert expiry on that hostname that makes the policy look missing, or a zone copy that published DNS without the file. Both use the same free MTA-STS checker; CrowWake just repeats the pulse every hour. Pair with TLS-RPT monitoring so failures are not silent once mode moves toward enforce.
What “good enough” looks like
DNS id that bumps when the policy changes. A reachable mta-sts hostname with a valid TLS cert serving /.well-known/mta-sts.txt. Policy mx: lines that match real MX (confirm with the free MX checker). Mode testing → enforce when TLS-RPT looks clean. Intentional “no MTA-STS yet” is fine for tiny mailboxes; accidental half-setup after a migration is not—especially once you already published TLS-RPT.
Quick triage when MTA-STS goes yellow or red
1) Re-run the free MTA-STS checker and read DNS-only vs policy-only vs neither. 2) If DNS is missing, restore TXT at _mta-sts with v=STSv1; id=… . 3) If the policy URL fails, point mta-sts.yourdomain at hosting that serves /.well-known/mta-sts.txt over HTTPS (cert errors count as missing). 4) Align mx: lines with live MX hosts. 5) Confirm TLS-RPT with the free TLS-RPT checker. 6) After edits, bump the DNS id, wait for TTL, re-check. 7) 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: missing DNS vs missing policy file are different jobs. Use the MTA-STS how-to for publish order and file shape, re-run the free MTA-STS checker, then keep watching. CrowWake monitors the public policy pair—it does not negotiate SMTP TLS to your MX or rewrite your mail 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 MTA-STS monitoring / policy checker with no login.
Related: what is MTA-STS, TLS-RPT monitoring, TLS-RPT / TLS reporting, MX monitoring, and the free TLS-RPT checker (policy + reports belong together).