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.
Diagnosing enforced TLS for mail delivery (MTA-STS)
Encryption in SMTP is by origin an optional affair, attempted where possible, which means an attacker in the middle who strips the STARTTLS announcement can force the exchange down to plain text. MTA-STS is the arrangement that closes this off, **instructing sending servers that mail for the domain must go over TLS.** This tool fetches both the `_mta-sts` TXT record and the policy file, and reports whether the configuration is complete.
**What confuses people about the arrangement is that the policy itself is not kept in DNS.** All the TXT record carries is an `id` marking the version; **the substance is served over HTTPS from `https://mta-sts.yourdomain/.well-known/mta-sts.txt`.** The trust in this mechanism therefore rests on web certificates rather than on DNS. **And the commonest place to get stuck is leaving `mode` at `testing`.** In that state delivery goes through regardless of a TLS failure, and **enforcement only takes effect once the value is `enforce`.** The settled order of adoption is to stay at `testing`, watch the TLS-RPT reports until you are satisfied nothing is breaking, and only then move to `enforce`.
How to use it
- Enter the domain Give the domain alone, in the form `example.com`.
- Check the TXT record **Look for `v=STSv1` and an `id=`.** The `id` is changed every time the policy is updated.
- Read the contents of the policy file Three entries appear: `mx`, `max_age` and `mode`.
- Confirm the mode **At `testing`, nothing is being enforced.** Reaching `enforce` is what gives the policy effect.
Tips for getting more out of it
- 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.
Where it comes in useful
Inspecting your own domain
**Since the mechanism needs both DNS and HTTPS in place, you can find whichever half is missing.**
Checking before moving to enforce
Mistakes in the configuration can be cleared away while still at `testing`.
Reviewing after adding an MX
**Forgetting to add a new MX host to the policy's `mx` list means delivery to that host is refused.**
Learning how far a correspondent has gone
You can see whether they enforce TLS on their own mail.
MTA-STS terms
- _mta-sts TXT
- **The DNS record carrying the `id` that marks the policy version.** The policy itself is not kept here.
- Policy file
- The substance, placed at `https://mta-sts.yourdomain/.well-known/mta-sts.txt`. **Being served over HTTPS, it requires a valid certificate.**
- Mode
- One of `enforce`, `testing` or `none`. **Under `testing`, mail is delivered even when the check fails.**
- Max_age
- How many seconds a sender may cache the policy. A longer value strengthens the protection but slows the spread of any change.
- Mx
- The list of MX hosts on which TLS is to be enforced. **Delivery to a host absent from this list is refused.**
- STARTTLS downgrade
- The attack in which a party in the middle strips the STARTTLS announcement to force plain text. **MTA-STS was devised to prevent it.**
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.