DNS-based Authentication of Named Entities (DANE)
DANE, which stands for DNS-based Authentication of Named Entities, is a security protocol that uses DNSSEC (DNS Security Extensions) to associate TLS cryptographic certificates directly with domain names via the DNS infrastructure.
In standard TLS connections, trust is established through a chain of third-party Certificate Authorities (CAs). DANE provides an alternative trust mechanism: rather than relying on CAs, it publishes certificate information directly in DNS records (using the TLSA record type), allowing a connecting server to verify a certificate against what is published in the domain’s DNS. This removes a key point of failure in the certificate trust chain, making it significantly harder to intercept or spoof encrypted connections.
In email, DANE is used alongside STARTTLS to secure the connection between mail servers. When an email is in transit between two mail servers, DANE ensures that the receiving server’s TLS certificate matches the one published in its DNS, preventing downgrade attacks in which an attacker tricks a sending server into using an unencrypted connection. For DANE to work, the DNS records must be secured with DNSSEC, which provides the cryptographic guarantee that the DNS data has not been tampered with.
For B2B email marketers and deliverability specialists, DANE represents a stronger layer of email transit security than STARTTLS alone. Its adoption is growing among security-conscious organisations and is now required by some government and enterprise email systems. While the configuration is primarily a task for infrastructure and IT teams, understanding what DANE does and why it matters is increasingly relevant for anyone responsible for email programme security and authentication strategy.
What is the difference between DANE and traditional TLS for email?
Traditional TLS for email (using STARTTLS) relies on a Certificate Authority (CA) to validate the receiving server’s certificate. If a CA is compromised or issues a fraudulent certificate, an attacker could intercept the connection. DANE replaces or supplements CA validation with direct verification against DNS records secured by DNSSEC. This means the certificate’s legitimacy can be verified through the domain’s own DNS infrastructure, without needing to trust a CA. DANE effectively closes a known attack vector in the standard TLS trust model.
What is DNSSEC, and why is it required for DANE?
DNSSEC (DNS Security Extensions) is a set of DNS protocol extensions that add cryptographic signatures to DNS records, allowing resolvers to verify that the DNS data they receive has not been tampered with in transit. DANE depends on DNSSEC because the TLSA records it publishes, which contain certificate fingerprints, are only trustworthy if the DNS responses themselves are authenticated. Without DNSSEC, an attacker could intercept and modify DNS responses, replacing legitimate TLSA records with fraudulent ones, thereby defeating the purpose of DANE.
Is DANE widely supported for email?
DANE adoption in email is growing, but not yet universal. It is supported by major open-source mail transfer agents, including Postfix and Exim, and is required for secure email by some government and high-security enterprise environments. Consumer email providers and many commercial cloud email platforms have varying levels of support. For B2B organisations with strict security requirements, checking whether your email infrastructure and your key partners support DANE is worthwhile as part of a comprehensive email security review.