DANE — DNS-Based Authentication of Named Entities

Every other email transport protocol — STARTTLS, MTA-STS — has a foundational weakness: trust in the network at the moment of first contact. STARTTLS announces TLS support in cleartext (a downgrade attacker can strip the announcement). MTA-STS fetches its policy over HTTPS the first time it sees a domain (trust-on-first-use, acknowledged in RFC 8461). DANE breaks that pattern by anchoring trust in the DNSSEC root keys, propagated through the DNS delegation chain — there is no first contact to attack, because the cryptographic chain extends to the global root.

The cost of that stronger guarantee is operational. DANE requires DNSSEC on every link in the chain (your domain, the MX hostname's zone, the registrar). It requires careful certificate-rotation timing or inbound mail bounces. And until October 2024, the only major commercial receiver that consumed TLSA records for SMTP was Postfix-based open-source mail — meaning the deployment effort produced limited real-world coverage. Microsoft's October 2024 GA of Inbound SMTP DANE changed that calculus, and the planned July 2026 migration of all newly-created Accepted Domains to DNSSEC-enabled *.mx.microsoft infrastructure represents the largest single forcing function for DANE deployment to date.

The problem DANE solves

SMTP's encryption story has three layers, each fixing the previous layer's weakness while introducing a new one:

Layer 1 — Plaintext (1982-2002). SMTP as defined in RFC 821 had no encryption. Mail transited in cleartext between every server hop. Anyone with access to the network path could read or modify messages.

Layer 2 — STARTTLS (RFC 3207, 2002). Added an opportunistic TLS upgrade: the receiving server announces 250-STARTTLS in its EHLO response, the sender issues STARTTLS, both negotiate TLS, and the rest of the conversation is encrypted. This solved passive eavesdropping but introduced two new problems. First, an active attacker on the path can strip the STARTTLS announcement from the EHLO response, causing the sender to fall back to cleartext — the sender doesn't know it should have been encrypted. Second, even when TLS is negotiated, sending MTAs historically did not validate the certificate, accepting any cert (self-signed, expired, attacker-presented) because requiring CA validation would block delivery to the long tail of self-hosted mail servers.

Layer 3 — DANE (RFC 7672, 2015) and MTA-STS (RFC 8461, 2018). Both close the downgrade-attack hole, but with different trust models. DANE publishes the certificate fingerprint in DNSSEC-signed DNS, making both "TLS required" and "specific cert required" cryptographically enforceable. MTA-STS publishes a policy over HTTPS that says "use TLS, validate against CAs, here are valid MX hostnames" — easier to deploy but with TOFU vulnerability. The two were designed to coexist; RFC 7672 §1.5 explicitly confirms they do not interfere.

How DANE works for SMTP

The DANE handshake adds three steps to the standard SMTP delivery chain. Here's what happens when a DANE-aware sender (Postfix with smtp_tls_security_level=dane, or Microsoft Exchange Online outbound) attempts to deliver mail to a DANE-enabled receiver:

If validation fails at any step, the sending MTA aborts the connection. There is no fallback to plaintext or to a less-secure validation mode — that would defeat DANE's entire purpose, since a downgrade attacker could simulate failure. The message is either tried at the next MX (if the destination has multiple MX records) or deferred for retry. After enough failed retries, the sender bounces the message back to the original sender with a TLS-related delivery failure notice.

TLSA record anatomy: 4 fields decoded

A TLSA record has exactly 4 fields, encoded as 1 byte + 1 byte + 1 byte + variable-length data. Each field has multiple valid values, and the choice of values determines what the receiver pins, how strictly, and whether the record is even useful for SMTP.

Field 1: Certificate Usage (1 byte)

Specifies what type of certificate the TLSA record represents and whether PKIX (CA-based) validation is also required. Of the 4 defined values, only 2 are recommended for SMTP per RFC 7672 §3.1.3:

Microsoft Exchange Online treats Usage values 0 and 1 as "not usable" per their documentation — when a TLSA record with Usage 0 or 1 is returned, Exchange Online doesn't perform DANE validation steps for that record. This aligns with RFC 7672 guidance that PKIX-anchored variants add complexity without security benefit for SMTP, where the use case is server-to-server (not browser-to-server) trust.

Field 2: Selector (1 byte)

Specifies what part of the certificate the TLSA hash represents:

Selector 1 (SPKI) is the operational sweet spot. The trade-off is that you're committing to long-term key reuse — if your private key is ever compromised, you must rotate the key (which means rotating the TLSA hash, which means the rotation timing problem detailed below). For most production SMTP infrastructure, key reuse for 1-2 years is acceptable; the ease of cert renewal under SPKI more than compensates.

Field 3: Matching Type (1 byte)

Field 4: Certificate Association Data

The actual fingerprint — a hex string whose length depends on the Matching Type. For the canonical SMTP combination (Selector 1, Matching Type 1), this is the SHA-256 of the SPKI, exactly 64 hex characters (32 bytes). Generation example:

# Extract SPKI hash from a PEM certificate (the canonical 3 1 1 value)
openssl x509 -in mx1.example.com.crt -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -u -c 64

The canonical SMTP TLSA record: 3 1 1

For SMTP, the recommended TLSA configuration is DANE-EE + SPKI + SHA-256, written as 3 1 1:

; In mx1.example.com's zone file:
_25._tcp.mx1.example.com. IN TLSA 3 1 1 5b8ee71c01e0c97...
;                              │ │ │
;                              │ │ └─ Matching Type: SHA-256
;                              │ └─── Selector: SPKI (public key)
;                              └───── Usage: DANE-EE (end-entity, no PKIX)

This combination produces three properties that align well with SMTP's operational realities:

1. No domain-name validation. The receiving SMTP server can accept mail for thousands of domains without needing a cert with all of them in SAN. Critical for shared MX infrastructure.
2. No expiry validation. If a cert expires by mistake or renewal is delayed, mail keeps flowing as long as the TLSA fingerprint still matches. The TLSA record itself becomes the validity oracle.
3. Stable across renewals (when key is reused). SPKI selector means renewing the cert with the same private key produces an identical TLSA hash — no DNS changes needed at renewal time.

Microsoft Exchange Online DANE: GA October 2024 + 2026 roadmap

Microsoft is the single most consequential commercial receiver for DANE deployment. Their published roadmap from Microsoft Learn — How SMTP DANE works and Microsoft Tech Community announcements:

Adoption reality 2026: the numbers

DANE adoption remains negligible globally despite a decade of standardization. DMARCguard's February 2026 scan of 5.5 million domains from the Tranco Top Sites List found exactly 30 domains publishing TLSA records for SMTP — under 0.001% adoption. The headline numbers:

The geographic distribution of DANE deployment correlates almost perfectly with national DNSSEC adoption. The Netherlands (where DANE is on the government's "comply or explain" list and the .NL TLD has aggressive DNSSEC promotion), Sweden, Norway, and the Czech Republic account for a disproportionate share of TLSA-publishing domains. Government, research, and CSIRT-affiliated networks are dramatically over-represented compared to commercial deployment.

DANE vs MTA-STS: dimensional comparison

Both protect against TLS downgrade attacks on SMTP, but with different trade-offs along every dimension. The choice isn't "which one" — for organizations that can deploy both, deploying both maximizes coverage. The decision matrix:

Certificate rotation without breaking inbound mail

The single highest-risk DANE operation is certificate rotation. Get the timing wrong and inbound mail bounces with TLS validation failures until sending MTAs' DNS caches expire. The required pattern is publish before deploy, deploy before retire:

If you skip the staging phase and atomically swap cert and TLSA, the failure mode is: sending MTAs with a cached old TLSA see the new cert, compute its hash, find no match, and abort the connection. Inbound mail bounces from those senders for as long as their DNS caches retain the old TLSA — typically 1-24 hours depending on the TLSA TTL you set. Selector 1 (SPKI) materially reduces this risk: if your cert renewal reuses the same private key (Let's Encrypt's --reuse-key flag enables this), the SPKI hash is unchanged across renewals, and the TLSA record stays valid through the cert change with zero DNS modification.

Common DANE failure modes (from TLS-RPT data)

Production DANE failures fall into a small number of recurring patterns, each with a specific diagnosis. The TLS-RPT result-types that signal DANE issues are tlsa-invalid, dnssec-invalid, dane-required, certificate-host-mismatch, and certificate-expired:

DANE's bootstrap problem (and DNSSEC NSEC3 mitigation)

A subtle attack vector against DANE: if an attacker can block the DNS query for the TLSA record (rather than forge a response), the sender doesn't learn that DANE is in scope and falls back to opportunistic TLS — which the attacker can downgrade. This is called the "bootstrap problem" and applies to MTA-STS too (block the policy fetch and the sender doesn't know to enforce STARTTLS).

The mitigation for DANE is DNSSEC's NSEC/NSEC3 mechanism for authenticated denial of existence. When a DNSSEC-signed zone is queried for a non-existent record, the response includes cryptographic proof that the record genuinely doesn't exist (NSEC3 record). The sender can distinguish "TLSA record doesn't exist (so DANE not required)" from "TLSA query was blocked (so I can't tell whether DANE was required)" — in the latter case, a DANE-aware sender treats this as suspicious and may refuse delivery rather than falling back. In practice, blocking-attacks are far harder to execute than spoofing attacks, since the attacker must maintain persistent network presence rather than briefly inject a forged response.

DANE in Cloud Server for Email infrastructure

Customer-specific implementation details matter for DANE deployment on managed infrastructure. Cloud Server for Email's standard managed deployment includes:

• DNSSEC-signed delegation on customer-controlled domains where supported by the registrar. We handle DS record submission and rotation. Customers using Route 53, Cloudflare, or DigitalOcean DNS get DNSSEC essentially for free; customers on legacy registrars may require DNS migration.
• TLSA records published with the canonical 3 1 1 combination (DANE-EE + SPKI + SHA-256) at _25._tcp.[mx-host] for every MX hostname.
• Dual-TLSA staging during cert rotation. Our deployment automation publishes the new TLSA at T0, deploys the new cert at T0+2×TTL, and removes the old TLSA at T0+4×TTL. TTL set to 3600s (1 hour) keeps the staging window manageable.
• SPKI selector + Let's Encrypt --reuse-key as the default. Cert renewal happens silently every 60 days without touching DNS. Key rotation (when needed) follows the staged TLSA pattern.
• TLS-RPT integration. Every customer DANE deployment gets a parallel TLS-RPT record so we can monitor real-world validation results from sending MTAs. The combination of DANE + TLS-RPT gives operators the visibility they need to deploy with confidence.

For customers running their own MTAs (PowerMTA, Postfix, MailWizz with custom outbound), we provide DANE consultation but do not manage the DNS layer directly — DANE deployment requires DNSSEC ownership of both the email domain and the MX hostname zone, which often spans the customer's registrar, DNS provider, and infrastructure providers.

Auditing your DANE configuration

Standard verification commands for an existing DANE deployment:

# 1. Verify DNSSEC chain on your email domain and MX
delv +rtrace example.com SOA
delv +rtrace mx1.example.com A

# 2. Verify TLSA record exists and is DNSSEC-validated
delv +rtrace _25._tcp.mx1.example.com TLSA

# 3. Verify the cert presented by your MX matches the TLSA hash
echo | openssl s_client -starttls smtp -connect mx1.example.com:25 \
  -showcerts 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -hex \
  | awk '{print $2}'
# Compare output hash with the value in the TLSA record

# 4. Online validators
#    - https://www.mailhardener.com/tools/dane-validator
#    - https://internet.nl (full email security audit including DANE)
#    - https://dane.sys4.de

Microsoft's Remote Connectivity Analyzer performs the same DNSSEC and DANE checks against your DNS configuration that Exchange Online does when sending email outside the service — useful for diagnosing why Microsoft 365 might be failing to deliver to your domain.

Related concepts in this glossary

• MTA-STS — the CA-trusted alternative to DANE; complements DANE rather than replaces it.
• TLS-RPT — the daily reporting mechanism that surfaces DANE failures from sending MTAs. Essential companion to DANE.
• SPF — sender authentication via authorized IP list. Different layer (sender identity, not transport security).
• DKIM — message-level cryptographic signature. Different layer (message integrity, not transport).
• DMARC — alignment policy across SPF/DKIM. Different layer (sender reputation policy).

Frequently asked questions

Last updated: May 2026 · Sources: RFC 7672, RFC 6698, RFC 7671, Microsoft Learn — How SMTP DANE works, DMARCguard 2026 scan, Mailhardener DANE knowledge base.