What is MTA-STS and how does it work?

9 May 2026 · 12 min read

When you send a message from one organisation to another, there is a moment most people never think about: the instant your mail server hands the message over the public internet to the recipient's mail server. SPF, DKIM and DMARC all care about who is allowed to send a message and whether its contents were tampered with. None of them say anything about whether that handover happened over an encrypted connection, or whether the server on the other end was really the right server at all. MTA-STS is the standard that fills exactly that gap.

MTA-STS, which stands for SMTP MTA Strict Transport Security, lets a domain owner tell the rest of the world's mail servers two firm things: "always use TLS encryption when you deliver mail to me", and "only trust a server that presents a valid certificate for my domain". Published correctly, it shuts down a class of attacks that the underlying mail protocol left wide open for decades. This article explains what MTA-STS actually is, the two pieces it is built from (a DNS record and an HTTPS-hosted policy file), the difference between testing and enforce mode, and precisely how it stops TLS downgrade and interception attacks.

The problem MTA-STS was built to solve

To see why MTA-STS exists, you have to understand how email encryption between servers worked, or rather failed to work, before it.

When one mail server delivers a message to another, it opens an SMTP connection and the two servers negotiate. The receiving server can advertise that it supports encryption by announcing a capability called STARTTLS. If the sending server sees STARTTLS, it can upgrade the plaintext connection to an encrypted TLS one before sending the message. This sounds reassuring, and a great deal of email is delivered this way. But the design has two fatal weaknesses.

The first weakness is that STARTTLS is opportunistic. The encryption is used only if it is offered, and there is no out-of-band way for the sender to know in advance that it should have been offered. If the STARTTLS announcement is missing, the sending server shrugs and delivers the message in plaintext rather than failing. That makes downgrade trivial. An attacker positioned on the network path, sometimes called a man-in-the-middle, can simply strip the STARTTLS keyword out of the conversation as it passes. The sending server, never having been told to expect encryption, falls back to plaintext, and the attacker reads or copies the entire message. This is the classic TLS downgrade attack, sometimes called STARTTLS stripping.

The second weakness is that even when TLS is used, the sending server historically did not verify the certificate properly. In opportunistic TLS, an expired certificate, a self-signed certificate, or a certificate for the wrong hostname was usually accepted anyway, because refusing it would have meant bouncing legitimate mail. So an attacker who could redirect the connection (for example by tampering with DNS or routing) could present their own certificate, terminate the TLS session themselves, read the message, and forward it on. The encryption existed, but it was encryption to the attacker. This is an interception attack, and unauthenticated TLS does nothing to prevent it.

MTA-STS was created to make encryption to the recipient both mandatory and authenticated, so that neither of these attacks can succeed quietly.

The two halves of MTA-STS

MTA-STS is unusual among email standards because it is not published in a single DNS record. It is built from two separate pieces that work together: a small DNS TXT record, and a policy file served over HTTPS from a fixed location on your domain. You need both, and they have to agree, or sending servers will treat your domain as having no MTA-STS at all.

Part one: the DNS record

The first piece is a TXT record at a specific subdomain: _mta-sts under your domain. For a domain called yourcompany.com, the record lives at _mta-sts.yourcompany.com. It is deliberately tiny:

_mta-sts.yourcompany.com. IN TXT "v=STSv1; id=20260622000000"

It carries just two tags:

• v=STSv1 identifies this as a version 1 MTA-STS record. A sending server that does not recognise the version ignores the record.
• id= is an opaque version string for your policy. Whenever you change the policy file, you change this id. Sending servers cache your policy, and the id is how they notice that the cached copy is stale and needs refetching. A timestamp such as 20260622000000 is a common, sensible choice because it always increases and is easy to read.

Notice what is not in the DNS record: the actual rules. The DNS record does not list your mail servers, your mode, or your TLS requirements. Its only jobs are to announce that an MTA-STS policy exists and to signal, through the id, when that policy has changed. All the substance lives in the policy file.

This split is intentional. DNS records can be spoofed or stripped on a path that lacks DNSSEC, so MTA-STS deliberately puts the trustworthy content behind HTTPS, where the certificate authority system can authenticate it. The DNS record is only a lightweight pointer.

Part two: the HTTPS policy file

The second piece is a plain-text policy file that you must serve over HTTPS from a fixed, well-known URL. For yourcompany.com, sending servers will fetch it from:

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

That hostname (mta-sts. followed by your domain) and that path (/.well-known/mta-sts.txt) are fixed by the standard. You cannot put the file anywhere else. The connection must be over HTTPS with a valid certificate for mta-sts.yourcompany.com, which is the linchpin of the whole design: because the file is fetched over authenticated HTTPS, an attacker on the mail path cannot forge or alter it.

