MTA-STS: SMTP MTA Strict Transport Security
MTA-STS forces sending servers to use TLS when delivering mail to your domain, blocking downgrade attacks that would otherwise let an attacker intercept inbound mail in plaintext.
TL;DR
- Publish a DNS TXT record + an HTTPS-fetched policy file at mta-sts.<your-domain>.
- Senders enforce TLS on every connection to your MX hosts.
- Mode 'enforce' bounces non-TLS delivery; mode 'testing' just reports it.
What it does
SMTP is a 1980s protocol that started cleartext; STARTTLS was added later as an opportunistic upgrade, but the sender can't tell the difference between 'this server doesn't speak TLS' and 'an attacker stripped the STARTTLS line.' MTA-STS closes that gap.
When MTA-STS is enabled, sending servers know your MX hosts MUST be reached over TLS with a valid certificate matching the MX hostname. If TLS fails, the message is queued (testing mode) or bounced (enforce mode), but never sent in cleartext.
Combined with TLS-RPT, MTA-STS gives you both prevention (mail won't go cleartext) and visibility (you see TLS failure reports daily).
How it works
- Publish a TXT record at _mta-sts.<your-domain> with v=STSv1; id=<unique-id>. The id changes every time you update the policy file.
- Host the policy file over HTTPS at https://mta-sts.<your-domain>/.well-known/mta-sts.txt with mode, MX hosts, and max_age.
- Sending servers fetch the policy file once per max_age period, cache it, and enforce it on every subsequent connection to your MX.
- Updating the policy: change the file content, then bump the id in the DNS TXT record so cached copies expire and senders refetch.
Example record
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
Common pitfalls
- Publishing the DNS TXT but not the policy file (or vice versa). Receivers ignore MTA-STS entirely if either piece is missing.
- Setting mode: enforce before all your MX hosts have valid TLS. Triple-check certs, hostnames, and SAN matches before flipping.
- Forgetting to bump the id in the TXT record after updating the policy file. Cached policies stick around for max_age and senders never see the change.
- max_age too short (e.g. 86400 = 1 day). Adds DNS load and policy churn without much benefit. 604800 (1 week) is the production standard.
Related tools
Want PhishFence to monitor MTA-STS for your domains?
Sign up free, add a domain, and PhishFence will continuously check MTA-STS (and the rest of the email-auth stack) for you.