MTA-STS Checker
Check the MTA-STS record and the hosted policy file.
Enter a domain to check its MTA-STS setup, the DNS record that announces the policy and the policy file that tells sending servers to use TLS. We read both live, over an encrypted connection, and nothing is stored.
This tool inspects the two halves of an MTA-STS deployment for a domain: the DNS TXT record published at _mta-sts.<domain>, and the policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. MTA-STS (RFC 8461) lets a domain tell sending mail servers that inbound mail must be delivered over TLS to named hosts, closing the gap that lets attackers strip encryption or redirect mail via a downgrade.
What the checker looks at
The DNS record must contain v=STSv1 and an id= value. The id is an opaque string you change whenever you update the policy file, so receivers know to re-fetch it. The policy file itself is fetched over HTTPS using a certificate that must be valid for the mta-sts subdomain. It declares version: STSv1, a mode:, one or more mx: patterns matching your real MX hosts, and a max_age: in seconds.
Reading and fixing the result
The mode is the key field. testing reports failures but still delivers; enforce makes receivers refuse delivery to a host that fails TLS or MX matching; none withdraws the policy. Common faults are an mx: list that does not match your published MX records, an HTTPS certificate that is invalid or missing for the subdomain, a max_age that is too short, or a stale id that never changes after edits. Start in testing, watch your TLS-RPT reports, then move to enforce. See our requirements guide or let DMARC Engine host and rotate the policy for you. Pair this with TLS-RPT and your authentication audit.
Frequently asked questions
What is the difference between testing and enforce mode?
In testing mode a receiver that hits a TLS or MX-matching failure still delivers the message but sends you a TLS-RPT report about it. In enforce mode the receiver refuses to deliver rather than fall back to an unencrypted or mismatched connection. Always run a period in testing first.
Why do I need both a DNS record and a policy file?
The DNS TXT record at _mta-sts.<domain> only signals that a policy exists and carries the id. The actual policy, including the MX list and mode, lives in the HTTPS-served file at https://mta-sts.<domain>/.well-known/mta-sts.txt. Both must be present and consistent for MTA-STS to work.
When do I change the id value?
Change the id= in the DNS record every time you edit the policy file. Receivers cache the policy and only re-fetch it when the id changes, so leaving it stale means your updates are ignored. A common convention is a timestamp such as id=20260620T1200.
Why does my policy file fail to load?
The file must be served over HTTPS on the mta-sts subdomain with a certificate that is currently valid for that exact hostname. Self-signed, expired, or mismatched certificates cause the fetch to fail, and the policy is then ignored. Plain HTTP is not accepted.
Does the mx list have to match my MX records exactly?
Each mx: line must match the mail hosts in your published MX records; a leading wildcard such as mx: *.example.net is allowed for one label. If a delivering host is not covered by any pattern, an enforcing receiver treats it as a failure and refuses delivery, so keep the list in sync with your MX.
Is MTA-STS a replacement for DANE?
No. MTA-STS relies on the web PKI and HTTPS, while DANE relies on DNSSEC-signed TLSA records. They solve the same downgrade problem by different means and can coexist; you can check your TLSA records with the DANE checker.