MTA-STS Policy Checker
Enter a domain to validate its MTA-STS deployment: the _mta-sts TXT record and the policy served at https://mta-sts.<domain>/.well-known/mta-sts.txt. MTA-STS lets you require TLS for inbound SMTP, closing the opportunistic-TLS downgrade gap that lets a network attacker strip encryption.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- The _mta-sts TXT record and its policy id
- Whether the .well-known policy file is reachable over a valid certificate
- The enforcement mode — enforce, testing, or none
- The covered MX hosts and the max_age
How to read the result
- OK = mode=enforce with a reachable policy — senders must use valid TLS to your MX.
- Warn (testing) = failures are only reported, not enforced; move to enforce when reports are clean.
- Warn (TXT but no policy) = DNS advertises MTA-STS but the policy file isn't reachable/valid.
- Warn (none) = no MTA-STS; senders fall back to strippable opportunistic TLS.
Frequently asked questions
What does MTA-STS protect against?
SMTP normally uses opportunistic TLS, which a man-in-the-middle can strip (downgrade to plaintext). MTA-STS tells senders your MX must present valid TLS, so they refuse to deliver in the clear.
What's the difference between testing and enforce mode?
In testing mode senders report TLS failures via TLS-RPT but still deliver; in enforce mode they refuse delivery if TLS/MX validation fails. Start in testing, then move to enforce once TLS-RPT looks clean.
Why is my TXT record present but the check still warns?
The policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt must return 200 over a certificate valid for mta-sts.<domain>. If it's unreachable or the cert is wrong, senders can't apply the policy.
Does MTA-STS need DNSSEC?
No — MTA-STS relies on the Web PKI (a valid HTTPS cert for the policy host), which is why it's often deployed instead of (or alongside) DANE, which does need DNSSEC.