Glossary term

MTA-STS: making TLS on inbound mail non-negotiable

What MTA-STS is

MTA-STS, short for SMTP MTA Strict Transport Security and defined in RFC 8461, is a policy mechanism by which a domain declares that mail sent to it must travel over authenticated TLS. A sending server that honors the policy will refuse to deliver your inbound mail in plaintext or to a server presenting the wrong certificate, instead of quietly falling back the way SMTP otherwise does.

The gap it closes is opportunistic encryption. STARTTLS, the standard way SMTP upgrades to TLS, is negotiated in-band on an unencrypted connection: the sender asks, the receiver offers, and if the offer never appears the mail flows unencrypted anyway. An attacker positioned on the path can strip the STARTTLS capability from the conversation, or answer the MX lookup with a server they control, and standard SMTP delivers into the trap without complaint. Encryption that downgrades on request is not a guarantee; it is a preference.

MTA-STS turns the preference into policy. The receiving domain publishes, over HTTPS, a signed-by-infrastructure statement: these are my legitimate MX hosts, they support TLS, and in enforce mode you must not deliver to anything else. Google, Microsoft and other large operators both publish MTA-STS policies for their own domains and honor them when sending.

How MTA-STS differs from DANE

Two protocols solve SMTP's downgrade problem, and which one a domain uses is mostly a question of DNS infrastructure.

DANE for SMTP (RFC 7672) pins certificates via TLSA records in DNS, and its security rests on DNSSEC: the records cannot be forged because the DNS responses themselves are signed. It is the cryptographically stronger design, and the one favored where DNSSEC adoption is mandated. Its cost is exactly that dependency — without DNSSEC on your zone, DANE for SMTP is not on the table.

MTA-STS was designed by and for operators who could not deploy DNSSEC at scale. It anchors trust in the Web PKI instead: the policy file is fetched over HTTPS from a well-known URL, so its authenticity rests on a TLS certificate rather than on signed DNS. A plain TXT record announces that a policy exists; the policy itself lives behind HTTPS.

The two coexist without conflict — a sender may check both, and RFC 8461 positions MTA-STS explicitly as the path for domains without DNSSEC. For most senders reading this, MTA-STS is the practically available option today.

How MTA-STS works

Deployment has three moving parts, all on the receiving domain's side.

The TXT record at _mta-sts.yourbrand.com announces the policy and versions it:

_mta-sts.yourbrand.com.  TXT  "v=STSv1; id=20260824T000000"

The id changes whenever the policy changes; senders cache policies and use the id to know when to re-fetch.

The policy file is served over HTTPS at a fixed well-known location, https://mta-sts.yourbrand.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.yourbrand.com
mx: mx2.yourbrand.com
max_age: 604800

mx lines list the legitimate mail hosts (wildcards like *.mail.protection.example.com are allowed); max_age says how long senders may cache the policy.

The mode sets the teeth. none switches the policy off in an orderly way; testing asks senders to evaluate and report violations via TLS-RPT but still deliver; enforce instructs them to refuse delivery when TLS cannot be negotiated with a certificate-valid host matching the mx list.

A compliant sender, before delivering to your domain, checks the TXT record, fetches and caches the policy, and validates that the MX host it resolved matches the policy and presents a valid certificate for its name. Any mismatch in enforce mode means the mail is not sent over the broken path — it queues and retries, surfacing as a deferral rather than a silent downgrade. Check the whole DNS surface, including the _mta-sts record, with the email DNS check.

MTA-STS and your deliverability

MTA-STS is formally about mail you receive, but it earns its place in a sender's vocabulary three ways.

Your sends encounter it. Large receivers publish enforce-mode policies, and mail systems that honor them will hold mail rather than deliver insecurely. A misconfigured TLS stack on your side, or an attempted delivery to a stale MX, now fails visibly instead of leaking plaintext — read those SMTP reply codes and deferral patterns accordingly.

