What is MTA-STS? Strict transport security for email explained

MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard, defined in RFC 8461, that lets a domain require encrypted, certificate-validated connections for inbound email. It works through a DNS record and a small policy file served over HTTPS, and it closes the gap left by opportunistic STARTTLS, which an attacker on the network path can silently strip.

Why does email need strict transport security?

SMTP, the protocol servers use to pass email between each other, predates widespread encryption. Encryption was retrofitted through STARTTLS: the receiving server advertises that it supports TLS (Transport Layer Security), and the sending server upgrades the connection before transmitting the message. The design is deliberately opportunistic. If TLS is not offered, or the upgrade fails, the sending server falls back to plain text so that mail still gets through.

That fallback is the weakness. An attacker positioned between the two servers (on a compromised network, a rogue Wi-Fi gateway, or a hijacked route) can simply delete the STARTTLS capability from the receiving server's response. Both servers behave correctly by their own rules, the connection proceeds unencrypted, and the attacker reads or modifies the mail in transit. This is called a downgrade attack, and neither side logs anything unusual.

There is a second gap: even when STARTTLS succeeds, most sending servers historically did not validate the certificate. A self-signed or mismatched certificate was accepted, because rejecting it would have meant losing mail. An attacker who can intercept the connection can therefore present their own certificate and decrypt the traffic. If you want a refresher on the journey a message takes between servers, see how email delivery works.

MTA-STS fixes both problems. It gives your domain a way to publish, in advance and over a channel the attacker cannot tamper with as easily, a statement that says: mail for this domain must be delivered over TLS, to these named mail hosts, with a valid certificate. A sending server that supports MTA-STS will then refuse to fall back to plain text.

How does MTA-STS work?

MTA-STS has two moving parts, and understanding why there are two is the key to understanding the design.

The DNS record

A TXT record at _mta-sts.yourdomain.com signals that a policy exists and gives it a version identifier:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260811T010101"

The id value is an opaque string that you change whenever the policy changes. Sending servers cache your policy (often for weeks), and a changed id tells them the cached copy is stale and a fresh one should be fetched. The record itself carries no policy content, only the signal.

The policy file

The policy itself is a plain-text file served over HTTPS at a fixed, well-known location:

https://mta-sts.example.com/.well-known/mta-sts.txt

The file looks like this:

version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
mx: *.mail.example.net
max_age: 604800

Each line matters:

• version is always STSv1.
• mode is none, testing or enforce (covered below).
• mx lines list the hostnames of your legitimate mail servers. A sender checks that the MX host it is about to connect to matches one of these patterns, and that the host presents a valid TLS certificate for that name. Wildcards match one label, so *.mail.example.net matches mx1.mail.example.net but not a.b.mail.example.net.
• max_age is how long, in seconds, senders may cache the policy. RFC 8461 recommends a value of weeks; 604800 is one week, and values up to 31557600 (about a year) are permitted.

Why HTTPS rather than putting the whole policy in DNS? Because plain DNS is itself spoofable by the same class of attacker. HTTPS delivery means the policy arrives over an authenticated channel: the web server must present a valid, publicly trusted certificate for mta-sts.yourdomain.com. An attacker who can tamper with your DNS answers still cannot forge the policy file without also defeating the web PKI (public key infrastructure). The alternative approach, DANE, solves the same trust problem with DNSSEC instead; more on that later.

The caching is what makes the protection stick. Once a sender has your policy cached with a long max_age, an attacker who blocks access to the policy file or strips STARTTLS gains nothing: the sender already knows encryption is required and will refuse to deliver in the clear until the connection can be made properly.

What do the three policy modes mean?

Mode	Effect on delivery	When to use it
none	No effect. Tells senders the domain has no active policy.	Withdrawing a policy cleanly, so cached copies expire without side effects.
testing	No effect on delivery. Senders still deliver mail that would have failed the policy, but report the failures via TLS-RPT.	Initial rollout. Run here until reports confirm every legitimate path passes.
enforce	Mail that cannot be delivered over validated TLS to a listed MX host is not delivered. Senders queue and retry, then bounce.	Steady state, once testing shows a clean picture.

The parallel with DMARC is deliberate and useful. Just as you move a DMARC policy from monitoring to enforcement only after reading the reports, you move MTA-STS from testing to enforce only after TLS-RPT reports confirm that real senders can reach your MX hosts over valid TLS. The difference is what enforcement risks: a wrong DMARC policy gets legitimate mail junked at the destination, while a wrong MTA-STS policy stops mail being delivered to you at all. That is why the testing phase, and the reporting that feeds it, are not optional steps to skip.

How do you deploy MTA-STS?

A worked deployment for example.com whose mail is hosted on mail1.example.com and mail2.example.com:

