How does MTA-STS prevent downgrade attacks?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
A downgrade attack works like this. An attacker sits between your mail server and the receiving server. When your server sends the signal "Let's encrypt this connection," the attacker strips out that signal. The receiving server doesn't see it. So your server gets no response and assumes encryption isn't available. It sends the email in plain text instead. The attacker intercepts it on the wire. Nobody knows it happened.
This is a real threat because STARTTLS doesn't force encryption. It's a suggestion. If the suggestion goes missing, email flows unencrypted by default. Downgrade attacks exploit that weakness.
Now here's how MTA-STS stops it. Before your server even attempts to connect, it looks up the receiving domain's MTA-STS policy (published in their DNS). That policy says "This domain requires TLS encryption. No fallback. No exceptions." Your server now knows what's required. If encryption fails for any reason, your server refuses to send the email. It bounces instead of downgrading to plain text.
The attacker can't just remove the STARTTLS signal anymore because the policy isn't about what the receiving server offers. The policy is published over HTTPS, which has its own certificate validation. The attacker would need to fake the certificate, impersonate the domain, and intercept the HTTPS lookup. That's much harder than stripping a plain SMTP signal.
The key insight: with enforce mode, you're removing the fallback option entirely. Email either goes encrypted or doesn't go at all. That makes downgrade attacks pointless.
To see if you're protected, check whether your receiving infrastructure has MTA-STS policy enforcement enabled. Use our MTA-STS Checker to verify your domain's policy is active.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
