What are limitations of MTA-STS deployment?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
MTA-STS (Mail Transfer Agent Strict Transport Security) sounds like the answer to all your email security problems. It's not. Here's what it actually does, and what it can't.
It only works if the sender checks for it. MTA-STS is voluntary on the sender side. Big mailbox providers like Gmail and Outlook do check it. Smaller mail systems and corporate servers often don't. So if your policy says "enforce encrypted connections," a sender using old infrastructure might ignore it completely and send anyway.
It doesn't protect your actual messages. MTA-STS secures the connection between mail servers. It doesn't encrypt your email content, sign it, or verify who sent it. That's what authentication protocols like DMARC do. MTA-STS is the bouncer at the door, not the vault inside.
Caching creates delayed updates. Once a sending server caches your policy, it won't re-fetch it until `max_age` expires. If you need to change your rules in an emergency, not everyone sees it right away. You're stuck waiting.
You need HTTPS infrastructure. You'll run a web server hosting your policy file on your domain with a valid TLS certificate. If your certificate expires, your whole MTA-STS policy stops working. That's maintenance overhead most senders take for granted until it breaks.
It doesn't catch a compromised receiving server. If someone gains access to the mail server at the receiving domain, MTA-STS can't help. That's what DANE and TLS reporting handle.
Bottom line. MTA-STS is one layer in a larger security stack. It's solid, but it's not a complete solution on its own.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