1. Confirm your MX hosts do TLS properly. Each host must offer STARTTLS with a certificate that is publicly trusted, unexpired, and valid for the MX hostname itself. A certificate for the wrong name is the most common reason enforcement would break.
2. Publish the policy file. Stand up HTTPS on mta-sts.example.com (a small static site or a CDN worker is enough) and serve /.well-known/mta-sts.txt with mode: testing, your mx lines, and a modest max_age such as 86400 (one day) while you iterate.
3. Publish the TXT record. Add _mta-sts.example.com with v=STSv1; id=<today's date or a serial>.
4. Turn on TLS-RPT. Publish a _smtp._tls TXT record so senders tell you about TLS failures. Without it, testing mode is silent and you learn nothing.
5. Read the reports for a few weeks. You are looking for failures against your own hosts: certificate name mismatches, hosts missing from the mx list, STARTTLS not offered on a secondary MX.
6. Move to enforce. Change mode to enforce, raise max_age to at least a week, and change the id in the TXT record so cached testing policies are refreshed.

Two operational rules follow from the caching model. First, treat the certificate on your MX hosts and on the mta-sts web host as production-critical and renew them automatically. Second, whenever you change mail providers or MX hosts, update the policy file and the id before the cutover, not after; senders holding a cached policy that names only the old hosts will refuse to deliver to the new ones. The DNS side of all this sits alongside the rest of your email records, summarised in DNS records for email.

How does TLS-RPT relate to MTA-STS?

SMTP TLS Reporting (TLS-RPT, RFC 8460) is the feedback channel for MTA-STS, in the same way aggregate reports are the feedback channel for DMARC. You publish one TXT record:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Participating senders (Google and Microsoft among them) then send you a daily JSON summary per sending platform: how many sessions to your domain succeeded, how many failed, and why (STARTTLS not offered, certificate expired, certificate name mismatch, policy could not be fetched). The reports contain connection statistics, not message content.

TLS-RPT is what makes the testing mode useful and the enforce mode safe: it is the only way you find out that a sender somewhere is failing to negotiate TLS with you before that failure starts bouncing mail. It also gives you a live signal of active interference, because a downgrade attack against a domain in enforce mode shows up as a spike of reported failures rather than silently lost mail. The report format and how to read it are covered in detail in what is TLS-RPT.

How does MTA-STS compare with DANE?

DANE (DNS-based Authentication of Named Entities) solves the same downgrade problem a different way: TLSA records in DNS pin the certificates your MX hosts use, and DNSSEC signing makes those records tamper-evident. DANE is arguably the stronger design, since it does not depend on the web PKI at all, but it requires DNSSEC on your zone and DNSSEC validation at the sender, and adoption of both remains uneven.

MTA-STS was designed as the pragmatic alternative that works without DNSSEC, which is why the large consumer mailbox providers implemented it first. The two are not mutually exclusive: a domain can publish both, and RFC 8461 specifies that a sender which validates DANE for a domain should apply DANE. For most organisations, MTA-STS plus TLS-RPT is the practical starting point.

What does MTA-STS not do?

Scope matters, because MTA-STS is often mistaken for a sender authentication control. It is not one.

• It protects inbound mail only. Your policy governs how other servers deliver to your domain. It says nothing about mail you send; protecting your outbound mail in transit depends on the recipient domains publishing their own policies.
• It does not authenticate the sender. A phishing message sent to you over a beautifully encrypted connection still arrives. Encryption in transit and protection against spoofing are separate problems; SPF, DKIM and DMARC handle the latter.
• It only binds senders that support it. Legacy sending servers that have never heard of MTA-STS behave as before. In practice the major providers do support it, so coverage of real-world mail volume is substantial, but it is not universal.

The practical reading: MTA-STS belongs in the same programme as DMARC, deployed with the same discipline (report first, enforce second), but it defends a different layer. DMARC defends who mail claims to be from; MTA-STS defends the pipe the mail travels through. Because both standards depend on reading reports before enforcing, most teams run them through the same tooling; a monitoring service such as DMARCHub can collect TLS-RPT reports alongside DMARC aggregate reports and flag failures before they become bounces (see /features).

Frequently asked questions

Does MTA-STS replace DMARC, SPF or DKIM?

No. MTA-STS encrypts and authenticates the connection between mail servers; DMARC, SPF and DKIM authenticate the message and its claimed sender. A domain can have perfect MTA-STS and still be trivially spoofed, and vice versa. Mature setups deploy both layers, and government guidance such as the NCSC's recommends exactly that combination.

Do Microsoft 365 and Google Workspace support MTA-STS?

Yes, on both sides. Google and Microsoft validate MTA-STS policies when sending, and both platforms' MX infrastructure serves mail over TLS with valid certificates, so domains hosted on either can publish a policy covering the provider's MX hostnames. You still host the policy file yourself on mta-sts.yourdomain.com; consult your provider's documentation for the exact MX patterns to list.

What happens if my certificate expires while MTA-STS is in enforce mode?

Senders that honour your policy will stop delivering to the affected host, queue the mail, and retry for as long as their queue lifetime allows (typically one to a few days) before bouncing it. Fix the certificate within that window and the queued mail flows through. This is why automated certificate renewal on every MX host, and TLS-RPT monitoring to catch the failure early, should be in place before you enforce.

Why is the MTA-STS policy served over HTTPS instead of DNS?

Because ordinary DNS answers can be forged by the same attacker the standard defends against. Serving the policy from https://mta-sts.yourdomain.com means it arrives over a channel authenticated by a publicly trusted certificate, without requiring DNSSEC. The DNS TXT record only signals that a policy exists and when it has changed; the trust lives in the HTTPS fetch.