MTA-STS — Enforcing TLS Instead of Just Offering It

The problem MTA-STS solves

STARTTLS is optional and negotiated in plaintext. An attacker in a man-in-the-middle position can simply strip the STARTTLS announcement from the SMTP dialogue. The sending server then sees a recipient that apparently cannot do TLS and delivers the message unencrypted — no error, nobody notices. This downgrade attack is the central weakness of email transport encryption.

MTA-STS (RFC 8461) closes the gap. You publish a policy stating: TLS is mandatory for my domain, and my MX hosts are named such and such. Sending servers fetch that policy over HTTPS, cache it, and refuse delivery if TLS is missing or the certificate does not match. Because the policy is served over HTTPS with a valid certificate, an attacker cannot forge it.

What AnalyzeMy.Email checks

• DNS record at _mta-sts.yourdomain.com with valid v=STSv1 and an id=
• Policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — actually fetched
• Mode: enforce, testing or none
• MX patterns in the policy and its max_age
• TLS-RPT record at _smtp._tls.yourdomain.com

The three modes

• none — the policy is deliberately disabled. Used to withdraw a previously published policy cleanly.
• testing — violations are not enforced but reported via TLS-RPT. The right starting point.
• enforce — TLS and a matching hostname are mandatory. If validation fails, delivery does not happen. This is the goal.

Do not go live without a feedback channel

MTA-STS alone does not tell you whether it works: the policy acts by preventing deliveries, and you hear nothing about it. TLS-RPT provides that feedback channel — it belongs in place before you move from testing to enforce. What the record looks like and what the reports contain is covered on the TLS-RPT page.

Typical pitfalls

• Policy file unreachable: the mta-sts. subdomain needs its own valid HTTPS certificate. A certificate error voids the entire policy.
• id not updated: after every policy change the id= in the DNS record must be bumped, otherwise sending servers keep using the cached version.
• Incomplete MX list: every MX host must appear in the policy. A forgotten backup MX causes rejected messages under enforce.
• Enforcing too early: run testing first and evaluate the TLS-RPT reports.