When your browser connects to a site over HTTPS, it trusts the server's certificate because some certificate authority signed it — and your device trusts that CA. The problem is the sheer number of CAs in the trust store. Any one of them, if compromised or coerced, can issue a perfectly valid certificate for a domain it has no business vouching for. History has receipts: the 2011 DigiNotar breach produced fraudulent certificates for Google and others, used to intercept traffic in Iran.
Certificate Transparency made misissuance detectable after the fact. DANE — DNS-Based Authentication of Named Entities, specified in RFC 6698 — takes a more direct route: it lets the domain owner state, in advance and authoritatively, which certificate or CA is allowed. If a certificate doesn't match what the domain published, it's rejected, no matter who signed it.
The TLSA Record
DANE works through a new DNS record type called TLSA. You publish it at a name that encodes the port and protocol of the service you're protecting. For a mail server accepting SMTP on port 25, that looks like:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash of the public key>
Those three numbers before the hash are the heart of it. They tell a connecting client exactly how to interpret the data:
| Field | Value | Meaning |
|---|---|---|
| Certificate Usage | 0 / 1 / 2 / 3 | 0–1 constrain a CA-issued cert; 2 trusts your own CA; 3 (DANE-EE) pins the exact server certificate, bypassing CAs entirely |
| Selector | 0 / 1 | Match the full certificate (0) or just its public key (1) |
| Matching Type | 0 / 1 / 2 | Exact data (0), SHA-256 hash (1), or SHA-512 hash (2) |
A 3 1 1 record — by far the most common in practice — means: "trust the certificate whose public key SHA-256 hash matches this value, and don't bother consulting any certificate authority." It's certificate pinning, but published in DNS where any client can fetch it, rather than baked into application code.
Why DNSSEC Is Non-Negotiable Here
There's an obvious objection: if DNS tells you which certificate to trust, what stops an attacker from spoofing the DNS response and pointing you at their certificate? This is exactly why DANE has a hard dependency on DNSSEC.
DNSSEC cryptographically signs DNS records, so a resolver can verify that a TLSA record genuinely came from the domain's authoritative servers and wasn't tampered with in transit. Without DNSSEC, DANE is worse than useless — it would let a network attacker substitute their own pin. DANE without DNSSEC is not DANE. The two are a package.
DANE doesn't eliminate trust — it relocates it. Instead of trusting hundreds of CAs equally, you trust the DNSSEC chain rooted at the DNS root zone. Whether that's an improvement depends on your view of who you'd rather rely on: the CA cartel, or the DNS hierarchy. For email server-to-server traffic, the DNS chain has proven to be a pragmatic win.
Where DANE Actually Succeeded: Email
Here's the honest part. DANE was proposed for HTTPS, and browsers rejected it. Chrome and Firefox declined to implement it, citing the slow pace of DNSSEC deployment, the added DNS lookups (and latency) per connection, and concerns about reliability. If you're hoping to protect your web browsing with DANE today, you can't — no mainstream browser checks TLSA records.
But email server-to-server transport is a different world, and there DANE found a real home through RFC 7672 (DANE for SMTP). The reason is a specific, long-standing weakness in how mail servers talk to each other.
The STARTTLS downgrade problem
When one mail server delivers to another, it normally uses opportunistic encryption via STARTTLS: the servers negotiate TLS if both support it, and fall back to plaintext if not. A network attacker can exploit that fallback by stripping the STARTTLS signal from the conversation, tricking both servers into sending mail in the clear — a silent downgrade with no warning to anyone.
A TLSA record fixes this. If a receiving mail server publishes a DANE record, a DANE-aware sender knows that TLS is mandatory and exactly which certificate to expect. There's nothing left to downgrade: no valid TLS, no delivery. Major providers and mail software — including widely used MTAs like Postfix — support DANE for SMTP, and it's seen meaningful adoption among security-conscious mail operators.
DANE vs. MTA-STS
DANE isn't the only answer to STARTTLS stripping. Google and Microsoft championed an alternative, MTA-STS, which achieves a similar goal without requiring DNSSEC — it publishes a policy over HTTPS instead. The two coexist:
- DANE requires DNSSEC, but offers stronger guarantees because the policy itself is cryptographically signed and can't be bypassed by a CA mistake.
- MTA-STS avoids the DNSSEC dependency, which lowers the deployment bar — but it leans on the CA system and a trust-on-first-use policy cache, so it's a softer protection.
Many well-run mail domains deploy both, covering senders that support either mechanism. They're complementary, not competing.
Should You Use It?
For an individual, DANE isn't something you configure — it's something your email provider and the providers you correspond with either support or don't. It's worth knowing about precisely so you can ask the right question when evaluating a privacy-focused email service: does it publish DANE records and validate them on outbound mail? That's a concrete, checkable signal of how seriously an operator takes transport security, well beyond the marketing claim of "encrypted email."
DANE's story is also a useful reminder that good cryptographic ideas don't always win where they were aimed. It lost the browser fight on deployment grounds, then found a quieter, genuinely valuable role hardening the email backbone — the part of the internet most users never see, but rely on every day. For the bigger picture on how email authentication fits together, see our overview of SPF, DKIM, and DMARC.