MTA-STS Check — 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.

TLS-RPT — the feedback loop

MTA-STS alone does not tell you whether it works. TLS-RPT (RFC 8460) adds a DNS record through which sending servers send you daily reports on successful and failed TLS connections. Without TLS-RPT you arm an enforce policy blind and only learn about delivery problems when someone complains. The two belong together.

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.