What is MTA-STS?

Updated 2026-10-15 · DMARC Fundamentals

SPF, DKIM and DMARC protect the mail you send: they let receivers check that a message claiming to be from your domain really is. MTA-STS — SMTP MTA Strict Transport Security, RFC 8461 — protects a different thing: the mail sent to you, while it travels between servers.

The problem: encryption that can be switched off

When another company's mail server delivers a message to yours, the two servers talk SMTP. Encryption on that hop is opportunistic: the sending server asks "can we use TLS?" and, if your server says yes, they encrypt. If the answer never arrives, most servers shrug and send the message in plain text rather than not at all.

That fallback is the weakness. Someone positioned on the network path can strip the "yes, I support TLS" answer out of the conversation, and the sender will happily deliver in the clear. They can also present a certificate that does not belong to you, and an opportunistic sender will not check it.

MTA-STS lets you publish a promise: "my mail servers always support TLS, with a valid certificate — if you cannot get that, do not deliver." Senders that support MTA-STS then refuse the downgrade instead of falling back to it.

The two halves

MTA-STS is published in two places, and both are required.

A DNS record at _mta-sts.<your domain> announces that a policy exists and names its version:

_mta-sts.example.com.   TXT   "v=STSv1; id=20261015T000000"

The id= value is a label of 1–32 letters or digits. Change it whenever you change the policy — that is how senders learn they need to fetch it again.

A policy file served over HTTPS at a fixed address, https://mta-sts.<your domain>/.well-known/mta-sts.txt:

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

• mode is testing (senders report problems but still deliver), enforce (senders refuse delivery that is not encrypted and verified) or none (withdraw the policy).
• Each mx line names a mail server senders may deliver to; the names must match your real MX records, and a leading *. covers one level of subdomain.
• max_age is how long, in seconds, senders may cache the policy. One week (604800) is a common value.

The policy file needs a web server for the mta-sts. host name with a valid certificate for it. That is the part most domains find awkward, and the reason many publish nothing.

How to roll it out safely

1. Publish TLS-RPT first. Senders that support it email you a report for each day they send you mail, saying whether it arrived securely. Without it, you cannot see what MTA-STS would break.
2. Publish the policy in mode: testing with an mx line for every MX host, then the _mta-sts record.
3. Read the TLS-RPT reports for a week or two. Failures usually mean an MX host missing from the policy or a certificate that does not match its host name.
4. Switch to mode: enforce and change the id= in the DNS record.

If you ever stop needing MTA-STS, publish mode: none with a new id= and leave it in place for at least the old max_age before deleting anything — senders cache the policy for that long.

Who uses it

The large mailbox providers publish MTA-STS for their own domains: google.com and microsoft.com both have an _mta-sts record today. Among ordinary business domains it is still uncommon, largely because of the hosting step above. That makes it an easy way to stand out in a security review: it is a visible, checkable promise that mail to you cannot be silently read in transit.

What the Domain health card shows

The MTA-STS row reads the DNS record — the _mta-sts TXT record — and reports one of these:

The four mail transport security rows — MTA-STS, TLS-RPT, DNSSEC and DANE — are part of the Starter, Scale and Enterprise plans; on the Free plan they are shown locked, marked Upgrade. None of them counts toward the "core checks passing" number, which is DMARC, SPF and DKIM only.