A typical policy file looks like this:

version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: *.mail.protection.outlook.com
max_age: 604800

Each line carries meaning:

• version: STSv1 matches the version in the DNS record.
• mode: is the heart of the policy and is either enforce, testing, or none. We will unpack these next.
• mx: lists the mail server hostnames that are valid recipients for your domain. You can have several mx: lines, and you can use a single wildcard label such as *.mail.protection.outlook.com. These names must match both the hostnames in your published MX records and the names on the TLS certificates those servers present.
• max_age: tells sending servers, in seconds, how long they may cache this policy. The value above is one week. A long max_age is actually a security feature: once a sender has cached your enforce policy, an attacker cannot strip it for the duration of the cache, even by interfering with DNS.

The file must be served exactly as text, and the formatting matters. If the file is missing, served over plain HTTP, served with an invalid certificate, or malformed, a careful sending server treats the policy as absent and your protection silently disappears. This is one of the most common reasons a setup looks correct but does not actually work, which is why it is worth verifying the live file rather than assuming.

How a sending server uses MTA-STS, step by step

Putting the two halves together, here is what happens when a compliant sending server (Gmail, Microsoft 365 and many others enforce MTA-STS) has a message to deliver to your domain.

1. It looks up your domain's MX records as normal to find your mail servers.
2. It looks up the _mta-sts TXT record. If there is no record, it falls back to ordinary opportunistic TLS and MTA-STS plays no part.
3. If the TXT record exists, the server checks whether it already has a cached policy with the same id. If the id is new or there is no cache, it fetches https://mta-sts.yourcompany.com/.well-known/mta-sts.txt over HTTPS, validating the certificate for that hostname. If the HTTPS fetch fails or the certificate is invalid, it uses any previously cached policy, or none.
4. With a valid policy in hand, the server connects to the MX host it intends to deliver to and checks two things: that the MX hostname is covered by an mx: pattern in the policy, and that the server presents a valid, trusted TLS certificate matching that hostname.
5. Now the mode decides the outcome. In enforce mode, if TLS cannot be negotiated, or the certificate is invalid, or the MX hostname is not listed in the policy, the server refuses to deliver and the message is deferred or bounced rather than sent insecurely. In testing mode, the server delivers the message anyway but records the failure and reports it.

The crucial change from plain STARTTLS is in that final step. With opportunistic TLS, a problem means "send it in plaintext anyway". With MTA-STS in enforce mode, a problem means "do not send it at all". That single inversion is what closes the downgrade hole.

Testing mode versus enforce mode

The mode field is where most of the operational care goes, and getting the sequence right is what makes an MTA-STS rollout safe.

mode: none

This effectively disables the policy. You would use it briefly when you want to withdraw MTA-STS in a controlled way, leaving the records in place but instructing senders to stop applying any TLS requirement. It is rarely the mode you want for any length of time.

mode: testing

In testing mode, sending servers evaluate your policy but never block a message because of it. If a delivery would have failed enforcement (no TLS, bad certificate, unlisted MX), the mail is still delivered, but the sending server makes a note. Those notes are sent back to you through TLS-RPT, a companion standard we describe below. Testing mode is how you safely confirm that your policy is correct, that every legitimate sending platform can fetch your file and validate your certificates, and that you have not forgotten an MX host, all without any risk of losing mail.

You should always start in testing mode. Run it for a week or two, watch the TLS-RPT reports, and only move on once they are clean.

mode: enforce

In enforce mode, the protection becomes real. A sending server that cannot establish authenticated TLS to a listed MX host will refuse to deliver. This is exactly the behaviour you want against an attacker, but it also means a mistake in your own configuration (an expired certificate on your mail server, a missing mx: line, a renamed MX host) can now block legitimate mail. That is precisely why the standard gives you testing mode first. Move to enforce only once your reports have confirmed there are no legitimate failures.

The safe path is always the same: publish in testing, watch the reports, fix anything they reveal, then switch a single line to enforce and bump the id.

TLS-RPT: the reporting channel

MTA-STS on its own enforces a policy but tells you nothing about what is happening. TLS-RPT (TLS Reporting) is the companion standard that closes that loop. It is a second small DNS TXT record:

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

With TLS-RPT published, sending servers send you a daily summary of their attempts to deliver to you over TLS: how many connections succeeded, how many failed, and why they failed (certificate problems, missing STARTTLS, policy-fetch errors, and so on). These reports are what make testing mode meaningful, because they are the only way to see failures that did not block mail. They are also your early warning system in enforce mode: a sudden spike in TLS failures can indicate a certificate about to expire, a misconfigured MX host, or an active attack. You should always deploy TLS-RPT alongside MTA-STS, never one without the other.