Your domain's trust posture includes it. The same organizations that grade senders on SPF, DKIM and DMARC increasingly treat transport security as part of domain hygiene. A published MTA-STS policy protects replies, bounce traffic and every message your customers send you from downgrade attacks — which is part of protecting the brand your domain reputation rides on.

It closes the loop with reporting. Paired with TLS-RPT, MTA-STS gives you daily machine-readable reports of who failed to reach your domain securely and why. That turns transport failures from invisible losses into a monitored metric, the same shift DMARC aggregate reports brought to authentication.

Limitations and failure modes

Enforce mode with a stale MX list. The classic self-inflicted outage: migrating mail providers, updating MX records, and forgetting the policy file still lists the old hosts. Compliant senders now refuse delivery to your working infrastructure — for up to max_age seconds after you fix it, thanks to caching. Update the policy and the TXT id as part of any MX change, and keep max_age moderate (days, not months) while your setup is young.

The certificate blind spot. The policy's HTTPS host (mta-sts.yourbrand.com) and every MX host need valid, unexpired certificates for their exact names. An expired certificate on one MX silently removes it from the eligible pool for policy-honoring senders; watch expiry the way you watch DNS.

Testing mode forever. mode: testing without a TLS-RPT destination reports to nobody and protects nothing. Testing is a phase with an exit: collect reports, fix what they show, move to enforce. A policy parked in testing for a year is a statement of intent, not a control.

Assuming universal enforcement. Sender-side support is strong among large providers and uneven elsewhere. MTA-STS raises the floor for mail from participating senders; it does not encrypt the long tail that never checks the policy. It is one layer, not the layer.

Forgetting the policy exists. The HTTPS file lives outside DNS, often outside the mail team's tooling, on a small static host nobody monitors. When that host dies, cached policies keep working until they expire, and then senders in enforce mode start deferring. Put the policy endpoint in the same uptime monitoring as your MX.

Confusing it with content authentication. MTA-STS secures the transport channel to your domain. It says nothing about who wrote a message or whether its From: header is honest — that remains DMARC's territory, and the two address unrelated attacks.

Frequently asked questions

Does MTA-STS protect mail I send or mail I receive? Mail sent to your domain. Publishing a policy tells the world's sending servers to require verified TLS when delivering to you. Your outbound mail is protected by the policies of the domains you send to.

Do I need MTA-STS if I already have SPF, DKIM and DMARC? They solve different problems. Authentication proves who sent a message; MTA-STS prevents interception and downgrade of messages in transit to you. A complete posture includes both, plus TLS-RPT for visibility.

What is the difference between testing and enforce mode? Testing asks senders to evaluate the policy and report violations while still delivering; enforce instructs them to withhold delivery over non-compliant paths. Testing exists to de-risk the switch — run it with TLS-RPT until the reports are clean, then enforce.

Why does the policy live on HTTPS instead of in DNS? Trust anchoring. Plain DNS answers can be forged by the same attacker MTA-STS defends against; HTTPS brings the Web PKI's certificate validation. Domains with DNSSEC can use DANE, which keeps everything in signed DNS instead.

Can MTA-STS break my incoming mail? Only through misconfiguration: a policy listing wrong MX hosts, an expired certificate, or an unreachable policy file after caches expire. Senders that honor the policy will defer rather than deliver insecurely, so failures look like delayed mail from major providers.

How do I know if my MTA-STS policy is working? Publish a TLS-RPT record alongside it and read the daily reports — successful sessions, failures and the reasons arrive in machine-readable form. For a spot check, verify the TXT record and fetch your own policy URL from outside your network.

Twenty minutes settles your current state: query _mta-sts.yourdomain , fetch /.well-known/mta-sts.txt on the policy host, and confirm every listed MX presents a valid certificate. If any step fails and your mode says enforce, some of your inbound mail is already queuing somewhere — the email DNS check gives you the whole picture in one pass.