The standard line on DANE is that it’s a tragedy. A cryptographically clean idea — pin your TLS certificate directly in DNS, skip the certificate authorities entirely — stranded behind DNSSEC, a dependency most of the internet never bothered to deploy. Beautiful on paper, dead in practice. I’ve written that line myself.
It’s wrong, or at least it’s only true if you’re standing in the United States looking at Gmail. Move your vantage point a few thousand kilometers east and DANE isn’t a cautionary tale. It’s mandatory. The Dutch government requires it. German mail providers run it by default. As of late 2025, roughly one in seven Dutch organizations had DANE on their mail servers — more than twice the MTA-STS adoption in the same survey — and the number of cryptographically anchored mail gateways in the .nl zone had roughly doubled in six months. Then in early 2026 Microsoft, of all companies, started shipping DANE validation in Exchange Online. The protocol everyone agreed was dead is having the best year of its life.
So which is it — failed standard or quiet success? The honest answer is both, and the split runs exactly along the line between the web and email. Same protocol, RFC 6698, two completely different fates depending on what it’s protecting. That divergence is the interesting part, and it says something real about how security standards actually win or lose.
What DANE actually is
Strip away the acronym and DANE is one stubborn idea: the people who already control a domain’s DNS should be allowed to say which certificate is legitimate for that domain, without asking a certificate authority for permission.
You publish a TLSA record. It lives at a name that encodes the port and protocol — for a mail server it’s _25._tcp.mail.example.com, port 25 over TCP — and it carries three small numbers and a hash. The numbers are a usage, a selector, and a matching type. The most common combination is 3 1 1, which reads as: this is the end-entity certificate itself (usage 3, “DANE-EE,” no CA involved), I’m pinning the public key (selector 1), and here’s its SHA-256 hash (matching type 1). A sending server resolves that record, completes the TLS handshake, hashes the key the other end presented, and compares. Match, deliver. No match, refuse. The certificate authority system — the 150-odd roots your browser trusts, the entire apparatus of paid validation — is simply not in the loop. DNS is the trust anchor.
Which is exactly why it can’t work without DNSSEC. A TLSA record you fetched over plain DNS is worthless: the same network attacker who could swap a certificate could swap the TLSA record that’s supposed to catch them. DANE’s security is borrowed entirely from DNSSEC’s chain of signatures. No signed zone, no DANE. That’s the dependency everyone points at, and it’s real. It’s just not the whole story.
Why the web rejected it
On the web, DANE lost cleanly, and it’s worth being clear-eyed that it deserved to.
There was a serious effort to bring DANE to browsers — pin your HTTPS cert in a TLSA record, let the browser check it, cut the CAs out of web PKI too. It went nowhere. Browsers never shipped TLSA validation. The proposal to staple DANE records into the TLS handshake so browsers wouldn’t even need to do their own DNSSEC lookups stalled out and the vendors walked away. Today no major browser validates DANE for HTTPS. On the web, the standard line is simply correct: it’s dead.
The reasons are specific, not mystical. A browser does a TLS handshake in tens of milliseconds against a server the user is actively waiting on; bolting a full DNSSEC validation chain onto that hot path, for every connection, was latency nobody wanted. Browsers had already built a different answer to the certificate-trust problem — Certificate Transparency logs, which make every issued certificate publicly auditable, plus HSTS preload lists baked into the browser binary. They didn’t need DNS to be the trust anchor because they’d made the CA system itself observable. And critically, the web’s clients are billions of end users on every imaginable network, where a broken DNSSEC chain means a blank error page and a support call. The blast radius of “DNSSEC mistake breaks the site” was unacceptable.
Every one of those reasons evaporates when you move to email.
Why email kept it
Server-to-server SMTP is a different world, and it’s the world DANE was quietly built for.
Start with the clients: they’re not people, they’re mail servers run by administrators. Postfix and Exim have supported DANE for years. The population that has to “manage DNSSEC” isn’t a billion phone users, it’s a few thousand mail operators who already live in DNS for a living and can sign a zone without filing a support ticket. The hot-path latency objection doesn’t apply either — nobody is staring at a progress bar while two mail servers negotiate; an extra DNS round trip on delivery is invisible.
And the alternative is weaker than people admit. The MTA-STS approach — publish your TLS policy as a web page and have senders trust it on first use — works, and Google bet Gmail on it in 2019. But it’s trust-on-first-use: the very first time a sender contacts you, with no cached policy, an attacker who can block that one HTTPS request leaves the sender none the wiser. DANE has no first-use gap, because the check happens in DNS, cryptographically signed, on every single connection. For email, where the whole threat is an active attacker stripping encryption in the path, that difference is the entire point. SMTP also never got a Certificate Transparency or an HSTS-preload equivalent, so the web’s reasons for not needing DANE simply don’t exist here. The gap DANE fills on the web was already filled by something else. On email it’s still open.
2026 is the year the bet shifted
For a long time you could dismiss email DANE as a European government hobby — the Dutch Standardization Forum putting it on a comply-or-explain list, a cluster of .nl and .de providers, and not much else at hyperscale. Google’s choice of MTA-STS over DANE looked like the market’s verdict.
That framing broke this year. Microsoft added inbound DANE validation to Exchange Online, and in early 2026 began rolling out configurable DANE and MTA-STS modes on outbound connectors — letting administrators set delivery to enforce DANE with DNSSEC, with a DNSSEC enablement wizard for the mail admin promised for later in the year. When the second-largest mailbox provider on earth ships DANE as a first-class, enforceable option, “nobody deployed it” stops being true. The market didn’t reach a verdict. It split, the way it usually does — Google on one side betting on the Web PKI it already dominates, the European public sector and now Microsoft on the other betting on signed DNS.
The lesson I take from DANE isn’t “good protocol, bad luck.” It’s that “is this standard dead?” is the wrong question, because it assumes a standard has one fate. DANE had at least three: genuinely dead on the web, mandatory in Dutch government mail, and newly alive in the largest enterprise mail platform going. Whether a protocol wins was never a property of the protocol. It was a property of who the clients are, what latency they’ll tolerate, and whether something else already solved their problem. Change those and you change the verdict — even though the RFC never moved a comma.