Inputs
Example
example.com -> _mta-sts TXT id, https://mta-sts.example.com/.well-known/mta-sts.txt, MX coverage, and starter policy.
MTA-STS Checker/Generator
Assess MTA-STS TXT and HTTPS policy files, compare MX coverage, and return conformance findings with remediation warnings.
Use it before changing MTA-STS DNS or policy files so TXT, HTTPS policy, MX coverage, and rollout mode line up.
Why MTA-STS needs three things to be true at once
MTA-STS closes a real gap: SMTP falls back to plaintext or unauthenticated TLS by default, and a network attacker can exploit exactly that downgrade. The mechanism is simple to describe and easy to misdeploy, because it lives in three places that must agree — a _mta-sts TXT record whose id announces policy changes, an HTTPS policy file at a fixed well-known URL on the mta-sts subdomain, and mx entries in that policy which must cover the hosts your MX records actually point at. Any one of the three drifting turns a security control into a delivery risk.
This checker reads all three surfaces for a domain and reports them as one deployment: TXT syntax and id, policy mode and max-age, MX coverage against your real MX set, and optional TLS-RPT context. It also produces a conservative starter draft for a staged rollout, so the first published policy is one that observes rather than enforces.
Staged rollout without breaking delivery
Work from pasted values while designing: TXT record, policy text, and known MX hosts can all be checked locally before anything is published. The coverage comparison is the part to take seriously — enforce mode with an MX host missing from the policy is the classic self-inflicted outage, and it is precisely the mistake a pre-publication diff catches.
Roll out in the proven order: publish in testing mode with TLS-RPT reporting, watch the reports long enough to trust that legitimate senders reach covered hosts over verifiable TLS, then switch to enforce and raise max-age gradually. Every policy change needs a new TXT id — senders cache the policy for max-age, and the id is the only signal telling them to refresh. Re-run the check after each step; the live mode shows what senders currently resolve and fetch.
Lookup routes and deliberate boundaries
Pasted records and policy text stay local. Live checks resolve DNS through Cloudflare DNS-over-HTTPS from the browser first, with the same-origin DNS fallback if that path fails, and fetch the policy only from the fixed mta-sts.<domain>/.well-known/mta-sts.txt URL through the same-origin helper. No SMTP session is opened and no delivery test is performed — the tool verifies the published policy surfaces, not your mail server's TLS handshake, which is the SMTP TLS readiness checker's job.
Frequently asked questions
What does the TXT id actually do?
It is a cache-busting version marker. Senders cache the HTTPS policy for max-age seconds and only refetch early when the id changes — so a policy edit without a new id can go unnoticed until caches expire.
Which mode should the first published policy use?
Testing. It asks senders to evaluate the policy and report failures without changing delivery behavior, which turns misconfigurations into report lines instead of bounced mail.
Why is MX coverage the critical check?
Because the policy's mx entries define which receiving hosts are legitimate. If your real MX hosts are not covered, an enforcing sender treats delivery to them as a policy failure — and in enforce mode that mail stops.
How should max-age be chosen?
Short at first — long enough to be honored, short enough that a broken policy ages out quickly. Once enforce has been stable, raising max-age hardens the domain against downgrade windows between fetches.
Is TLS-RPT required for MTA-STS?
No, but running MTA-STS without it means enforcing policy blind. TLS-RPT delivers aggregate failure reports — the only routine feedback channel that shows senders failing your policy before users notice missing mail.
How does MTA-STS relate to DANE?
Both defeat SMTP downgrade attacks. DANE anchors trust in DNSSEC-signed TLSA records; MTA-STS anchors it in HTTPS and the web PKI. They can coexist — senders that support DANE typically prefer it, and MTA-STS covers the large sender population that does not.