MTA-STS, short for SMTP MTA Strict Transport Security, is a standard that lets a domain declare that mail servers delivering email to it must use TLS with a valid certificate and must connect only to the MX hosts listed in a published policy. In email infrastructure, it closes the main weakness of opportunistic STARTTLS, which an attacker on the network path can strip or redirect without either side noticing.
The mechanism is specified in RFC 8461 and combines a DNS TXT record that signals the policy exists with a policy file served over HTTPS. It protects mail in transit between servers, not stored mail and not the connection between a user and an email client. A companion standard, SMTP TLS Reporting (TLS-RPT), lets the domain receive daily reports about delivery failures caused by the policy.
Why SMTP needs MTA-STS
Server-to-server SMTP encrypts mail with STARTTLS, an upgrade command issued after the plaintext connection opens. Because the upgrade is optional and unauthenticated by default, a man-in-the-middle can remove the STARTTLS offer and force plaintext delivery. Sending servers also rarely validate certificates, since many receivers use self-signed or mismatched ones.
MX lookups are equally exposed: without DNSSEC, a spoofed DNS answer can direct mail to an attacker’s server. MTA-STS addresses both problems by giving senders a trusted, cached statement of which hosts are valid and that TLS is mandatory, authenticated through the Web PKI rather than through DNS alone.
How an MTA-STS policy is published and applied
A domain publishes two components. The first is a TXT record at _mta-sts.example.com with content such as v=STSv1; id=20261101T120000;, where the id value changes whenever the policy changes. The second is a plain-text policy served at https://mta-sts.example.com/.well-known/mta-sts.txt with a certificate valid for that host name.
| Field | Example value | Purpose |
|---|---|---|
| version | STSv1 | Policy format version |
| mode | enforce, testing or none | How senders apply the policy |
| mx | mail.example.com or *.example.net | Allowed MX host patterns, one per line |
| max_age | 86400 to 31557600 seconds | How long senders cache the policy |
A supporting sender looks up the TXT record, fetches the policy over HTTPS and caches it for max_age seconds. On each delivery, it checks that the MX host matches a listed pattern and that the server presents a certificate valid for that MX name. In enforce mode, if either check fails, the sender does not deliver and queues the message for retry.
The cache provides the real protection. Because the policy is remembered, an attacker who later blocks the TXT record or HTTPS fetch cannot silently remove it, a model known as trust on first use. The maximum permitted max_age is 31,557,600 seconds, roughly one year, and values of one to several weeks are common.
Policy modes and rollout
MTA-STS offers three modes that support a gradual rollout. Moving directly to enforce without monitoring risks rejected mail if any MX host has an expired or mismatched certificate.
| Mode | Sender behavior | When to use it |
|---|---|---|
| testing | Delivers anyway, reports failures via TLS-RPT | Initial deployment and monitoring |
| enforce | Refuses delivery on any validation failure | After reports show clean results |
| none | Treats the domain as having no policy | Withdrawing a policy safely |
A safe sequence is to publish TLS-RPT first with a _smtp._tls TXT record, then a testing policy with a short max_age, review several weeks of reports, and only then switch to enforce with a longer max_age. To withdraw the policy, publish mode none with a new id rather than deleting it, so cached copies are replaced.
MTA-STS compared with DANE and other email standards
MTA-STS is often confused with sender authentication standards, but it protects a different property: the confidentiality and integrity of the transport, not the identity of the sender. Its direct alternative is DANE for SMTP, which uses DNSSEC-signed TLSA records.
| Standard | What it protects | Trust anchor | Main requirement |
|---|---|---|---|
| MTA-STS | Server-to-server transport | Web PKI certificates | HTTPS host and public CA certificate |
| DANE for SMTP | Server-to-server transport | DNSSEC | Signed zone and TLSA records |
| SPF | Authorized sending IP addresses | DNS | TXT record listing senders |
| DKIM | Message integrity and signing domain | DNS public key | Signing on outbound mail |
| DMARC | Alignment policy for the visible From domain | DNS | SPF or DKIM alignment |
DANE gives stronger guarantees because it does not depend on a first fetch, but it requires DNSSEC on the recipient domain, which many hosting setups lack. Large providers support MTA-STS widely, and domains can publish both; senders that support DANE generally prefer it when valid TLSA records exist.
Common MTA-STS deployment problems
Most failures come from operational drift rather than from the standard itself. The policy and the MX records are maintained in different places, so a change to one is easily forgotten in the other.
- Changing MX records without updating the mx lines in the policy file.
- Forgetting to change the id in the TXT record, so senders keep an outdated cached policy.
- Letting the certificate expire on the mta-sts host or on an MX server.
- Serving the policy with a redirect or wrong content type, which compliant senders reject.
- Skipping TLS-RPT, leaving the domain blind to rejected deliveries.
MTA-STS also does not protect inbound mail sent by servers that ignore the standard; it only binds senders that implement it. It is therefore one layer in a transport security strategy, ideally combined with monitoring of TLS reports and automated certificate renewal on every MX host.
Explained without jargon
When one mail server sends a message to another, the connection is usually encrypted, but only if nobody interferes. An attacker in the middle can quietly ask both sides to skip encryption. The message then travels in the open.
MTA-STS is like a public notice on a company’s website. It says: deliver our mail only through these named doors, and only through a locked channel. Sending servers that read the notice remember it for weeks. If someone tries to trick them later, they refuse to hand over the mail instead of sending it unprotected.
A typical use case
A law firm handles confidential client correspondence and wants assurance that incoming email cannot be downgraded to plaintext in transit. Its IT team first publishes a TLS-RPT record and an MTA-STS policy in testing mode with max_age set to 86,400 seconds, listing its two MX hosts at the hosted mail provider.
Reports arriving over three weeks show that every major sending provider negotiates TLS successfully, except for one partner whose relay used an outdated configuration, which the partner then fixes. The firm switches to enforce mode with max_age of 1,209,600 seconds, two weeks. From then on, senders that support the standard refuse to deliver if they encounter an invalid certificate or an unlisted mail server, which removes the risk of silent interception for that traffic.