DANE Email Authentication: How DNS-Based TLS Pinning Stops STARTTLS Stripping (and Why 0.0% of Domains Use It)

Of 5,499,028 domains we scanned in February 2026, exactly 30 publish a TLSA record for SMTP. That’s 0.0% adoption — the rarest email-authentication protocol in production today, by an order of magnitude (DMARCguard scan, Feb 2026; see our 2026 email authentication adoption study for methodology). DANE email authentication (DNS-Based Authentication of Named Entities, RFC 7672) is supposed to fix STARTTLS stripping — the attack class where on-path middleboxes silently downgrade encrypted SMTP to plaintext — yet the deployment numbers say almost nobody uses it.

The attack itself is real and well-documented. Durumeric and colleagues observed 41,405 SMTP servers across 193 countries corrupting STARTTLS in 2015, and the worst-affected ISPs forced 96% of inbound mail from Tunisia to Gmail to cleartext for over a year (IMC 2015, doi.org/10.1145/2815675.2815695). A decade later, the most directly comparable independent measurement — TU Dresden’s 4-million-domain Tranco scan (Tehrani et al., TMA 2024) — corroborates our 0.0% finding: they measured 0.1% TLSA presence, with DNSSEC adoption itself sitting at roughly 5% of the same dataset.

This post explains what DANE actually is, why its adoption is a rounding error, exactly how it stops the STARTTLS-stripping attack class, and how to decide whether you should deploy it on your domain — or pick MTA-STS instead. The TLSA mechanics are covered exhaustively in our comprehensive DANE protocol guide; this post is the strategy layer.

What Is DANE? (DNS-Based Authentication of Named Entities)

DANE is an IETF protocol that binds a TLS certificate (or its public-key hash) to a DNS hostname using a DNSSEC-signed TLSA record. For email, the DANE-for-SMTP profile in RFC 7672 lets a sending mail server verify the receiver’s certificate before delivering — without depending on the public Web PKI and its hundreds of trusted certificate authorities.

Two RFCs do the heavy lifting. RFC 6698 defines the TLSA record format itself — the DNS data type and the four numeric fields it carries. RFC 7672 specifies how SMTP MTAs use those records to authenticate STARTTLS: when to look up TLSA, what to do on a match, and what to do on a mismatch. Together, they define a working DANE protocol stack for mail-server-to-mail-server traffic on port 25.

The model is certificate pinning via DNS. The receiving domain publishes the fingerprint of its server certificate (or the certificate of a private CA that signed it) as a TLSA record. A DANE-aware sender does that DNS lookup before STARTTLS, then refuses to deliver in plaintext if the served certificate doesn’t match. RFC 7672 §1.3.1 frames the motivation bluntly: “The server’s indication of TLS support can be easily suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can be subverted by simply downgrading a connection to cleartext. No TLS security feature, such as the use of PKIX, can prevent this. The attacker can simply disable TLS.” DANE closes that gap by making TLS support a DNSSEC-signed mandate rather than a hint inside the SMTP greeting.

The 0.0% Problem — Why Almost Nobody Runs DANE

The adoption gap is not subtle. Three independent measurements all point in the same direction.

• DMARCguard scan, Feb 2026: 30 of 5,499,028 Tranco-derived domains publish a valid TLSA record for SMTP — 0.0005%.
• TU Dresden, TMA 2024: 0.1% TLSA presence on a ~4-million-domain Tranco subset, with DNSSEC adoption at roughly 5% of the same set (Tehrani et al., arXiv 2407.02287, early-2024 scan).
• Viktor Dukhovni’s continuous SMTP DANE survey counts roughly 3.95 million DANE-enabled mail domains globally, but the absolute count is concentrated in .nl, .se, and .cz plus a small number of bulk-enabling hosters such as One.com, TransIP, and Argeweb.

Four structural blockers explain almost all of the gap, and none of them are about the protocol itself.

