DANE
What is DANE?
DANEA protocol family defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS server certificates or public keys to a service, removing reliance on the public CA system.
DNS-Based Authentication of Named Entities (DANE), specified in RFC 6698 and refined for SMTP in RFC 7672, publishes TLSA records that name a service (for example _25._tcp.mail.example.com) and identify the legitimate certificate or public key. DNSSEC integrity ensures these records cannot be tampered with on the wire. For SMTP, DANE forces sending MTAs to enforce TLS to MX hosts whose TLSA records validate, defeating downgrade and rogue-certificate attacks. DANE also supports HTTPS and other protocols, but adoption is greatest in email. It complements MTA-STS by providing a stronger, DNSSEC-anchored guarantee; many operators deploy both. Effective DANE requires correctly maintained DNSSEC zones and TLSA record updates during certificate rotation.
● Examples
- 01
Publishing a TLSA record so partner MTAs refuse to deliver mail to mail.example.com without the expected certificate.
- 02
Pinning a public key via TLSA 3 1 1 to allow seamless certificate rotation by the same key pair.
● Frequently asked questions
What is DANE?
A protocol family defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS server certificates or public keys to a service, removing reliance on the public CA system. It belongs to the Network Security category of cybersecurity.
What does DANE mean?
A protocol family defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS server certificates or public keys to a service, removing reliance on the public CA system.
How does DANE work?
DNS-Based Authentication of Named Entities (DANE), specified in RFC 6698 and refined for SMTP in RFC 7672, publishes TLSA records that name a service (for example _25._tcp.mail.example.com) and identify the legitimate certificate or public key. DNSSEC integrity ensures these records cannot be tampered with on the wire. For SMTP, DANE forces sending MTAs to enforce TLS to MX hosts whose TLSA records validate, defeating downgrade and rogue-certificate attacks. DANE also supports HTTPS and other protocols, but adoption is greatest in email. It complements MTA-STS by providing a stronger, DNSSEC-anchored guarantee; many operators deploy both. Effective DANE requires correctly maintained DNSSEC zones and TLSA record updates during certificate rotation.
How do you defend against DANE?
Defences for DANE typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for DANE?
Common alternative names include: DNS-Based Authentication of Named Entities.
● Related terms
- network-security№ 707
MTA-STS
An email security mechanism defined in RFC 8461 that lets a domain require TLS for inbound SMTP and pin a list of trusted MX hostnames, defeating downgrade and STARTTLS-stripping attacks.
- network-security№ 1098
STARTTLS
An SMTP, IMAP, POP3, and XMPP extension defined in RFC 3207 that upgrades a plaintext connection to TLS after the protocol greeting, enabling opportunistic encryption between mail servers and clients.
- network-security№ 764
Opportunistic TLS
An encryption posture in which two parties use TLS when both support it and fall back to plaintext otherwise, typical of SMTP between mail servers using STARTTLS without strong authentication.
- network-security№ 1159
TLS (Transport Layer Security)
The IETF-standardized cryptographic protocol that provides confidentiality, integrity, and authentication for traffic between two networked applications.
- network-security№ 345
DNSSEC
A set of DNS extensions that uses digital signatures to let resolvers verify the authenticity and integrity of DNS records.
- network-security№ 984
Secure Email Gateway
A perimeter or cloud service that filters inbound and outbound email for spam, phishing, malware, data leakage, and policy violations before it reaches user mailboxes.