MTA-STS Checker
Validate your MTA-STS DNS record and policy file so inbound mail cannot be downgraded to plain text.
About the mta-sts checker
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain declare that its mail servers require TLS with a valid, trusted certificate, and instructs sending servers to refuse delivery rather than fall back to an unencrypted or unauthenticated connection. This closes a gap that plain STARTTLS leaves open: STARTTLS on its own can be silently stripped by an attacker in the middle, since nothing forces a sender to insist on it.
Two pieces have to line up. First, a DNS TXT record at _mta-sts.yourdomain.com announces that a policy exists and gives it a version id. Second, an HTTPS-hosted policy file at a fixed URL under a mta-sts subdomain lists the exact mail server hostnames and the enforcement mode. This tool fetches and validates both. The mode field controls behavior: testing reports failures without blocking delivery, letting you find problems safely, while enforce actually rejects delivery attempts that cannot be secured. Moving from testing to enforce should happen only after TLS-RPT reports (a companion mechanism) come back clean for a reasonable period.
Because the policy file is fetched over HTTPS from a fixed hostname, that hostname's own certificate has to be valid too; an expired or mismatched certificate on the policy host breaks MTA-STS even if the mail servers themselves are configured correctly. Because both pieces must be correct at once for MTA-STS to work at all, this tool checks the DNS record and the policy file together rather than in isolation, so a mismatch between the two is caught immediately instead of surfacing later as silent delivery failures.
Common questions
- What is MTA-STS?
- A policy declaring that a domain's mail servers require TLS with a valid certificate, published as a DNS record plus an HTTPS-hosted policy file, so senders cannot be tricked into delivering mail unencrypted.
- What does mode: testing do?
- Senders that support MTA-STS report failures through TLS-RPT but still deliver the mail. It is meant as a safe rollout phase before switching to enforce.
- Do I need TLS-RPT too?
- It is strongly recommended. Without it you have no visibility into delivery failures caused by your MTA-STS policy, and you would only find out about problems from complaints.
- Why does the policy file need its own valid certificate?
- The policy is fetched over HTTPS, so if the certificate on the policy hostname is invalid or expired, senders cannot retrieve the policy at all and MTA-STS effectively stops working.
What this tool checks (8 rules)
- email.mta-sts.max-age-too-low — MTA-STS max_age is very short
- email.mta-sts.mode-none — MTA-STS policy mode is none
- email.mta-sts.mode-testing — MTA-STS policy is still in testing mode
- email.mta-sts.mx-not-covered — A live MX host is not listed in the MTA-STS policy
- email.mta-sts.no-record — No MTA-STS policy published
- email.mta-sts.policy-invalid — MTA-STS policy file is malformed
- email.mta-sts.policy-unreachable — MTA-STS policy file cannot be fetched
- email.mta-sts.record-invalid — MTA-STS DNS record is malformed