MTA-STS

How it works

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain declare that inbound SMTP requires TLS with a valid certificate, closing the downgrade hole in opportunistic TLS. The domain publishes a TXT record at _mta-sts.<domain> carrying a policy ID, and serves the policy itself over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt, listing the permitted MX hosts and a mode of testing, enforce, or none. A sending MTA fetches and caches the policy, and thereafter refuses to deliver over an unencrypted or improperly certified connection. TLS-RPT (RFC 8460) is its companion reporting channel, returning daily reports of TLS negotiation failures.

When it matters

It matters because STARTTLS is strippable: an active network attacker removes the TLS offer and a sending MTA silently falls back to plaintext. MTA-STS is the caching policy that makes that downgrade fail instead. It protects mail arriving at your domain, which makes it complementary to SPF, DKIM, and DMARC, all of which address sender identity rather than transport. See The Email Authentication Stack.

Common misconceptions

• "It encrypts my mail end to end." It enforces transport encryption between mail servers. The message is plaintext at rest on both ends.
• "Publishing the DNS record is enough." The policy file must be served over HTTPS on the mta-sts subdomain with a valid certificate. A broken policy host means no protection, with no error.
• "`testing` mode is a reasonable resting place." It reports failures without enforcing. Like DMARC's p=none, it is a staging step, and a policy left there indefinitely protects nothing.