DANE for email in 2026
The browser version was abandoned a decade ago. The SMTP version is in production at scale, and the operational objections to it have mostly gone.
There are two protocols called DANE, and most writing about it treats them as one. The version meant to put TLS keys in DNS for browsers is gone: Chrome briefly supported a DNSSEC variant of it and then removed it, Firefox never shipped it, and Adam Langley wrote the obituary in 2015. The version for mail servers, DANE for SMTP in RFC 7672, is alive and carrying a serious share of mail in the places that adopted it. This article is about the second one: what it protects, who runs it, and what changed about running it.
Why the browser version was abandoned
The Chrome case is the cleanest to tell because the people involved wrote it down, and Langley's reasons still hold. DNS is unreliable at the edge: Chrome ran experiments looking up a TXT record it knew existed on connections it knew were working, and four to five percent of users could not retrieve it, most likely because something on their network blocked unusual DNS record types. A browser that fails hard on a missing lookup gets called broken; a browser that ignores the failure is not doing security.
The web also had a different plan. Certificate Transparency was the long-term bet for catching misissuance, and CT depends on certificates from a known set of trusted certificate authorities (CAs), the companies that issue certificates. A TLSA record is a DNS record holding a fingerprint of a server's certificate, and anyone can publish one, which is the point for a mail operator who wants to skip the CA and a problem for a transparency log that wants a manageable set of roots. On top of that, DNSSEC zones at the time were full of 1024-bit RSA keys the web PKI had spent a decade removing from its own trust stores. No browser was going to import that.
Why the mail version works
RFC 7672 was published in October 2015, the same year as the web obituary, and it solved a problem browsers did not have. SMTP between mail servers has always used opportunistic TLS: most servers try to encrypt, but a sender has no way to verify who it is talking to. STARTTLS is the step where two mail servers switch to an encrypted connection. An attacker on the path who strips STARTTLS from the server's EHLO response gets the mail in cleartext, and the CA system does not help, because the MX lookup that names the server is itself unauthenticated, and many MX hosts, the servers that accept mail for a domain, present self-signed certificates anyway.
DANE for SMTP closes that gap. The receiver publishes a TLSA record for each MX host, signs the zone with DNSSEC, and the sender validates the chain. The sender then has a cryptographic requirement: if the connection is downgraded to cleartext or a different certificate is presented, delivery fails closed: the mail waits instead of going out unencrypted.
It works where the browser case failed because the endpoints are servers, not user devices. Servers run validating resolvers that hotel Wi-Fi cannot interfere with, and mail has retry semantics, so a temporary DNSSEC failure is a deferral rather than an error page in front of a person.
What DANE protects, and what it does not
The scope is deliberately narrow. DANE stops STARTTLS stripping. It stops an attacker from using a certificate issued by a rogue or compromised CA. It lets self-signed certificates work, which is useful for internal mail routing.
It does nothing for mail at rest; once the message is in the mailbox, DANE's job is over. It does not authenticate the sender, which is what SPF, DKIM, and DMARC do. DANE protects the connection between two servers, and the authentication protocols protect the message inside it. A domain that handles anything sensitive wants both.
Who runs it
SMTP DANE is real, useful, and concentrated by region and by provider. In a September 2025 scan of the 10,000 domains Zivver's customers email most, 14% of domains supported DANE, and those domains received about 28% of the mail by volume. Large receivers do it; small ones mostly do not.
Microsoft turned on DANE for Exchange Online in two stages: outbound validation rolled out in the first half of 2022, and inbound went generally available in October 2024. Inbound is opt-in per domain. The admin signs the domain's own zone at its DNS host, runs Enable-DnssecForVerifiedDomain, points MX at the mx.microsoft host it returns, then runs Enable-SmtpDaneInbound. Microsoft publishes the TLSA records at its own hosts; the customer never publishes TLSA. Domains added to Microsoft 365 since July 2026 get an mx.microsoft MX from the start. Until someone does that, the domain's MX host has no TLSA records.
Google publishes no TLSA records for Google Workspace domains and points senders at MTA-STS, a web-published policy telling senders to require encryption, instead. The TLSA record lives at the MX host, which is why a Workspace customer cannot add one. MTA-STS fetches a transport policy over HTTPS and validates the receiver's certificate through the web PKI, where Certificate Transparency logs give an audit trail. The result is a provider lottery: a European receiver that publishes TLSA gives you DANE on the wire, a Microsoft 365 tenant can have it if an admin does the work, and a Google Workspace domain cannot have inbound DANE at all unless it sits behind a gateway whose inbound hosts publish TLSA records. Check the gateway's own MX hosts before assuming it does.
The operational objection, and what changed it
DANE couples your certificate to your DNS. The classic failure is the admin who renews the mail server certificate and forgets the TLSA record; because DANE fails closed, inbound mail stops. In a regulated environment that is the trade you agreed to. Everywhere else it was a standing source of anxiety, and a fair reason to stay away.
Two things changed that. DNSSEC stopped being hard, as the DNSSEC article covers: at the major DNS providers, signing the zone is a checkbox, so the foundation is no longer the obstacle. And certificate automation caught up. Tooling such as danectl, or a renewal hook on your ACME client, rotates the TLSA record alongside the certificate and turns the coupling into a scripted handoff. Publish a 3 1 1 record (DANE-EE, SPKI selector, SHA-256) and the hash survives renewals for as long as you keep the same key pair. Most ACME clients generate a new key at each renewal unless told to reuse it; certbot needs --reuse-key. The friction is not gone, but it is manageable by a normal operations team.
What to do with this
If you handle sensitive correspondence or regulated data, publish TLSA records for your MX hosts, and turn on DANE validation for the mail you send. Pair DANE with MTA-STS for senders that will not do DNSSEC, and pair both with TLS-RPT so sending servers tell you when they cannot deliver to you securely. If you last looked at the protocol before 2017, the picture has moved, and the objections you remember were about operations that have since been automated.