MTA-STS Policy Checker
Fetches a domain's _mta-sts TXT record and mta-sts.txt policy file to diagnose whether MTA-STS (mandatory TLS encryption for inbound mail) is configured correctly.
Tips
- MTA-STS is enforced by the sending server, not the receiving one. Once you publish it, other people's servers will start requiring TLS when they send mail to your domain.
- Roll out mode: testing for a few weeks to a month before switching to enforce, so an unexpected delivery rejection doesn't catch you off guard.
- max_age is usually set between 604800 seconds (7 days) and 31557600 seconds (1 year). Too short a value forces frequent re-fetches of the policy file.
- You can use a wildcard (*.example.com) in the mx field, but the TLS certificate's SAN (Subject Alternative Name) must match that wildcard.
- Publishing only the DNS record or only the policy file does nothing — MTA-STS only takes effect once both are present.
FAQ
Side Note — Why STARTTLS wasn't enough, and how MTA-STS came about
For decades, encryption in transit for SMTP relied on STARTTLS (standardized in 1999), which opens a connection in plaintext and only later upgrades it to TLS. In 2014, researchers confirmed real-world "STARTTLS stripping" attacks: because the STARTTLS negotiation itself happens before encryption kicks in, an on-path attacker could rewrite the server's response to hide its STARTTLS support, tricking the other side into falling back to plaintext.
The root cause was STARTTLS's deliberate design to gracefully fall back to plaintext when a peer doesn't support TLS — a compatibility feature attackers could exploit by simply pretending the peer had no TLS support at all. Around 2015, Google's own measurements showed STARTTLS stripping happening at scale in certain countries and on certain ISPs.
MTA-STS (RFC 8461, published 2018) was the industry's answer, jointly developed by Google, Microsoft, Yahoo and others. A domain declares MTA-STS support via a DNS TXT record, then publishes an HTTPS-fetched policy file listing its permitted MX hosts and TLS requirements. Once fetched, the policy is cached for max_age, so a subsequent downgrade attempt can be detected and rejected rather than silently accepted.
MTA-STS is commonly paired with TLS-RPT (TLS Reporting, RFC 8460), which lets domain owners receive reports whenever a sending server fails to establish TLS. MTA-STS is the enforcement layer; TLS-RPT is the observability layer — running both together is today's recommended practice.