1. DNSSEC is the prerequisite. No DNSSEC, no DANE — and DNSSEC adoption itself sits at roughly 5–7% of authoritative zones globally. SIDN’s editorial “None of the biggest internet services are DNSSEC-enabled” (28 Jan 2025) frames the structural problem precisely.
2. DNS-host gaps. GoDaddy DNS, Namecheap Free DNS, Vercel managed DNS, Netlify DNS, and Hurricane Electric (dns.he.net) cannot publish TLSA records at all — the record type is simply missing from their UI and API. Hetzner DNS Console does expose TLSA, but the platform refuses to sign zones; records publish but are cryptographically inert and produce silent DANE failures.
3. Registrar gaps. Only Cloudflare Registrar publicly automates the DS handoff via RFC 7344 / RFC 8078 CDS/CDNSKEY scanning. Every other deployer copies DS digests between two web UIs at every key rollover. Lee et al. (USENIX Security 2022) measured 30% of DNSSEC-signed .com/.org/.net domains with missing DS records at the registrar — the registrar handoff is where deployments die.
4. Big-mailbox holdouts. Gmail and Google Workspace publish no TLSA records (they enforce MTA-STS only). Fastmail explicitly does not support DNSSEC. Yahoo, Apple iCloud, Zoho, and mxroute all show no public TLSA presence. Only Microsoft 365 (with inbound SMTP DANE GA on 28 Oct 2024), Proton Mail, Posteo, and Mailbox.org commit to DANE for major mailbox volume.

DANE email security only delivers value when both ends of the pipe agree to use it — and outside the Dutch and German ecosystems, almost nobody does.

Source: provider documentation, accessed 2026-04-28.

How DANE Stops STARTTLS Stripping

The attack pattern DANE for SMTP defeats is straightforward. Without DANE, a sending MTA opens an SMTP connection on port 25, parses the EHLO response for a STARTTLS capability, and falls back to plaintext if it doesn’t see one. An on-path middlebox that quietly rewrites the STARTTLS advertisement to a same-length garbage token like XXXXXXX causes the legitimate sender to negotiate cleartext with no warning. The message ships in the open.

With DANE deployed, the lookup happens before the SMTP transaction. A DNSSEC-validated TLSA record is a binding mandate to use TLS — suppressing the STARTTLS capability from EHLO no longer works because the sender already has signed proof that the receiver supports TLS. The downgrade attempt converts into a hard delivery deferral: the message stays in the queue until the network path stops tampering, rather than leaking in plaintext.

Three documented incidents anchor the threat:

• Cricket / AIO Wireless, 2013–Oct 2014: AT&T-owned US prepaid carrier rewrote STARTTLS advertisements on port 25 (classic Cisco PIX/ASA inspect esmtp “fixup”). Discovered by Golden Frog engineers and filed with the FCC’s 14-28 Open Internet Proceeding (EFF coverage).
• Durumeric et al., IMC 2015: 41,405 SMTP servers across 4,714 ASes and 193 countries corrupting STARTTLS; seven countries had >20% of inbound Gmail forced to cleartext; Tunisia peaked at 96%.
• Thai ISPs, September 2014: a transparent proxy in front of smtp.gmail.com:25 captured AUTH credentials by suppressing TLS on the EHLO response.

DANE would have blocked the second pattern outright — the canonical case RFC 7672 was designed to defeat. The first and third are partly out of scope: both involved user submission, and DANE for SMTP covers only MTA-to-MTA on port 25. The fix for user submission is implicit TLS on 465 or 587 with strict certificate validation.

Honesty about scope matters. DANE is not a universal STARTTLS-stripping cure. USENIX Security 2021’s “Why TLS is better without STARTTLS” (Poddebniak et al.) showed that in-band buffering injection bugs survive DANE entirely — the attacker’s plaintext is pre-loaded before the TLS handshake and consumed inside the validated session. CVE-2021-38371 (Exim) and CVE-2011-0411 (Postfix) are textbook examples. DANE binds the certificate; it cannot police what the receiver buffered before the cipher started.

Why DANE Requires DNSSEC (and What That Costs)

The DANE DNSSEC dependency is not an implementation accident. It is the cryptographic foundation that makes the protocol meaningful.

