Half of MTA-STS Deployments Enforce Nothing (2026 Study)

Every email standard you have heard of authenticates the message. SPF says who may send, DKIM proves the content was not altered, DMARC ties the two together. None of them protects the connection. A network attacker who can strip the STARTTLS upgrade reads your mail in plaintext, and every one of those records still passes.

MTA-STS (RFC 8461) is the answer to that. It lets a domain say: always use TLS to reach me, only trust these MX hosts, and refuse delivery rather than fall back.

It also has an unusual design. It requires two independent things to be right at the same time:

1. a DNS TXT record at _mta-sts.<domain> announcing a policy id, and
2. a policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt, with a certificate valid for that hostname.

Only the first is visible to a DNS lookup. That is the half almost every "do you have MTA-STS?" checker inspects, and it is the half that tells you the least — because the policy file is where the word enforce either does or does not appear.

We measured both halves across the top 5,000 domains on the web. 133 announce MTA-STS. 70 enforce it.

This is our own measurement, run on 27 August 2026. Method below, harvesting script included.

The headline numbers

Of 5,000 domains, 3,504 receive mail (they publish an MX record). Among those:

Adoption is small, which is not the interesting part — MTA-STS is newer and harder to deploy than DMARC, and 3.8% is roughly what you would expect. The interesting part is what happens to the 133 once you fetch the second half:

47.4% of domains that announce MTA-STS are not protected by it. A checker that stops at DNS reports all 133 identically.

We re-probed all 133 on 31 August, four days after the harvest. Exactly 70 still enforce — the headline is not an artefact of one afternoon. Nine domains moved between the non-enforcing categories, which is the churn you would expect and which changes none of the conclusions. The two that affect named examples are recorded under Corrections.

Four ways to have MTA-STS and get nothing

1. Testing mode — 51 domains

mode: testing means the receiving domain wants failure reports but does not want senders to actually refuse delivery. Nothing is enforced. It is the correct first step, explicitly designed into the standard, and it deserves to be described fairly: these domains have done real work, and doing it in this order is what the RFC recommends.

It is also a step organisations stop on. Among the 51:

facebook.com · yahoo.com · office.com · office365.com · mail.ru · theguardian.com · t-online.de · ikea.com · sophos.com · worldbank.org · dynatrace.com · onet.pl

Microsoft is the clearest illustration that this is a deliberate per-domain decision rather than an accident: outlook.com and live.com enforce, while office.com and office365.com test. The mail domains are protected; the app domains are watching.

Five of the 51 testing-mode domains publish no TLS-RPT record at all, which is the one combination that cannot be defended. Testing mode's entire purpose is to collect reports before you enforce. Without a reporting address there are no reports, so the policy is not a stage on the way to enforcement — it is a permanent no-op.

2. Announced in DNS, never served — 9 domains

These publish the _mta-sts TXT record, so every DNS-based checker calls them adopters, and then serve nothing usable at the policy URL:

We re-checked each of these by hand, separately from the harvester. cloudflare.com is the starkest: the DNS record is there and current, and the hostname the standard requires simply has no address record.

The sonos.com 403 is worth a note, because a wrong reading was available and we checked rather than assumed. A 403 could be a web firewall refusing unusual clients rather than a genuinely absent file. We retried with a browser user-agent and with none at all, on two separate days; it returned 403 every time. From a sending mail server's point of view the policy is unfetchable either way.

3. A policy URL that answers 200 with something that is not a policy — 1 domain

twingate.com was the case worth dwelling on, because it defeats a whole class of checker. On 27 August the DNS record was present and the policy URL returned HTTP 200. A checker that verifies "the file is reachable" passed it.

The body was an HTML page — a Next.js site served from Google Cloud Storage, six kilobytes of markup where the standard expects half a dozen key: value lines. It parsed to no version, no mode, no mx entries. A sending MTA got a well-formed HTTP success carrying nothing it could use.

