MTA-STS Explained: Enforcing TLS for Email (2026)

MTA-STS lets your domain require that other mail servers use encrypted, authenticated TLS when they deliver email to you. Without it, the encryption between mail servers is merely opportunistic — an attacker can strip it away and force your mail into plain text without anyone noticing. MTA-STS closes that gap by publishing a policy that says “always use TLS with a valid certificate, or do not deliver at all.” This guide explains what MTA-STS is, how the MTA-STS record and policy file work, the MTA-STS syntax with a real example, how it differs from DANE, and how to roll it out safely. It belongs alongside TLS-RPT in our email security toolkit.

What is MTA-STS?

MTA-STS stands for SMTP MTA Strict Transport Security. It is a standard, defined in RFC 8461, that lets a receiving domain declare it supports TLS and instruct sending servers to refuse delivery if a secure, validated connection cannot be established. The problem it solves is real: classic SMTP encryption uses STARTTLS, which is opportunistic, so a network attacker can perform a “STARTTLS stripping” downgrade — quietly removing the encryption offer so the message is sent in clear text, or redirecting it through a malicious server. MTA-STS makes encryption mandatory for your inbound mail, on your terms.

How MTA-STS works

MTA-STS has two moving parts — a DNS record that signals a policy exists, and an HTTPS-hosted policy file that contains the rules:

1. Discovery. The sender looks up a TXT record at _mta-sts.yourdomain.com, which carries a version and a policy id — not the policy itself.
2. Policy fetch. The sender retrieves the policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS, validating the certificate of that web host.
3. Caching. The sender caches the policy for up to max_age, re-reading the TXT id to notice changes.
4. Enforcement. On delivery, the sender requires STARTTLS and checks each of your MX hosts against the policy’s allowed names and a valid certificate. In enforce mode, a failure means the message is not delivered.

One caveat worth knowing: MTA-STS is “trust on first use.” The very first contact, before any policy is cached, is not protected — but every subsequent delivery is.

MTA-STS record and policy syntax

The MTA-STS record is a short TXT record; the real rules live in the policy file. Here is the DNS MTA-STS record:

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

And the MTA-STS policy file served at https://mta-sts.example.com/.well-known/mta-sts.txt:

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

The three MTA-STS policy modes matter: testing reports problems via TLS-RPT but still delivers; enforce refuses delivery on a TLS failure; and none cleanly retires the policy.

MTA-STS vs DANE

MTA-STS and DANE solve the same problem — enforcing TLS between mail servers — but differently. MTA-STS relies on the web’s certificate system and an HTTPS-hosted policy, and needs no DNSSEC, which makes it far easier to deploy; the trade-off is the brief trust-on-first-use window. DANE (RFC 7672) anchors its trust in DNSSEC-signed TLSA records, eliminating that window and offering stronger cryptographic guarantees, but it requires DNSSEC and is supported by fewer providers. They are complementary: if you run DNSSEC, deploy both; if you cannot, MTA-STS gives you most of the protection with much less effort.

Requirements and provider support

To publish MTA-STS you need an HTTPS server at mta-sts.yourdomain.com with a valid certificate, and valid certificates on all of your MX hosts. You do not need DNSSEC. On the sending side, the major providers honour other domains’ MTA-STS policies: Google Workspace, Microsoft 365 (which validates outbound TLS automatically), and Yahoo all enforce recipient policies in 2026, and Yahoo’s sender rules now push direct senders to enable MTA-STS. Always pair it with TLS-RPT so you get reports on what is failing.

Setting up MTA-STS step by step

1. Confirm TLS on your MX hosts. Every mail server in your MX records needs a valid, CA-trusted certificate that matches its hostname. This is the foundation SMTP MTA Strict Transport Security relies on, so fix any expired or mismatched certificates first.
2. Stand up the policy host. Create the subdomain mta-sts.yourdomain.com with a valid HTTPS certificate, and serve the policy file as plain text at /.well-known/mta-sts.txt.
3. Publish the policy in testing mode. List every MX host and set a sensible max_age. In testing mode, failures are reported but mail still flows.
4. Add the DNS record. Publish the _mta-sts TXT record with a unique id.
5. Turn on TLS-RPT and watch the reports for one to two weeks to confirm clean TLS sessions from real senders.
6. Switch to enforce — and remember to change the id so senders pick up the new policy.

Why MTA-STS matters more every year

It is easy to assume email is already encrypted in transit, and most of the time it is — but “most of the time” is exactly the problem. Opportunistic STARTTLS encrypts a connection only if both servers negotiate it successfully and nothing interferes. An attacker positioned on the network path can strip the encryption offer so the servers silently fall back to plain text, or redirect the connection to a server they control, and neither end raises an alarm. For routine marketing mail that may not matter much, but for password resets, invoices, legal documents and anything carrying personal data, a silent downgrade to clear text is a genuine exposure.