The argument is simple. Without DNSSEC, an attacker who can spoof DNS responses can also spoof your TLSA record — forging a valid pin for a certificate they themselves control. The TLSA pin is then worse than no pin at all, because the sender will trust it. Conforming MTAs are required by RFC 7672 §2 to ignore unsigned TLSA responses for exactly this reason. No DNSSEC, no DANE, no exceptions.

Every link in the deployment chain has to hold:

1. Authoritative DNS host signs your zone. Most major hosts (Cloudflare, Route 53, Google Cloud DNS, Azure DNS, deSEC, Bunny) automate this; some (Hetzner, Vercel, Netlify, Hurricane Electric) cannot.
2. Registrar publishes the matching DS record at the parent TLD. This is where most deployments break. Lee et al. (USENIX 2022) measured the failure rate at 30% of DNSSEC-signed second-level domains in .com/.org/.net.
3. Mail server presents a certificate that matches the TLSA hash. Whatever you pinned has to be served on port 25, exactly.
4. Key rollovers re-publish the DS record at the parent. Manual unless you’re on Cloudflare Registrar with CDS/CDNSKEY automation.

The economic counter-argument deserves a fair hearing. Geoff Huston (APNIC Chief Scientist) wrote in May 2024: “DNSSEC as we know it today is just not going anywhere. It’s too complex, too fragile and just too slow to use for the majority of services and their users.” That explains the 0.0% number more honestly than any single technical objection. The ecosystem hasn’t decided DANE is wrong; it has decided DNSSEC is too costly to operate at scale outside ccTLDs with active registrar incentives. The Dutch model — SIDN financial incentives plus Forum Standaardisatie comply-or-explain — is the only one producing material adoption growth.

The TLSA Record, Field by Field

A working TLSA record looks like this:

_25._tcp.mail.example.com.   IN   TLSA   3 1 1   abc123def456789...<SHA-256 hex>

Five components carry all the meaning. The owner name encodes the protocol and port the record applies to. The three numeric fields select which artifact is being pinned and how. The hex string is the actual hash.

The operator decision condenses to two patterns: DANE-EE (3 1 1) for self-managed certs and DANE-TA (2 1 1) for fleets behind a private CA. RFC 7672 §3.1.3 explicitly allows self-signed certificates under usage 3 — that is the CA-bypass selling point of DANE authentication. You don’t need a Let’s Encrypt cert or a paid commercial cert to authenticate to a DANE-EE-pinning peer; the DNSSEC-signed hash is the trust anchor.

The mechanics — every usage value, every interaction between selector and matching type, every per-MX RRset rule — are covered exhaustively in our comprehensive DANE protocol guide. This post is the strategy layer; that page is the reference layer.

DANE vs MTA-STS — How to Pick

The DANE vs MTA-STS question reduces to one trade-off: DANE is cryptographically stronger; MTA-STS is operationally easier. The right answer depends on which barrier you can clear today.

DANE currently outpaces MTA-STS on sender-side validation rate (Ashiq, Fiebig, Chung — IMC 2025) — a counter-intuitive result given DANE’s lower publisher adoption, but consistent with the DANE-publishing population skewing toward operationally serious mail providers. BSI TR-03108 v2.0 puts the regulator’s view plainly: “MTA-STS does not provide more robust identification of the [server].” It is a fallback, not an equal.

The decision rule reads cleanly:

• If you already control DNSSEC and a TLSA-aware DNS host (Cloudflare, Route 53, Google Cloud, Azure DNS, deSEC, Bunny, OVH, NS1, DNSimple), deploy both.
• If your domain lives on GoDaddy, Namecheap Free, Vercel, Netlify, Hurricane Electric, or Hetzner DNS Console, deploy MTA-STS only and migrate DNS provider before adding DANE.
• If you fall under DE-regulated ESP rules, NL Forum Standaardisatie scope, or NIS2 essential-entity duty-of-care, DANE is the policy expectation and MTA-STS is the documented fallback.

TLS-RPT is the reporting layer that catches failures in either protocol — see our TLS-RPT setup walkthrough. The policy layer that pairs with DANE-EE is MTA-STS — see our MTA-STS configuration guide. Together with the MTA-STS learn page and TLS-RPT learn page, they form the stack most deployers aim at: DANE for cryptographic enforcement, MTA-STS as the fallback, TLS-RPT as the visibility layer.

