The state of email authentication, August 2026

This is the third month of our measurement of how the top million domains actually deploy the four major email-security protocols. DMARC is the policy layer that decides what a receiver should do with mail claiming to be from you that doesn't pass SPF or DKIM. BIMI puts your logo on mail that already passed DMARC, so it authorizes nothing by itself. MTA-STS and DANE both govern whether the connection carrying your mail is encrypted, DANE by publishing your mail server's certificate fingerprint in DNS, signed with DNSSEC, in a record type called TLSA. June was the baseline. July was the first set of deltas, and the story there was Migadu deleting the TLSA records for its entire customer fleet and single-handedly pushing DANE negative.

This month DANE grew 5.2%, the fastest monthly rate we've recorded for any protocol. 85% of that growth is Strato, a large German host, switching TLSA on for its entire customer base.

Same mechanism, opposite sign, two months running. These protocols move in provider-sized blocks, not domain-sized ones, and August made that case more cleanly than July did.

There's also something new this month. MTA-STS and DANE are both ways for a domain to tell senders to use TLS. Neither says anything about what the receiving server does when a sender ignores that. So we asked the servers directly, and the answer is that almost none of them enforce anything.

The August numbers

Of the 699,932 mail-eligible domains in the August top 1M (mail-eligible meaning the domain publishes an MX record other than a null MX, the record that explicitly announces it accepts no mail):

Look at the MTA-STS row. It went down by five domains. Now look at what actually happened: 237 domains turned MTA-STS on this month and 64 turned it off, a net gain of 173.

Both are true, and the gap between them is the most important thing to understand about this dataset.

Why the raw numbers lie

Cloudflare Radar's top 1M is a living list, rebuilt weekly from DNS traffic, and a quarter of it turned over between July and August. Only 752,415 domains appear in both months.

That churn is mostly noise. Domains falling off the list overwhelmingly keep the same mail provider across the gap, so leaving the top 1M is a dip in relative popularity rather than a change to anyone's mail setup. A raw month-over-month delta therefore mixes two unrelated things: domains actually changing their DNS, and the list swapping a quarter of a million low-traffic tail domains for a different quarter of a million.

So every delta below is computed on one fixed population: the 547,977 domains that were mail-eligible in both months and that we measured cleanly in both.

Every protocol grew. The raw list said MTA-STS shrank and DMARC lost 14,000 domains. Neither happened.

DANE: one provider turned it on

In June, Migadu deleted its TLSA records and 500 domains lost DANE overnight. Sometime in July, Strato added them, and a thousand domains gained it.

The mechanism is identical, just reversed. Strato's customers point their MX at three shared hosts. Our July run found no TLSA records on them; our August run finds one shared certificate fingerprint published across all three, covering every customer at once. Of the 1,001 Strato-hosted domains in our fixed population, 3 had DANE in July and 998 have it in August: 995 domains gaining it in one month from one change.

It is properly signed and genuinely usable, which we confirmed against Strato's own nameservers rather than trusting our own snapshot.

Now the part that matters more than the headline. Strip Strato out and the remaining same-domain change is +175 domains, or +0.77% for the month. Next to last month:

The headline rate swung by more than six and a half points between two consecutive months. The underlying rate moved by five hundredths of a point.

Organic DANE adoption, meaning domain owners publishing TLSA records on MX hosts they already control, is a slow steady climb of about 0.8% a month. Everything dramatic in the headline is provider decisions.

That reframes what DANE adoption even is. It is not 32,000 domains choosing a protocol. It is a few dozen hosting companies choosing it, and their customers inheriting the result without being consulted in either direction. The 995 Strato customers who gained inbound transport security this month did nothing to earn it, and the 500 Migadu customers who lost it in June did nothing to deserve that.

Migadu's records, incidentally, have not come back. The only hyperscaler moving in the other direction is Microsoft, whose newer mx.microsoft endpoints now carry DANE for 641 of the 23,766 DANE publishers in our fixed population, or 2.7%. Small, but not nothing: that's two thirds the size of the Strato event, arriving quietly rather than all at once, and it is the only crack in the hyperscaler wall.

Why one provider can move a fifth of the internet's mail

There is a structural reason a single provider can move numbers this big, and it is worth seeing in full.

The top million's mail collapses hard. 1,610,680 MX record references resolve down to 366,215 unique hostnames, and those to just 155,923 distinct addresses.

They are distributed like a barbell. One address, 142.250.27.27, which is aspmx.l.google.com, is an MX for 138,006 domains: just under 20% of every mail-eligible domain in the top million, behind a single A record.

At the other end, 122,053 addresses serve exactly one domain each. They aren't one per domain, because a self-hoster running mx1 and mx2 on two dedicated addresses counts twice; between them they cover 105,628 domains, 15.1% of the total. The address space is mostly self-hosters; the domains are mostly on a handful of endpoints.

Those big addresses are anycast, fronting global fleets, so this is not "20% of the world's mail runs on one machine." But the concentration that matters here is administrative, and that part is entirely real. One configuration change, at one operator, reaches nearly a fifth of every mail-eligible domain in the top million. Strato moving 995 domains in a month is not an anomaly in this topology. It is what the topology is for.

