Blog · Dmarc
What DANE Adoption Data Reveals About the State of Email Authentication in 2026
Tracking email authentication adoption across the top one million domains is now a monthly practice. The second round of data is in, and the headline finding is not the one the industry expected: DANE adoption fell, and it came down to a single provider.
The measurement tracks four protocols across a monthly snapshot of the top 1M domains by Alexa ranking (or equivalent):
- DMARC - domain-based message authentication, reporting, and conformance
- MTA-STS - SMTP MTA strict transport security
- DANE - DNS-based authentication of named entities (using TLSA records)
- BIMI - brand indicators for message identification
Month two of measurement shows DANE numbers dropping. Not a gradual decline. A sharp move downward tied to one large email provider withdrawing DANE support during the measurement window.
The other three protocols held roughly flat or showed modest gains. DMARC enforcement continued its slow climb. MTA-STS adoption remained low but stable. BIMI stayed rare.
Why One Provider Move Matters More Than the Protocol
DANE requires both the sending domain and the receiving provider to support it. If a large provider decides DANE is not worth operating, the aggregate adoption number moves regardless of how many domains have published TLSA records.
This is the fundamental asymmetry in DANE adoption: it is provider-dependent in a way DMARC is not. A domain can publish a perfect DMARC record and receive reports from hundreds of receivers. Publishing a TLSA record only helps if the receiving MTA actually looks it up.
The practical effect is that DANE adoption is a function of provider support, not protocol design.
DMARC, MTA-STS, DANE, BIMI: A Side-by-Side Comparison
| Protocol | What It Protects | Requires Provider Support | Adoption Level |
|---|---|---|---|
| DMARC | From-address domain spoofing | No - domain owner only | Moderate and growing |
| MTA-STS | SMTP transport encryption | No - domain owner only | Low but stable |
| DANE | TLS certificate validity for SMTP | Yes - receiving MTA must check | Very low, stalled |
| BIMI | Brand logo in supported mail clients | Partially - client support varies | Very rare |
DMARC and MTA-STS are domain-owner decisions. They do not depend on receiver cooperation beyond basic protocol support. DANE does.
What This Means for Your Email Authentication Strategy
Three things stand out from this data.
First, the protocols that require only domain-owner action (DMARC, MTA-STS) are more reliable bets than those requiring receiver infrastructure changes (DANE). If you are deciding where to invest your email authentication budget, DMARC reporting and enforcement is the highest-return move.
Second, aggregate ecosystem data is interesting but not immediately actionable for your domain. The DANE decline was caused by a provider decision you have no control over. What matters more is whether your own domain's authentication is configured correctly, passing for legitimate senders, and failing for spoofing attempts.
Third, monitoring your own domain's authentication posture matters more than celebrating ecosystem trends. DMARCFlow gives you the same reporting infrastructure that drives these ecosystem studies, but focused on your own domain.
How to Monitor Your Own Email Authentication Posture
DMARCFlow collects and parses DMARC aggregate reports from receivers, giving you the same visibility that drives ecosystem studies, but focused on your own domain.
You can set up alerts for:
- Sudden drops in DMARC pass rates (which may indicate a provider change affecting your mail flow)
- New unauthorized sending sources appearing in your aggregate reports
- Alignment failures from vendors or forwarding chains
- SPF and DKIM failures that suggest configuration drift
The monthly ecosystem studies are useful context. Your own domain's data is the signal that actually matters for your operations.
FAQ
Does a DANE adoption decline mean DANE is a bad protocol?
No. DANE is a well-designed protocol with strong security properties. The problem is adoption mechanics, not protocol quality. Wide DANE adoption requires receiver MTA support at scale, which has not materialized.
Should I remove my TLSA records if DANE adoption is falling?
No. If you have TLSA records published and your receiving infrastructure supports DANE, leaving them in place costs nothing and adds transport security for the fraction of mail that does use DANE. The records are not hurting you.
Is MTA-STS a better investment than DANE?
For most domain owners, yes. MTA-STS tells receiving MTAs to only deliver mail over TLS and to validate certificates. Unlike DANE, it does not require the receiver to look up your TLSA records. It is a policy signal that modern mail systems already respect.
How does BIMI fit into this picture?
BIMI requires both DNS publication and mail client support. Apple Mail, Gmail, and a few other clients render BIMI logos. Support is growing but still limited. BIMI is a brand play, not a security control. Do not treat it as a substitute for DMARC enforcement.
The Bottom Line
DANE adoption fell in month two of measurement because one large provider stopped supporting it. That is not a vote of no confidence in the protocol. It is a reminder that email authentication adoption is driven by provider economics, not protocol merit alone.
For domain owners, the practical takeaway is simple: focus on what you control. Run DMARC in enforcement mode. Monitor your aggregate reports. Catch configuration drift before it becomes a deliverability problem.
DMARCFlow handles the monitoring and alerting. The ecosystem data is worth watching. Your own domain's data is what you can act on.