Is DANE Required for NIS2 Compliance?

The honest legal answer is no — no EU instrument names DANE literally. The functional answer is that ENISA’s Technical Implementation Guidance v1.2 (September 2025) maps Commission Implementing Regulation (EU) 2024/2690 §6.7.2(k) — “modern e-mail communications standards” — to the DANE / DNSSEC / MTA-STS family. Article 2(2) imposes comply-or-explain logic: a relevant entity that decides DANE is “not appropriate, not applicable or not feasible” must “in a comprehensible manner document its reasoning.”

Member-state policy is more explicit:

The enforcement teeth exist on paper. Directive (EU) 2022/2555 Article 34(4) caps administrative fines at “EUR 10 000 000 or … 2% of the total worldwide annual turnover, whichever is higher” for essential entities that infringe Article 21. The Commission sent reasoned opinions to 19 Member States on 7 May 2025 for transposition delays. Through 28 April 2026, no national supervisory authority has published a named NIS2 fine — teeth on paper, not yet bared.

If your domain falls under NIS2 Annex I or II, document a DANE deployment plan against §6.7.2(k) — or document, comprehensibly, why MTA-STS is your alternative. The latter is allowed; the former is the policy expectation in the Netherlands and Germany.

How to Deploy (or Validate) DANE on Your Domain

Five steps cover the working deployment. Each one fails closed: skip a step, and you either get nothing (silent failure) or a hard delivery deferral.

1. Confirm DNSSEC is signing your zone. Run dig +dnssec mail.example.com TLSA and look for an RRSIG. If it isn’t there, enable DNSSEC at your DNS host and publish the matching DS record at your registrar before doing anything else. Unsigned TLSA records have zero security value and may produce silent failures on Hetzner DNS Console.

# Confirm the TLSA RRset is DNSSEC-authenticated
dig +dnssec _25._tcp.mail.example.com TLSA

# Look for an RRSIG line in the answer section.
# No RRSIG → conforming MTAs ignore the record per RFC 7672 §2.

# Publish a TLS-RPT record so DANE-validating senders can email
# JSON failure reports describing exactly which TLSA didn't match.
_smtp._tls.example.com.   IN   TXT   "v=TLSRPTv1; rua=mailto:[email protected]"

2. Generate a TLSA record from your MX host’s certificate. On the mail server, derive the SHA-256 of the SubjectPublicKeyInfo with openssl. The output is the hex hash for a usage 3 1 1 (DANE-EE) record.

# From the MX host, derive the SHA-256 of SubjectPublicKeyInfo
openssl x509 -pubkey -noout -in mail.crt \
  | openssl pkey -pubin -outform DER \
  | sha256sum

# Then publish the TLSA RRset, one per MX hostname
# _25._tcp.mx1.example.com.   IN   TLSA   3 1 1   <hex>
# _25._tcp.mx2.example.com.   IN   TLSA   3 1 1   <hex>

3. Publish at _25._tcp.<mx-host>. One TLSA RRset per MX hostname, not per organizational domain. If example.com has mx1.example.com and mx2.example.com as MX hosts, you need two TLSA RRsets — one at _25._tcp.mx1.example.com and one at _25._tcp.mx2.example.com.
4. Validate end-to-end. Use DMARCguard’s DANE checker for the live DNSSEC walk and TLSA match, or our DANE record generator if you’d rather generate from a PEM file first and verify after. The checker also flags the most common silent-failure modes: unsigned TLSA, missing DS at the parent, MX hostname mismatch, and wrong owner-name port.
5. Monitor with TLS-RPT. Publish _smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:[email protected]" so DANE-validating senders can email JSON failure reports describing exactly which TLSA record didn’t match. Without TLS-RPT, a botched key rollover is invisible until your inbound queue fills up. The reporting layer is the TLS-RPT setup walkthrough.

Key rollover deserves its own note. Every time you rotate the certificate (or its key, if you pinned the SubjectPublicKeyInfo), you must republish the TLSA record before the old certificate expires — and re-publish the DS at your registrar after every DNSSEC key rollover. If your registrar isn’t Cloudflare Registrar, plan a manual DS publish window and verify the parent zone shows the new DS digest before the rollover.