Who actually refuses unencrypted mail

A reader asked a good question after the July post: how many MX servers refuse connections that aren't encrypted?

It's sharper than it sounds. Publishing MTA-STS or DANE binds a sender that checks: a conforming one has to abort delivery rather than fall back to cleartext. What it can't do is bind the receiver, or a sender that never looks. A domain can publish the strictest policy there is and still cheerfully accept plaintext from anyone who doesn't check.

So we connected to all 366,215 unique MX hosts on port 25, read the EHLO capability list, and tried to start a mail transaction in the clear. 290,230 gave a conclusive answer; the rest were dead, silent, or turned us away for reasons unrelated to TLS, which the methodology section breaks down. Of the ones that answered:

Two in a thousand. Per domain it's thinner still. Counting only the 620,240 domains where every single one of their MX hosts gave us an answer, 598 of them, 0.096%, require TLS across the board.

That number is low for a reason worth sitting with. Requiring inbound TLS means bouncing mail from any sender that can't do TLS, and unlike publishing a policy, that decision has a victim: the correspondent on some ancient system whose message now fails. Almost nobody makes that trade, and that's a defensible choice rather than a failure.

The interesting question is whether the domains that ask for TLS are the ones that enforce it:

(The DANE row covers 29,646 of the 31,891 DANE publishers, 93%: the rest had at least one MX host we couldn't get an answer from.)

The two protocols split completely. A domain publishing MTA-STS at enforce is 8.5 times likelier than average to also enforce TLS inbound: a real, if modest, signal. A domain publishing DANE is 1.2 times likelier, which is no signal at all.

That fits everything else this month. MTA-STS is still mostly something an operator switches on deliberately. DANE is overwhelmingly inherited from a provider default, and a default tells you nothing about the intentions of the domain that inherited it.

Either way the absolute numbers are brutal. 99.18% of the domains publishing an enforce policy, the ones explicitly telling the world "you must use TLS to reach me," will accept your plaintext mail without complaint.

Who the 598 are

We went looking for an industry pattern and mostly didn't find one. What we found instead was geography. German-speaking and Central Europe are wildly over-represented:

Enrichment is each TLD's share of the 598 enforcers divided by its share of mail-eligible domains, computed from the counts shown.

Add .ch (4 enforcers) and German-speaking Europe is 15.4% of the enforcers against 3.8% of mail-eligible domains. The names skew toward regulated sectors: comdirect and DZ Bank, the German government's own debt agency, two hospital groups, a regional authority, a rural district and a city government. Banks, hospitals and government, with the grocery chain Edeka as the odd one out.

The obvious explanation is regulatory: Germany's BSI TR-03108 sets secure-transport requirements for mail providers, and GDPR has pushed European health and finance toward encryption-by-default harder than elsewhere. We've measured the clustering, not the cause, so treat that as a hypothesis.

The second pattern you can probably guess by now. 71 of the 598 run on AWS SES Mail Manager, and 13 of that product's 14 measured hostnames enforce TLS. That is 93%, which is not 71 independent security decisions. It is a product shipping mandatory TLS by default. The customer list gives it away: 22 of the 71 are online casinos and gambling affiliates, another 36 are SEO and content-farm domains including seven near-identical .live search-spam sites, and the recognizable names left over are Supercell's clashroyale.com and SAP's concursolutions.com. Nobody in that first group made a considered decision about transport security.

Meanwhile the providers carrying most of the world's mail enforce essentially nothing:

There is exactly one exception in Microsoft's entire estate. Its MX hostnames collapse onto just 130 addresses, and one of those refuses cleartext: not a 365 tenant endpoint, and not one of the consumer frontends either, but outlook.com itself. It looks isolated rather than the leading edge of a rollout, since the consumer domains that would flip first all still accept plaintext. Worth re-checking in September.

So TLS enforcement isn't an industry story. The two visible patterns are a regulatory cluster in German-speaking Europe and one AWS product default, and between them they account for about a quarter of the 598; the rest are scattered one-offs, sitting on top of an ecosystem where the hyperscalers require nothing. Which is also why 248 of the 598, 41%, run their MX in their own domain rather than a provider's: for most of the world, if you want this, you have to run the server yourself.

The other three protocols

The two transport-security protocols above are stuck in the low single digits. DMARC is the outlier: 63.6% of mail-eligible domains publish a valid record, and it's the only one of the four operating at real scale.

It's also the one where the movement is broadest. Among domains with a valid record in both months, 2,570 tightened their policy and 535 loosened it, a 4.8-to-1 ratio in favor of getting stricter. And no single vendor is behind it: every large provider tightens more than it loosens, at rates ranging from 0.34% of the domains it hosts to 1.22%. Thousands of unrelated operators independently deciding to move from monitoring to enforcement is the healthiest pattern in this dataset, and it's the reason DMARC is the only protocol here on a timeline that matters.

MTA-STS grew 2.45%, the faster of the two months we've measured, and 56 domains graduated from testing (collect failure reports, change nothing) to enforce (actually refuse non-compliant delivery) against 15 going the other way. The funnel still leaks in the same place: 9,896 domains publish a valid _mta-sts TXT record but only 8,099 have a policy file the world can actually fetch. Roughly 1,800 domains are advertising a policy nobody can read, which is worth checking if you're one of them.

BIMI added 350 publishers against 27 losses, and 111 of the new ones bought a Verified Mark Certificate, the part that actually gets a logo rendered in an inbox. Allianz, AT&T, AOK and Burt's Bees are in this month's cohort. One caveat matters for BIMI: it's a sender-side brand signal, often published on a different domain than the one that receives mail, so our count undercounts and should never be read as symmetrical with the other three.

If these rates held

Two months of same-domain readings is enough to ask when each protocol would reach every mail-eligible domain, if it kept growing at exactly this pace. Both the share and the rate below are measured on the 547,977 domains present in both months. That's a different set from the one July's equivalent table used, so read the shares against each other rather than against last month's.

DANE's share includes the Strato jump; its rate is the organic one with that event removed, which is why the two look mismatched.

Read the near end and ignore the far end: real adoption follows an S-curve rather than compounding forever, and BIMI will never reach 100% anyway because most domains don't send branded mail.

But the shape is the point, and it is the single most important thing in this post. Authenticating who sent a message is on track to be universal within a decade. Protecting how that message travels is not on track at all. DMARC reaches most of the internet in the early 2030s. The two protocols that secure the connection between mail servers run past 2040, and DANE's underlying rate is slow enough that its future will be decided by a handful of hosting companies rather than by adoption in any normal sense.

What this means if you run mail

If your DANE comes from your provider, monitor it. This is the second month running where one provider decision moved between five hundred and a thousand domains in or out of DANE without their owners doing anything. A cron job that runs dig TLSA _25._tcp.<your-mx> and alerts on an unexpected empty answer is twenty minutes of work, and it's the difference between knowing and finding out.

Check that your MTA-STS policy is actually fetchable. About 1,800 domains publish a valid TXT record pointing at a policy file that can't be read from outside their network. Fetch your own https://mta-sts.<domain>/.well-known/mta-sts.txt on a schedule, from somewhere that isn't your own network.

Don't confuse publishing with enforcing. If you've deployed MTA-STS or DANE, you've told senders what you'd prefer. You have not required anything. Requiring inbound TLS is a separate decision with real deliverability consequences that only 0.2% of servers make. Just know which one you've actually done.

And if you're starting from zero, the order is clear from the data. DMARC first, and move to quarantine or reject rather than parking at p=none: it's the protocol with real adoption, real momentum, and the clearest payoff. Then MTA-STS, which is cheap to publish and, unlike DANE, doesn't require you to run DNSSEC. DANE if your provider offers it, since in practice that's how almost everyone gets it. Requiring inbound TLS is the last step, and the one with the bluntest failure mode: a DMARC policy costs you mail you didn't authorize, while refusing cleartext costs you mail from anyone who can't do TLS at all. Make that one on purpose.

How we measured this

The four DNS-based protocols are measured from 30 small machines spread across 30 regions on every populated continent. Every answer has to be confirmed by two resolvers in different regions and from different providers before we record it, we use only unfiltered resolvers (filtering resolvers return NXDOMAIN for blocklisted domains, which silently corrupts a census), and the whole run is paced across two hours so we never lean on anyone's infrastructure. The June post has the full detail.

A domain counts as unmeasurable only when a lookup hard-fails everywhere, which is different from a clean "no record" answer. Those domains are excluded from the relevant denominator rather than counted as non-adopters. This month that was 1,369 of 699,932 mail-eligible domains, 0.196%, in every case because the domain's MTA-STS policy host was unreachable from every vantage point. The four DNS lookups had none.

The port-25 measurement is a different kind of measurement, and needs its own caveats. DNS has no opinion about who is asking; a mail server can refuse to talk to you. Of the 366,215 hostnames, 16,113 had no address to dial at all, 54,940 resolved but wouldn't hold an SMTP conversation, and 4,932 reached a real server that turned us away for reasons unrelated to TLS, like greylisting or IP reputation. All three groups are excluded from the denominator rather than counted as "doesn't require TLS," because folding them in would bias the result in exactly the flattering direction.

Two limits are worth stating plainly. The probe stops at MAIL FROM with a null sender, never sending RCPT or DATA, so it never delivers mail and never does anything resembling a sender callout. The price of that restraint is that a server enforcing TLS only at a later stage looks opportunistic to us, which makes 0.20% a floor rather than a ceiling. And excluding hosts that refuse your prober is never neutral, because those hosts are not a random sample of the internet.

What's next

The September reading lands in early September. Four things worth watching: whether Strato's TLSA records stay up, since Migadu's never came back; whether any other large host follows; whether that single Microsoft address spreads to the rest of an estate that is otherwise uniformly opportunistic; and whether the port-25 enforcement number moves at all. Our guess on the last one is that it doesn't, and that it stays the most stable number in this dataset, because it's the only one that costs the operator something real.

If you run mail for a domain in the top million, you're in this data. The deltas are where the story is, and for the second month running the story is that the decisions are being made by a handful of providers on behalf of everyone else.