SMTP MTA Strict Transport Security removes the silence. By publishing a policy that says “encryption is mandatory and the certificate must validate,” you turn an optional, strippable courtesy into a firm requirement that senders enforce on your behalf. Combined with TLS-RPT for visibility, it means you both close the downgrade hole and get told whenever someone tries — or fails — to deliver securely. As regulators and mailbox providers continue to push for encrypted, authenticated mail, deploying MTA-STS is increasingly table stakes for any domain that handles sensitive correspondence. It is also still early enough to be a genuine differentiator: in our 2026 study of 10,000 top domains, only 3.6% published an MTA-STS policy — so getting this right puts you ahead of the overwhelming majority of senders.

MTA-STS pitfalls and best practices

• Forgetting to change the id after editing the policy — senders keep the stale cached version until max_age expires. Always bump it.
• An MX not listed in the policy, or the wrong wildcard scope — legitimate servers fail validation.
• Expired or wrong-host certificates on an MX or on the mta-sts subdomain — the latter silently breaks the whole policy.
• Leaving mode: testing forever — you get reports but no actual protection.
• Best practice: roll out in testing with TLS-RPT for about two weeks, confirm clean reports, then switch to enforce; automate the id from a publish-time timestamp; list every MX including backups; and monitor certificate expiry everywhere. To roll back in an emergency, set mode: testing or none and bump the id.

MTA-STS and the major providers in 2026

MTA-STS only delivers value if real-world senders honour the policy you publish, and in 2026 the major platforms do. Google Workspace both honours other domains’ MTA-STS policies when sending and can host a policy for your domain. Microsoft 365 and Exchange Online validate TLS on outbound mail automatically and surface failures as non-delivery reports — so if your published policy or certificates are broken, Microsoft senders will tell you by bouncing, which is exactly the behaviour you want from enforcement. Yahoo’s 2026 sender rules push direct senders toward modern TLS and MTA-STS as well. Because the big mailbox providers account for most consumer mail, publishing a policy now meaningfully reduces the share of your inbound mail that could be silently downgraded.

The flip side is that enforcement is unforgiving of operational mistakes, which is why the policy host deserves special attention. The certificate on mta-sts.yourdomain.com is just as critical as the certificates on your MX hosts: if it expires, senders cannot fetch your policy and your protection lapses. Treat both as monitored, auto-renewed certificates, and keep the max_age long enough (a week or more) that a brief outage of the policy host does not immediately strip protection from every sender. When you do need to make an emergency change — a certificate problem, a new MX — remember that lowering the policy to testing only takes effect once you also change the id, because that is how senders detect that the cached policy is stale.

Related reading

• SPF records guide
• DKIM records guide
• DMARC records guide
• BIMI records guide
• ARC guide

MTA-STS FAQ

Does MTA-STS require DNSSEC?

No. MTA-STS uses the web certificate system and an HTTPS-hosted policy file, so it works without DNSSEC. That is its main advantage over DANE; the trade-off is a brief trust-on-first-use window before the policy is cached.

Is MTA-STS for inbound or outbound mail?

Both. You publish an MTA-STS policy to protect mail other people send to you, and your own mail server honours other domains’ policies when you send to them. The major providers already do the latter automatically.

What is the difference between MTA-STS testing and enforce mode?

In testing mode, TLS failures are reported via TLS-RPT but the message is still delivered, so you can find problems safely. In enforce mode, a message that cannot establish a validated TLS connection is not delivered at all. Always start in testing.

I edited my policy but nothing changed — why?

You almost certainly forgot to change the id in the MTA-STS record. Senders detect policy changes by the id, so until it changes they keep using the cached policy until max_age expires. Bump the id on every edit.

Should I use MTA-STS or DANE?

If you cannot run DNSSEC, use MTA-STS — it delivers most of the protection with far less complexity. If you already run DNSSEC, deploy DANE as well for its stronger, no-trust-on-first-use guarantees. They are complementary rather than mutually exclusive, and a sender that encounters both an MTA-STS policy and DANE records on the same domain can honour whichever it supports. For most organisations without DNSSEC today, MTA-STS paired with TLS-RPT is the pragmatic starting point, with DANE added later on if and when DNSSEC is eventually adopted across the domain.

Does MTA-STS replace SPF, DKIM and DMARC?

No. MTA-STS secures the transport — how mail is encrypted between servers — while SPF, DKIM and DMARC authenticate who sent the message. They protect different things and should all be deployed together. A useful way to remember it: authentication answers “is this message really from who it claims?”, while MTA-STS answers “was this message carried over a connection that could not be eavesdropped on or downgraded?” You want both guarantees, and neither one substitutes for the other — a perfectly authenticated message can still be sent over a stripped, unencrypted connection, and a perfectly encrypted connection can still carry a spoofed message.