Why Email Security Moves in Provider-Sized Blocks

If you assumed that email security spreads one domain at a time, the data says otherwise.

Month two of a monthly measurement across the top million domains produced a finding that should change how you think about your email security exposure. DANE adoption fell in July, and it came down to a single provider. Migadu removed TLSA records for its entire customer fleet sometime in June. About 500 domains that had DANE in June did not have it in July. Nobody on those domains touched a thing, and most of them probably still do not know.

Take Migadu out of the numbers and DANE grew like the rest of the protocols.

This is the pattern underneath almost every month in the data: email security moves in provider-sized blocks, not domain by domain.

What One Provider Can Do to the Adoption Curve

The most striking example from the July data is not the DANE drop. It is what happened on the way back up.

Of 488 domains that gained DANE in July, 466 got it because they switched to a mail host that publishes DANE by default. Most of those 466 moved to Cloudflare Email Routing, which has DANE enabled for its customers automatically. About 60 of those domains were low-effort setups that had clearly never given email security a second thought. They switched hosts for convenience, and DANE arrived as a side effect.

One provider decision, 466 domains secured. No individual domain owner made that choice.

The same pattern shows up in MTA-STS. ALDI Sud switched the protocol on for eleven of its country domains in what was clearly one coordinated change. That is eleven domains that went from no MTA-STS policy to a valid, enforceable policy in a single afternoon, because someone at ALDI made one decision.

The month-over-month numbers from the measurement study make this concrete:

DMARC valid records: +2,282. Domains tightening their policy outnumbered loosening it 2,488 to 567.
DANE: down 249 as measured. Remove the Migadu deletions and it was up 258.
MTA-STS valid policies: +163, with 76 domains graduating from testing mode to enforce.
BIMI: +346.

These numbers look like steady, incremental progress. They are not. They are the net result of a small number of large provider moves layered on top of a much larger number of individual domain decisions.

The Gap Between Sender Authentication and Transport Security

Here is the number worth sitting with: if the current DMARC pace held, the protocol would reach near-universal deployment by the early 2030s. The two protocols that secure the connection between mail servers, MTA-STS and DANE, are on a track that runs into the 2040s and beyond.

Authenticating who sent the mail is almost solved. Protecting how it travels is more than a decade behind.

The reason is structural. DMARC is a DNS record that any domain owner can publish without cooperation from their mail provider. MTA-STS and DANE require the receiving side to also support the protocol. You can publish a valid MTA-STS policy, but if the destination mail server does not enforce TLS, MTA-STS does nothing for you.

This makes transport-layer email security a coordination problem. Both sides have to play, and the receiving side often has more leverage. A domain running Google Workspace or Microsoft 365 has limited ability to force receiving servers to upgrade their TLS posture.

Provider defaults amplify this gap. A hosted email provider that publishes MTA-STS by default for all its customers does more for transport security in one afternoon than thousands of individual domain owner decisions could accomplish over years.

What This Means for Your Domain

Two practical implications follow from this pattern.

First, you are more exposed to your mail provider's security defaults than you probably realize. If your provider enables DANE, you get it automatically. If they remove it, you lose it without knowing. If your provider does not support MTA-STS, you cannot enforce it for inbound mail from that provider's domains, no matter what you publish in DNS.

Second, your email security posture is partly a function of decisions you did not make. The 60 domains that picked up DANE from Cloudflare Email Routing did not choose DANE. They chose a host, and DANE came along. The 500 domains that lost DANE when Migadu deleted its TLSA records did not choose to lose it either.

This does not mean domain owners are powerless. It means the leverage point is different than the typical security advice suggests. Instead of asking "how do I configure DANE myself," the more useful question is "which providers have already made the right security defaults, and what happens to my DMARC reports when a provider changes those defaults for me."

What You Can Actually Control

You can control your DMARC policy. You can monitor your aggregate reports to catch provider-driven changes before they cause problems. And you can choose providers based on their security defaults, not just their price and uptime.

DMARC aggregate reports are worth highlighting here. When a provider changes DANE or MTA-STS defaults for their entire fleet, it shows up in your DMARC reports as a shift in authentication results. A sudden change in which IPs are passing alignment, or a spike in failures from providers you recognize, can be the first signal that something changed on their end without your knowledge.

For organizations managing email across multiple domains, this is where automation changes the picture. Watching DMARC reports manually across dozens or hundreds of domains is tedious enough that most teams do not do it consistently. That creates a blind spot precisely when provider-sized changes hit: you lose DANE, you see a few bounces, and you spend days figuring out why.

DMARCFlow aggregates DMARC reports across all your domains in one view, which makes it harder for provider-driven changes to stay invisible. When a single provider removes TLSA records for hundreds of domains overnight, a dashboard showing all your DMARC results catches it faster than waiting for a help desk ticket.

The practitioners running this monthly measurement are not academic researchers. They run an email infrastructure company and they are publishing this data because the pattern is relevant to anyone making decisions about email security. The takeaway is not that individual domain owners should ignore email security. It is that the real lever in email security is often at the provider level, and the organizations most likely to notice when that lever moves are the ones watching their aggregate reports consistently.

Email security does not spread one domain at a time. It moves in chunks, and the chunks are getting bigger.

FAQ

Why do DANE and MTA-STS grow more slowly than DMARC?

DMARC is a DNS record a domain owner can publish independently. DANE and MTA-STS require coordination with the receiving mail server, making them harder to deploy unilaterally. Provider defaults fill that gap for hosted email, but the receiving-side requirement keeps overall adoption lower.

Can I deploy DANE without my email provider's help?

Partially. You can publish TLSA records for your own mail servers. But if your MX hosts are managed by a third party, you need that provider to support DANE for it to work for your inbound mail.

How would I know if my provider changed its email security defaults?

The first signal usually shows up in your DMARC aggregate reports. A sudden change in authentication results from a provider you recognize often means they changed something on their end. If you are not reading those reports regularly, you may not find out until mail starts bouncing.

Does this mean individual domain owners have little control over email security?

They have less control over transport-layer security than sender authentication. But DMARC policy is entirely in the domain owner's hands, and monitoring aggregate reports across all your domains is something you can do regardless of who your provider is.