We built our own DANE scanner against the Tranco 5.5M list — that is how we know the answer is 30. The same scanner powers the DANE checker tool you can run against your own domain right now.

Frequently Asked Questions

What is DANE in email?

DANE in email is DNS-Based Authentication of Named Entities for SMTP, defined in RFC 7672. A receiving domain publishes a DNSSEC-signed TLSA record at _25._tcp.<mx-host>, and a DANE-aware sending mail server uses that record to verify the receiver’s TLS certificate before delivering. If the certificate doesn’t match, the sender refuses to deliver in plaintext — closing the STARTTLS-stripping attack class.

Does DANE require DNSSEC?

Yes. RFC 7672 §2 requires conforming MTAs to ignore TLSA records that aren’t authenticated by DNSSEC, because an attacker who can forge DNS can also forge an unsigned TLSA. You must DNSSEC-sign your zone and publish a matching DS record at your registrar before DANE provides any security benefit. No DNSSEC means no DANE — there is no workaround.

What is the difference between DANE and MTA-STS?

DANE pins TLS certificates in DNS via DNSSEC; MTA-STS publishes a policy over HTTPS plus a versioning TXT record. DANE is cryptographically stronger and supports self-signed certs (DANE-EE, usage 3), but requires DNSSEC and TLSA-capable DNS hosting. MTA-STS works on any DNS host with HTTPS but inherits Web PKI risk. Most operators deploy MTA-STS first and add DANE when the DNSSEC stack is ready.

How do I check or generate a TLSA record?

Use DMARCguard’s DANE checker for live validation — it does the DNSSEC walk and TLSA match for you — or our DANE record generator to compute the 3 1 1 <hash> from a PEM certificate. On the command line: openssl x509 -pubkey -noout -in cert.pem | openssl pkey -pubin -outform DER | sha256sum.

Is DANE called something different in English?

Yes — DANE stands for DNS-Based Authentication of Named Entities and refers to the IETF protocol defined by RFC 6698 (TLSA) and RFC 7672 (SMTP). The dictionary word “Dane” (a person from Denmark) is unrelated. This post covers the protocol; if you wanted the demonym, you wanted Merriam-Webster, not DMARCguard.

Why is DANE adoption near zero?

DANE adoption sits at 0.0% (30 of 5.5M domains in our Feb 2026 scan) because it requires three independent things to work: a DNSSEC-signed zone, a DNS host that exposes TLSA records, and a registrar that publishes DS records (ideally via CDS/CDNSKEY automation). GoDaddy, Namecheap Free, Vercel, Netlify, and Hetzner Console all break the chain at one step or another. Big mailbox providers (Gmail, Yahoo, iCloud) also don’t publish TLSA, so most senders see no upside.

Where to Go from Here

DANE email authentication is the strongest available defense against STARTTLS stripping, but it lives or dies on DNSSEC. The 0.0% adoption number is a measurement of the DNSSEC ecosystem, the registrar market, and the big-mailbox holdouts — not of the protocol’s design.

The decision is simpler than the numbers suggest:

• On Cloudflare, Route 53, Google Cloud, Azure DNS, deSEC, or Bunny with a Cloudflare-Registrar-style flow, deploy DANE and pair it with TLS-RPT for visibility.
• On GoDaddy, Namecheap Free, Vercel, Netlify, Hurricane Electric, or Hetzner DNS Console, start with MTA-STS, fix DNS hosting later, then add DANE.
• Under NIS2, Forum Standaardisatie, or BSI TR-03108, DANE is the policy expectation and MTA-STS is the documented fallback.

DANE-EE (3 1 1) lets you skip the public CA entirely — the DNSSEC-signed hash is the trust anchor. No Let’s Encrypt rotation, no commercial CA, no Web PKI dependency.

DANE email authentication is the rarest standard in the email-authentication stack. Make it less rare for your domain — or make a defensible MTA-STS plan instead.

Continue with our TLS-RPT setup walkthrough and MTA-STS configuration guide for the rest of the TLS-trifecta.