Since 31 August that URL returns a clean 404, so Twingate has moved from this category into the previous one. We are not claiming credit for the change and have no idea whether anyone there saw this. What matters for the reader is that we found it by re-checking rather than by being told, and that we are telling you the example is no longer live: at the time of writing no domain in this sample serves a 200 carrying a non-policy. One in 133 did four days ago.

This is still the failure mode that argues hardest for parsing rather than probing, and it is the one we would least like to be wrong about, because reachability is not validity and the gap between them returns a green tick. But a reader who tries to reproduce it on twingate.com today will not, and saying so is cheaper than being caught.

4. Explicitly switched off — 2 domains

wpastra.com and immobilienscout24.de serve a valid policy that says mode: none. That is the standard's documented way to withdraw a policy without breaking senders who cached it, so it is correct behaviour — but a DNS-only checker counts them as adopters too.

What we expected to find and did not

Going in, the failure we most expected was enforce-mode policies whose mx: patterns no longer match the domain's real MX hosts. That is the dangerous one: a sender obeying the policy would refuse the actual mail servers, so a stale policy would break delivery rather than merely fail to protect it.

Of 70 enforcing domains, zero had a mismatch. Every enforce-mode policy correctly covered the live MX hosts, wildcards included.

That is a negative result and we are reporting it as one. The plausible explanation is survivorship: a policy that stops matching your MX causes mail to bounce, someone notices within hours, and it is fixed or withdrawn. The failure mode is real but self-clearing, which is exactly why a snapshot does not catch it. The failures that persist are the silent ones — testing mode and missing files — because nothing breaks when you get those wrong.

Reporting is more common than the thing being reported on

162 domains publish a TLS-RPT record (RFC 8460), against 133 publishing MTA-STS. 46 have TLS-RPT and no MTA-STS at all, including linkedin.com, mozilla.com, duckduckgo.com, opera.com, zoho.com and britannica.com.

This is not a mistake. TLS-RPT reports on opportunistic TLS as well as on MTA-STS policies, so a reporting address collects useful data on its own, and turning it on first is a sensible way to see your traffic before committing to a policy. It is worth naming because it inverts the assumption that reporting follows enforcement — for a third of these domains, reporting is all there is.

Two smaller findings

max_age is often short. The RFC recommends a policy lifetime of at least a week (604,800 seconds) so senders keep the policy cached even if your web host has an outage. Of 122 policies stating a value, 37 are below that. The good news is that the single most common setting is the recommended week exactly (55 domains); the gap is a second cluster of 31 domains at exactly one day. A short lifetime means a sender re-fetches often, and every fetch is a chance to fail open.

Adoption does not rise with rank. Splitting the mail-receiving domains into five bands of 1,000:

Flat, within noise. Unlike DMARC — which climbs sharply at the top of the list — being a bigger site does not make MTA-STS more likely. It is still a specialist deployment rather than a default.

What to do about it

If you have MTA-STS: fetch your own policy file from outside your network and read the mode: line. Those are two different checks and the first is the one that gets skipped. If it says testing, confirm you have a TLS-RPT address and that someone reads the reports — otherwise you are in a holding pattern with no exit condition.

If you are choosing a checker: ask whether it fetches the policy. A tool reporting "MTA-STS: found" from a DNS lookup alone cannot distinguish enforce from testing from a file that 404s, and those are the whole question.

If you are deploying it: publish the policy file first and the DNS record second. In that order a mistake is invisible; in the other order you spend the gap advertising a policy nobody can fetch.

Method

Sample. The Tranco top 5,000, list ID ZJGPG — the same list our DMARC, provider market share, SPF lookup-limit and DKIM selector studies use, so all five join on domain.

DNS. For each domain, three DNS-over-HTTPS queries against Cloudflare's 1.1.1.1: TXT at _mta-sts.<domain>, TXT at _smtp._tls.<domain>, and MX at the apex. A record counts only if it begins v=STSv1.