Exactly how MTA-STS stops the two attacks

It is worth being concrete about how the mechanism defeats each threat, because the design is elegant.

Against a TLS downgrade (STARTTLS stripping) attack: the attacker strips the STARTTLS announcement so the sending server thinks encryption is unavailable. Without MTA-STS, the sender delivers in plaintext. With an enforce-mode MTA-STS policy already cached, the sending server knows, independently of anything the attacker can touch on the mail path, that TLS is required for your domain. When TLS is not offered, it refuses to deliver in plaintext. The attacker cannot strip the policy, because the policy was fetched earlier over authenticated HTTPS and is held in the sender's cache for up to max_age. The downgrade simply fails, and the message waits rather than leaking.

Against an interception (man-in-the-middle) attack: the attacker redirects the connection to a server they control and presents their own TLS certificate. Without MTA-STS, opportunistic TLS often accepts whatever certificate appears, so the attacker terminates the encryption, reads the message, and relays it on. With MTA-STS, the policy lists the legitimate MX hostnames, and the sending server requires a valid certificate matching one of those names from a trusted certificate authority. The attacker cannot obtain such a certificate for your mail hostnames, so certificate validation fails and, in enforce mode, delivery is refused. The interception is detected and blocked.

In both cases the common thread is the same: MTA-STS converts encryption from "nice if available" into "required and authenticated", and it anchors that requirement in a policy the attacker cannot reach.

MTA-STS, DANE, and where it fits with DMARC

You may encounter DANE, an alternative way to require authenticated TLS for mail that uses DNSSEC and a TLSA record instead of an HTTPS-hosted file. DANE is cryptographically stronger in some respects, but it requires your domain (and your recipients) to have DNSSEC fully deployed, which many do not. MTA-STS was designed precisely so that domains without DNSSEC could still get strong protection, leaning on the web certificate authority system that is already universal. Many organisations publish both; they are complementary rather than mutually exclusive.

It is also worth being clear about what MTA-STS does not do. It protects the transport of mail in flight: confidentiality and integrity of the connection between servers. It says nothing about whether the sender is authorised to use your domain or whether the visible From: address is genuine. Those are the jobs of SPF, DKIM and DMARC, which authenticate identity rather than transport. A complete email-authentication posture needs both layers. You publish SPF, DKIM and DMARC to stop spoofing, and you publish MTA-STS and TLS-RPT to stop interception and downgrade. You can read how the identity layer fits together in what is DMARC and how does it work.

A safe rollout in practice

If you are setting MTA-STS up yourself, the order of operations is what keeps your mail flowing.

1. Confirm your MX records are correct and that every MX host already presents a valid, trusted TLS certificate matching its hostname. MTA-STS only works if your own servers pass the checks it will enforce.
2. Stand up the mta-sts.yourcompany.com host over HTTPS with a valid certificate, and serve the policy file at /.well-known/mta-sts.txt with mode: testing.
3. Publish the _mta-sts TXT record with an id, and publish the _smtp._tls TLS-RPT record so reports start flowing.
4. Watch the TLS-RPT reports for a week or two. Resolve every legitimate failure they reveal.
5. Once the reports are clean, change the policy file to mode: enforce and update the id in your DNS record so caches refresh.

You can confirm each piece is live and consistent with the free MTA-STS checker, which fetches both the DNS record and the policy file and flags mismatches such as a stale id, a missing certificate, or an MX host that is not listed. It is the fastest way to catch the silent failures described earlier before they bite.

The practical takeaway

MTA-STS is the part of email security that protects messages while they cross the network, the layer that SPF, DKIM and DMARC do not touch. It works by pairing a small _mta-sts DNS record with an HTTPS-hosted policy file, and its power comes from enforce mode: once a sending server has cached your policy, it will refuse to deliver your mail in plaintext or to an unverified server, which is precisely what defeats TLS downgrade and interception. Pair it with TLS-RPT so you can see what is happening, and always start in testing mode before you enforce.

Getting the DNS record, the HTTPS host, the certificate and the policy file all consistent (and keeping the certificate renewed forever after) is fiddly, and a single stale id or expired certificate can silently switch your protection off. If you would rather not own that operational burden, our done-for-you MTA-STS service hosts the policy, manages the certificate, keeps the records in sync, and monitors your TLS-RPT reports, alongside the rest of your email authentication. Whichever route you take, start with the free MTA-STS checker to see exactly where your domain stands today.