MTA-STS: The Definition, the Mechanics, and the Common Mistake
MTA-STS closes the gap where an attacker strips the offer of encryption from an SMTP connection. A domain advertises a policy in DNS and serves it over HTTPS, naming its valid mail hosts and whether senders must refuse to deliver rather than downgrade. It governs inbound mail, not the campaigns you send.
Key takeaways
- The DNS record only signals that a policy exists; the policy itself is served over HTTPS.
- Modes are none, testing and enforce. Enforce means a conforming sender refuses to deliver rather than downgrade.
- Policies are cached for max_age, so a mistake persists well after you correct the file.
- It says nothing about authentication, reputation or inbox placement.
MTA-STS (SMTP Mail Transfer Agent Strict Transport Security) is a standard that lets a domain publish a policy saying its mail servers support TLS and that senders should refuse to deliver mail to it over an unencrypted connection. The policy is fetched over HTTPS from a well-known location on the domain, and its existence is advertised by a DNS TXT record. It is defined in RFC 8461.
The problem it solves is narrow and specific. SMTP negotiates encryption opportunistically: a sending server asks whether the receiver supports STARTTLS, and if the answer is no, it sends in the clear anyway. An attacker positioned between the two servers can simply strip the offer of encryption and watch the mail go by unencrypted, with neither side raising an alarm. MTA-STS removes the fallback by letting the receiver say, in advance and out of band, that encryption is not optional.
The two pieces, and why there are two
A DNS TXT record at _mta-sts.<domain> carries a version and an id value. The id changes whenever the policy changes; that is the entire mechanism by which senders learn to re-fetch. The record itself does not contain the policy.
A policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. It lists the permitted MX hostnames, a mode, and a max_age in seconds for how long senders may cache it.
The split is deliberate and it is the interesting part of the design. DNS is not authenticated for most domains, so a policy published only in DNS could be forged or removed by the same attacker MTA-STS is defending against. Serving the policy over HTTPS borrows the web PKI: the sender validates a certificate for mta-sts.<domain> before trusting a word of it. The DNS record exists only to say a policy exists and to signal when it has changed, which is a job DNS can do safely because tampering with it can at worst cause a stale fetch.
- Step 1Check DNS
Look for a TXT record at _mta-sts.<domain> and read its id value.
- Step 2Fetch over HTTPS
If the id is new, fetch the policy from mta-sts.<domain>/.well-known/mta-sts.txt over a validated TLS connection.
- Step 3Cache
Hold the policy for up to max_age seconds. A cached policy survives a DNS outage, which is the point.
- Step 4Enforce
Deliver only to a listed MX host over TLS with a valid certificate. In enforce mode, refuse rather than downgrade.
mode takes three values and the difference between them is the whole operational story. none disables the policy. testing means senders should report failures but deliver anyway. enforce means a sender that cannot establish a validated TLS connection to a listed host must not deliver the message at all.
Where the textbook definition misleads
It protects mail coming to you, not mail going out. This is the single most common misunderstanding, and it inverts the value of the standard for anyone running outbound. Publishing MTA-STS on your domain instructs other people's servers about how to reach yours. It does nothing about how your campaigns reach anybody else. If you are sending, the relevant question is whether your sending platform honours other domains' policies, which is a property of the platform and not something you configure in your DNS.
Enforce mode can hold mail rather than deliver it, by design. A policy that lists MX hosts which no longer serve the domain, or a certificate that expires on the mail host, causes conforming senders to refuse delivery. That is correct behaviour and it is exactly what you asked for. It also means an expired certificate becomes a mail outage instead of a warning, which is a real operational trade and a good reason to sit in testing mode long enough to see the reports.
The policy is cached, so a mistake persists. max_age is often set to weeks. A sender that fetched a policy yesterday will keep applying it even after you correct the file today, because it has no reason to look again until the id changes and its cache expires. Rolling back a bad MTA-STS policy is not instantaneous, which is unusual for DNS-adjacent configuration and catches people out.
Publishing it is a web-hosting job as much as a DNS job. The policy lives at an HTTPS endpoint on a subdomain, which means somebody has to stand up mta-sts.<domain>, serve a plain text file from a fixed path, and keep a certificate valid on it forever. That is a different team and a different renewal calendar from the one that owns your MX records, and the gap between them is where most stalled rollouts sit. Treating it as "add a TXT record" underestimates the work by roughly the whole of it.
Nothing tells you who is honouring the policy unless you ask for reports. MTA-STS on its own is silent. The companion TLS reporting record, TLS-RPT, is what causes senders to post daily summaries of successful and failed TLS connections to an address you nominate. Without it, testing mode is indistinguishable from none: you have published a policy, nobody is enforcing it, and no information is coming back. This is the same failure shape as a DMARC record with no reporting address, and it is just as common.
It says nothing about whether a message is wanted. MTA-STS is transport security. It has no bearing on authentication, on reputation, or on placement. A message delivered over a perfectly enforced TLS channel lands in the spam folder exactly as readily as one that was not.
- The transport between one mail server and another
- Whether encryption may be downgraded to none
- Which MX hostnames a sender may deliver to
- Inbound mail addressed to the publishing domain
- Whether the sender is who they claim to be, which is authentication
- Whether the message reaches an inbox or a spam folder
- Encryption of the message at rest in either mailbox
- Anything about mail your own campaigns send outward
What this means when you are running outbound
For an outbound programme the honest answer is that MTA-STS is mostly somebody else's control, and knowing that is worth more than a configuration change. Two things follow.
The first is that your sending platform's TLS behaviour is a procurement question, not a DNS question. A platform that honours published policies will refuse to deliver to a domain whose MX or certificate has drifted, and that refusal will show up in your reporting as a delivery failure at a handful of recipient domains. Recognising the shape of that failure, concentrated at a few domains, unrelated to your reputation, matters when you are triaging a campaign that is otherwise healthy.
The second is that publishing a policy on your own sending and reply domains is still worth doing, for a reason unrelated to campaign performance: replies come back to those domains, and replies are the part of an outbound programme that carries real information about a prospect. Protecting the transport of your inbound mail is a small, ordinary piece of hygiene.
If you do publish, start in testing mode with a short max_age, watch for a few weeks, and only then raise the mode and the cache lifetime. That order costs a month of patience and removes the entire failure class where a certificate renewal takes your mail down. The same discipline applies to the related TLS-RPT record, which is the reporting channel that makes testing mode useful in the first place: without somewhere to send reports, testing mode observes nothing.
What the failure actually looks like
It is worth knowing the signature, because it mimics a reputation problem closely enough to send a team down the wrong path for a day.
A campaign is delivering normally. A small, stable set of recipient domains starts failing, and the failures do not spread. The failing domains have nothing in common commercially, no shared industry, no shared list source, and the same domains accepted mail last month. Meanwhile every other domain on the same sending inventory is unaffected, which rules out your reputation, because reputation is a property of the sender and would not select recipients this way.
That pattern says the problem is at the recipient end, and MTA-STS is one of a small number of things that produce it. A certificate expired on one of their MX hosts, or they added a host and forgot to list it in a policy still in enforce mode. Your sending platform, behaving correctly, is refusing to downgrade the connection.
There is no fix on your side, which is the useful conclusion. The recipient's mail team has a broken policy, and messages will resume when they repair it. What you should do is stop the affected addresses rather than let a sending platform retry into a wall for days, note the domains, and check whether the same set reappears on the next campaign. The general lesson generalises past this standard: before treating a bounce cluster as a sending problem, check whether the same inventory is delivering fine everywhere else. If it is, the cause is on the other side of the connection.
- Yes: The policy file is served over HTTPS with a valid certificate for mta-sts.<domain>
- Yes: Every MX host currently serving the domain is listed in the policy
- Yes: Mode starts at testing, with a reporting address that someone reads
- Yes: max_age starts short, so a mistake expires quickly
- Yes: Certificate expiry on the mail hosts is monitored before mode moves to enforce
- No: Publishing enforce mode on day one to look thorough
The short version
MTA-STS is a promise a domain makes to the internet about how mail should reach it: over TLS, to a named set of hosts, with no silent downgrade permitted. It is fetched over HTTPS so the promise cannot be forged, and cached so it survives the failure of the DNS that advertises it.
For a receiving domain it closes a genuine gap in SMTP. For a sending programme it is a fact about other people's infrastructure that occasionally explains a delivery failure, and a piece of hygiene worth applying to the domains your replies land on. It is not part of the deliverability stack, and no amount of it will change where your messages land; that work lives in authentication, in domain reputation and warmup, and in what you send. If placement is the actual problem, start with a deliverability audit rather than with transport security, and use MXToolbox to see what your domains publish today.
RevenueFlow runs cold email and LinkedIn outreach for B2B teams on sending infrastructure we configure and monitor ourselves. See how the campaigns work.
Specification behaviour verified as of August 2026 against RFC 8461. Verify current requirements with the source before relying on them.
Frequently asked questions.
Frequently asked questions- Does MTA-STS help my outbound campaigns reach the inbox?
- No. Publishing it instructs other servers about how to reach yours, so it governs mail arriving at your domain. Whether your campaigns are honoured by other domains policies is a property of your sending platform rather than something you configure. It has no bearing on placement, which is decided by authentication, reputation and content.
- Why is the policy served over HTTPS instead of DNS?
- DNS is unauthenticated for most domains, so a policy published only there could be forged or removed by exactly the attacker MTA-STS defends against. Serving it over HTTPS borrows the web certificate system: a sender validates a certificate before trusting the policy. The DNS record only advertises that a policy exists and signals when it has changed.
- What breaks when I turn on enforce mode?
- Anything that makes a listed host unreachable over validated TLS. An expired certificate on a mail host, or a new MX host missing from the policy, causes conforming senders to refuse delivery entirely. That is correct behaviour and it converts a certificate lapse into a mail outage, which is why testing mode exists and is worth staying in.
- Why is nothing being reported while I am in testing mode?
- Testing mode alone is silent. The companion TLS-RPT record is what causes senders to post daily summaries of successful and failed TLS connections to an address you nominate. Without it, a policy in testing mode is indistinguishable from no policy at all, which is the same failure shape as a DMARC record with no reporting address.