In short. SPF, DKIM and DMARC change how your mail is classified. MTA-STS changes whether it is delivered — in enforce mode a sending server that cannot establish trusted TLS to your MX will refuse to deliver rather than fall back. That makes it the most useful and the least forgiving of the email controls.
What it protects against, precisely
SMTP negotiates encryption opportunistically. A sending server issues STARTTLS, and if the response is missing or the certificate is unusable it simply continues in plaintext. That fallback is the vulnerability: an attacker positioned on the path can strip the STARTTLS offer and watch the message go by in the clear, and neither side notices.
MTA-STS removes the fallback. It publishes a policy stating that senders must use TLS, must validate the certificate, and must only deliver to the MX hosts you list. A sender that honours the policy and cannot meet those conditions queues the message and eventually returns it, rather than delivering it insecurely.
This is the part worth internalising before you deploy it. SPF, DKIM and DMARC influence a receiving system's judgement about a message. MTA-STS instructs other people's servers to refuse delivery under conditions you define. Misconfigure the first three and mail lands in spam; misconfigure this one and mail does not land at all.
The two parts, and why the second one is a web problem
A policy has two components that live in different places, and they must agree.
| Component | Where it lives | What it carries |
|---|---|---|
| DNS record | TXT at _mta-sts.example.com | A version and an id that changes when the policy changes |
| Policy file | https://mta-sts.example.com/.well-known/mta-sts.txt | The mode, the MX list and the cache lifetime |
# The DNS side — the id is any string; change it whenever the policy changes
_mta-sts.example.com. IN TXT "v=STSv1; id=20260824T120000Z"
# The policy file, served as text/plain over HTTPS
version: STSv1
mode: testing
mx: mail.example.com
mx: mail2.example.com
max_age: 604800Note what the second row implies. The policy is fetched over HTTPS from a host named mta-sts.example.com, and that host needs a valid certificate of its own. Your mail delivery now depends on a web certificate that has nothing to do with mail. If that certificate expires, senders cannot fetch the policy — and while a cached policy keeps working, once it lapses the behaviour depends on the sender's implementation.
Put the MTA-STS host in the same certificate monitoring as everything else, and give it the same renewal automation. A subdomain created once for a policy file is exactly the kind of host that gets forgotten by whoever set up renewal for the main site.
Three modes, and only one of them is safe to start with
| Mode | What a sender does | Use it when |
|---|---|---|
none | Ignores the policy entirely | Withdrawing a policy you no longer want |
testing | Delivers anyway, but reports failures | Always, first — this is the whole rollout |
enforce | Refuses delivery on failure | Only after reports come back clean |
Going straight to enforce is the mistake this article exists to prevent. In testing mode a mismatch costs you a report; in enforce mode the same mismatch costs you the message.
TLS-RPT is what makes testing mode useful
Testing mode only helps if somebody tells you what failed, and that is what TLS-RPT does. It is a separate DNS record that asks senders to send you aggregate reports about TLS connection outcomes.
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"The reports arrive as JSON, typically daily, and they name the failure: certificate not matching the host, expired certificate, no TLS offered, policy fetch failure. That list is your go-live checklist — enforce mode is safe when those counts are zero and have been for a while.
Publish TLS-RPT before the policy, not alongside it. A week of reports against no policy at all tells you which senders already fail to establish TLS with your MX, which is information you want before you make failure fatal.
The cache is the reason mistakes persist
max_age tells senders how long to keep the policy. That is deliberate — it stops an attacker from suppressing the policy simply by blocking a fetch — and it means a wrong policy stays wrong for that long on every server that already fetched it.
The consequences are worth stating plainly:
- A policy with a stale MX list keeps rejecting mail to your new servers until the cache expires.
- Switching to
nonedoes not take effect immediately; senders holding a cachedenforcepolicy keep enforcing. - Changing the policy requires changing the
idin DNS — that is how senders learn a refetch is needed. Editing the file without touching the record is the most common way a fix appears not to work.
Start with a short max_age — a day or two — during rollout, and raise it once the policy has been stable. The same reasoning applies to HSTS, where the commitment is likewise easier to make than to unmake; that trade is covered in the HSTS guide.
The failure that arrives months later: a mail migration
The MX list in the policy is a second, independent copy of information that also lives in your DNS. When you move mail providers you update the MX records, because that is the change everyone knows about. If the policy file still lists the old hosts, senders honouring an enforce policy will refuse to deliver to the new ones.
Nothing on your side reports this. Your MX records are correct, your new provider is healthy, and mail from strict senders stops. The symptom is partial — only senders that implement MTA-STS are affected — which makes it look like a problem at their end.
# The two lists that must agree
dig +short MX example.com | sort
curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt | grep '^mx:' | sort
# Any host in one and not the other is a delivery failure waiting for a strict senderAdd the policy file to the migration checklist next to the MX records themselves. It is not part of DNS, so it survives every DNS change untouched — which is precisely why it is forgotten.
Verifying a deployment
Four checks, in order. Each one fails in a way the next cannot diagnose, so do not skip ahead.
# 1. Is the DNS record present and parseable?
dig +short TXT _mta-sts.example.com
# 2. Is the policy fetchable over HTTPS with a valid certificate?
curl -sSI https://mta-sts.example.com/.well-known/mta-sts.txt | head -3
# 3. Does it parse, and is the mode what you think it is?
curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt
# 4. Does your MX actually offer TLS with a certificate matching its own name?
openssl s_client -starttls smtp -connect mail.example.com:25 \
-servername mail.example.com < /dev/null 2>&1 \
| grep -E 'Verify return code|subject=|CN ='Step four is where real deployments fail. The certificate on the mail host must match the MX hostname, not your domain — a certificate for example.com on a host named mail.example.com fails validation, and in enforce mode that is a delivery refusal.
How to check your domain right now
Our email configuration check reports MTA-STS and TLS-RPT alongside MX, SPF, DKIM and DMARC in a single pass, including the policy mode and its max_age — which is the pair of values that decides how long a mistake would last. It also resolves your MX records, so you can compare them against the policy's list without running two tools.
For the certificate on the mail host itself, use the SSL checker against the MX hostname rather than your domain, since that is the name senders validate. The MX lookup shows the records as the world sees them, and the DNS lookup confirms the _mta-sts and _smtp._tls records are published where senders look for them.
Because the policy depends on a certificate that renews on its own schedule, this is a configuration worth watching rather than checking once. Scheduled monitoring against the MTA-STS host catches an expiring certificate weeks before it becomes an undeliverable-mail incident.
Frequently asked questions
Do I need MTA-STS if I already have SPF, DKIM and DMARC?
They solve different problems. The other three authenticate the sender and tell receivers how to treat unauthenticated mail. MTA-STS protects the transport of mail to you against downgrade and interception. Neither substitutes for the other.
Can it stop legitimate mail from arriving?
Yes, in enforce mode, and that is by design — refusing insecure delivery is the point. It happens when the MX list is stale, the mail host's certificate does not match its own name, or the policy cannot be fetched. Testing mode plus TLS-RPT exists so you find all three before enforcing.
Why is my updated policy being ignored?
Almost certainly because the id in the DNS record did not change. Senders use that value to decide whether to refetch; an edited file behind an unchanged id looks like the same policy they already have cached.
What happens if the policy host goes down?
Senders with a cached policy continue using it until max_age expires. Senders without one cannot fetch it and treat the domain as having no policy. Either way it is a fault worth alerting on, because it silently removes the protection you deployed.
Which certificate does the mail server need?
One valid for the MX hostname — the name in your MX record — not for your domain. This is the single most common reason a deployment that looks correct fails validation at the sender.
How long should max_age be?
Short while you roll out, so a mistake expires quickly, and long once stable, so an attacker cannot strip the policy by blocking one fetch. Raise it only after the policy has run unchanged through a full reporting cycle.
Checklist
- Publish TLS-RPT first and read a week of reports before publishing any policy.
- Start in
testingmode. Never begin atenforce. - Keep
max_ageshort during rollout and raise it once stable. - Change the
idin DNS every time you edit the policy file. - Make the MX list in the policy match your actual MX records, exactly.
- Give the mail host a certificate matching the MX hostname, not the domain.
- Serve the policy as plain text over HTTPS with a valid certificate.
- Add the MTA-STS host to certificate monitoring and renewal automation.
- Add the policy file to the mail migration checklist — it is not part of DNS.
- Move to
enforceonly when reports have been clean for a full cycle.
