MTA-STS Policy Generator

MTA-STS: enforcing TLS on inbound SMTP

MTA-STS (Mail Transfer Agent — Strict Transport Security) is the email transport companion to HSTS, standardized in RFC 8461 by the IETF in 2018. SMTP has historically negotiated encryption opportunistically through STARTTLS, which means an on-path attacker can simply strip the STARTTLS response and force the sending server to fall back to cleartext. MTA-STS closes that gap: a receiving domain publishes a policy declaring "you must use TLS, you must verify my certificate, and these are my valid MX hostnames" — and compliant senders cache and enforce it.

A deployment has three moving parts:

• A DNS TXT record at _mta-sts.example.com advertising that the policy exists and carrying an opaque id.
• An HTTPS endpoint at https://mta-sts.example.com/.well-known/mta-sts.txt serving the policy file with a valid public certificate (no self-signed).
• A policy file listing the mode, MX patterns and a max_age for caching.

The DNS record and policy file

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260101120000Z"

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.com
max_age: 604800

The id in the TXT record is the cache-busting token: when you rotate the policy file, you must bump id (a timestamp is convenient) so senders re-fetch instead of serving the stale cached copy until max_age expires.

Policy modes: none, testing, enforce

none disables MTA-STS — used to back out a policy. testing tells senders to apply the policy but deliver anyway on failure, while still emitting TLS-RPT reports (see the companion tool). enforce instructs senders to refuse delivery if the MX certificate, hostname or TLS handshake fails. The standard rollout path is testing for at least a couple of weeks, watching TLS-RPT for surprises, then flipping to enforce.

Adoption and operational reality

Google, Microsoft 365, Yahoo, ProtonMail, Fastmail and AWS SES all honor MTA-STS as senders, and most of them publish their own policies as receivers. Big Brazilian providers and ESPs are catching up more slowly, which is a deliverability opportunity for security-minded teams. The cost is essentially zero — a TXT record, a subdomain on your existing HTTPS infrastructure, and a five-line policy file — and the payoff is closing the most widely exploited SMTP downgrade attack.

Companion standards. DANE (RFC 7672) does a similar job but pins certificates via DNSSEC TLSA records; it is more rigorous but much less deployed because DNSSEC adoption is uneven. Most teams pick MTA-STS for pragmatic reasons. TLS-RPT (RFC 8460) is the reporting channel and is almost always deployed alongside MTA-STS.

FAQ

Do I need this for a small mailing domain? Strictly no, but it is the cheapest TLS hardening you can buy — a single TXT record plus a static file. If you already publish HTTPS, deploy it.

What happens if the policy file disappears? Senders that already cached the policy continue to enforce it until max_age expires. New senders will not see any policy and fall back to opportunistic TLS. This is why max_age tends to be a week or longer in production.

How do I test it? Use hardenize.com, mxtoolbox.com or aykira.com.au/mta-sts-checker. They fetch your TXT, the policy file and validate the MX list and certificate.

What are the common failures? The .well-known URL returning 404, a self-signed certificate on the policy subdomain, an MX missing from the policy, or forgetting to bump id after editing the file.