DANE: DNS-based Authentication of Named Entities

What it does

DANE is the answer to 'I don't fully trust the public CA system.' Instead of asking 'is this cert signed by a CA my system trusts,' a receiver asks 'is this cert's hash the one the domain published in DNS?' That removes the CA from the trust chain entirely.

DANE only provides real protection when DNSSEC is in place. Without DNSSEC, an attacker who can spoof DNS can spoof the TLSA record too, and you've gained nothing.

For SMTP, DANE is published at _25._tcp.<mx-host> with TLSA records listing (usage, selector, matching-type, certificate-association-data). The standard profile for SMTP is 3 1 1: DANE-EE (skip CA validation), SPKI (hash the public key, not the cert), SHA-256.

How it works

1. Enable DNSSEC on your domain and confirm it validates from public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9 with the AD bit set).
2. Compute the SHA-256 of your MX server's SubjectPublicKeyInfo (SPKI).
3. Publish a TLSA record at _25._tcp.<mx-host> with value '3 1 1 <hash>'.
4. Sending servers that support DANE-SMTP (Postfix with smtp_tls_security_level=dane) will refuse to deliver mail to your MX unless the cert hash matches.

Example record

_25._tcp.mail.yourdomain.com TLSA

Common pitfalls

• Publishing TLSA without DNSSEC. Provides zero security — attackers spoofing DNS can spoof the TLSA record too.
• Using usage 0 or 1 (PKIX-TA / PKIX-EE). These still rely on CA validation; defeats the point of DANE for most deployments.
• Forgetting to update the TLSA record when you renew or rotate the cert. Inbound mail starts bouncing within minutes for senders that enforce DANE.
• Pinning the full cert (selector 0) instead of the SPKI (selector 1). Cert renewals break the record; SPKI lets you re-issue with the same key without changing TLSA.

Related tools