Policy fetch. Where the DNS record exists, one HTTPS GET to https://mta-sts.<domain>/.well-known/mta-sts.txt with a 10-second timeout. Redirects are not followed, per RFC 8461 §3.3: a policy reachable only through a 3xx is not a valid policy. No domain in this sample redirected, so this changes none of the numbers here — but a harvester that follows redirects would silently count one that did. Failures are categorised rather than collapsed into "no policy", because a 404 and a certificate error are different mistakes with different fixes.

Parsing follows RFC 8461 §3.2 — key: value lines, with mx repeatable. MX matching implements the §4.1 wildcard rule, where a leading *. matches exactly one label.

Reproducing it. The script is committed at scripts/study-mta-sts.mjs:

node scripts/study-mta-sts.mjs tranco.csv 5000 out.json

Limitations

We did not connect to any mail server. Everything here is DNS and HTTPS. Whether a sending MTA honours these policies, and whether the MX hosts actually present valid TLS on port 25, needs SMTP and is not measured. We make no claim about delivery outcomes — the same rule our SPF study follows when it reports that policies cannot be evaluated as specified without claiming mail was rejected.

One network, one moment. All fetches came from a single host on 27 August 2026. A policy URL that timed out for us might answer from elsewhere, and geo-restricted or rate-limited hosts would look like failures. This is why the failure categories are reported separately rather than summed into one number, and why every named failure was re-tested by hand on a second day — which is how the zapier.com correction below was found.

133 is a small numerator. The percentages within the adopter group — 52.6% enforcing, 38.3% testing — rest on a base of 133 domains. The direction is clear and the named examples are individually checkable, but a second sample would move these by a few points. The per-provider splits are smaller still and we have deliberately not published percentages for them.

Testing mode is not a defect. We have counted it as "not enforcing", which is factually what it is, but the RFC recommends deploying that way first. A domain in testing mode may be days from enforcing. What we can say is that it provides no protection today, and that no DNS-only checker will tell you which of the two you are looking at.

Corrections

28 August 2026 — zapier.com was named wrongly. The harvest recorded a 403 at mta-sts.zapier.com and this article listed Zapier among the domains that announce a policy and never serve one. Re-probing the next day returned HTTP 200 and a valid mode: testing policy, five times out of five. The original 403 was almost certainly a web firewall reacting to a burst of concurrent requests, not an absent file.

Zapier has therefore moved from "never served" to "testing mode", and two counts changed with it: testing 50 → 51, never served 10 → 9. The headline is untouched — 133 announce, 70 enforce, 52.6% — because a testing-mode policy and a missing one are both "not enforcing".

The lesson is worth more than the number. A single automated probe is enough to count a category and not enough to name a company. Every other domain named in this article was re-tested five times on a second day from the same host, and the other nine failures reproduced identically every time.

31 August 2026 — two named domains have changed, and a re-probe confirms the headline. Four days after publication we re-probed all 133 announcing domains using the same evaluator the site's checker runs. Enforce is still exactly 70. Two domains this article names by name have moved:

• twingate.com, the whole of section 3, now returns a clean 404 at its policy URL instead of HTTP 200 with an HTML page. The measurement on 27 August stands and the section has been re-worded into the past tense. As of today no domain in this sample exhibits that failure, so the example is no longer reproducible — stated plainly rather than left for a reader to discover.
• t-online.de, listed as a testing-mode example, now fails with a TLS error at mta-sts.t-online.de and serves no usable policy. It has moved from "testing" to "announced, never served". The counts as measured on 27 August are unchanged; today's equivalents would be testing 50 and never-served 11.

Both were found by bun run check:study-claims, which re-probes every domain this article names against the claim made about it. That script exists because of the zapier.com error below: naming a real company's configuration is the most checkable thing on this site and the fastest to rot, and until 31 August nothing watched it.

Redirects. The published harvester followed HTTP redirects when fetching policy files. RFC 8461 §3.3 says they must not be followed, so a policy reachable only via a 3xx should count as absent. We re-fetched all 133 announcing domains with redirects disabled: none redirected, so no published number depended on it. The script has been corrected anyway, because the next person to run it may not be so lucky.