What Is MTA-STS? SMTP TLS Enforcement Explained

Email between mail servers has historically been delivered in plaintext, with encryption applied only opportunistically. MTA-STS — Mail Transfer Agent Strict Transport Security — lets a domain declare that inbound mail must be delivered over TLS with a valid certificate, closing the loophole that lets an active attacker downgrade the connection and read or alter messages in transit.

What Is MTA-STS?

MTA-STS is an internet standard (RFC 8461) that lets a receiving domain publish a policy telling sending servers two things: that they should require STARTTLS, and that the receiving mail server must present a valid, trusted certificate matching one of the domain's expected MX hosts. If either condition is not met, a conforming sender refuses to deliver the message rather than falling back to plaintext.

The policy is discovered in two parts: a small DNS TXT record that announces a policy exists (and its current version), and a policy file served over HTTPS that contains the actual rules.

The Problem MTA-STS Solves

SMTP negotiates encryption with the STARTTLS command. The weakness is that STARTTLS is opportunistic and unauthenticated: a network attacker sitting between the two mail servers can strip the STARTTLS capability from the conversation (a downgrade attack), and the sending server, seeing no TLS on offer, quietly delivers the message in the clear. Because there is no certificate validation by default, an attacker can also impersonate the receiving server.

MTA-STS removes the "quietly fall back to plaintext" behaviour for domains that opt in. Once a sender has fetched and cached your policy, it will only deliver over authenticated TLS.

MTA-STS vs DANEMTA-STS and DANE (DNS-based Authentication of Named Entities) solve the same problem in different ways. DANE anchors trust in DNSSEC and TLSA records; MTA-STS anchors trust in the Web PKI (the same certificate authorities browsers trust) and HTTPS. MTA-STS is easier to deploy because it does not require DNSSEC. Many large providers publish both.

How MTA-STS Works

When a sending mail server has a message for example.com, an MTA-STS-aware sender does the following:

Looks up the _mta-sts.example.com TXT record to see whether a policy exists and read its id.
If the id is new (or nothing is cached), fetches the policy file from https://mta-sts.example.com/.well-known/mta-sts.txt over HTTPS with a valid certificate.
Parses the policy: the mode, the allowed mx patterns, and the max_age (how long to cache the policy).
When delivering, requires STARTTLS and checks that the receiving MX host's certificate is valid and matches one of the mx patterns. If not, and the mode is enforce, delivery is refused.

The Two DNS + HTTPS Components

1. The TXT record

Published at _mta-sts.yourdomain.com, this record simply announces that a policy exists and carries an id that changes whenever you update the policy file. Senders re-fetch the policy only when the id changes.

text

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260707T120000Z"

2. The policy file

Served as text/plain over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt, with a certificate valid for the mta-sts. subdomain. This is where the real rules live.

text

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

Policy Fields Explained

Field	Required?	Description
`version`	Yes	Always `STSv1`.
`mode`	Yes	`testing`, `enforce`, or `none` (see below).
`mx`	Yes	One line per allowed MX host. A leading `.` wildcard matches exactly one label (e.g. `.example.com` matches `mx1.example.com` but not `example.com`).
`max_age`	Yes	How long (in seconds) senders cache the policy. Common values: 86400 (1 day) while testing, up to 604800+ once stable.

MTA-STS Modes

testing: Senders check the policy but still deliver mail even if TLS validation fails. Failures are surfaced through TLS-RPT reports. This is the safe starting point.
enforce: Senders refuse to deliver if STARTTLS or certificate validation fails. This is the protective mode you graduate to once reports are clean.
none: Tells senders to discard any cached policy. Used to cleanly decommission MTA-STS.

Enforce mode can block mailIn enforce mode, any MX host that is not covered by an mx pattern — or that presents an invalid/expired certificate — will have its inbound mail refused. Always run in testing mode for one to two weeks and review TLS-RPT reports before switching to enforce.

Deploying MTA-STS Safely

Host the policy file over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid certificate for that subdomain.
Publish the _mta-sts TXT record with an id. Bump the id every time the policy file changes.
Add a TLS-RPT record so you receive daily reports of any TLS failures.
Start in mode: testing, watch reports for one to two weeks, then switch to mode: enforce (and update the id).

You can generate all three artifacts with the MTA-STS & TLS-RPT Generator, and verify a live deployment with the MTA-STS Checker. For a full walkthrough, see the guide How to Set Up MTA-STS.

Frequently Asked Questions

Does MTA-STS require DNSSEC?

No. That is the main practical advantage over DANE. MTA-STS relies on the Web PKI and HTTPS, so you only need a valid TLS certificate for the mta-sts. subdomain — no DNSSEC signing required.

Do I need to change my MX records?

No. MTA-STS does not change how mail is routed. Your existing MX records stay the same; the policy just lists which of those MX hosts are allowed to receive TLS-protected mail.

What happens if a sender does not support MTA-STS?

MTA-STS is opportunistic on the sender side — servers that do not implement it simply ignore your policy and deliver as they normally would. It protects mail from the (large and growing) set of providers that do support it, with no downside for those that do not.

How do I check whether my MTA-STS is working?

Use the ShowDNS MTA-STS Checker to look up the _mta-sts record, fetch and parse the policy file over HTTPS, and confirm your MX hosts are covered.