The certificate authority system has a fundamental problem: any of hundreds of CAs can issue a certificate for any domain. If one CA is compromised, hacked, or coerced by a government, they can issue fraudulent certificates that browsers and mail servers will trust. It's happened before—DigiNotar, Comodo, WoSign—and it will happen again.
For web browsing, we've developed mitigations: Certificate Transparency logs, CAA records, browser vendor oversight. But email has historically been more vulnerable. Mail servers connecting to each other don't have the same ecosystem of protections.
DANE—DNS-based Authentication of Named Entities—offers a different approach entirely. Instead of trusting certificate authorities, you publish your certificate information directly in DNS, secured by DNSSEC. The sending server doesn't need to trust any CA; it just needs to trust DNS, which it already does for everything else.
The problem DANE solves
When your mail server connects to another server to deliver email, it needs to verify it's talking to the right server. Without verification, an attacker could intercept the connection and impersonate the destination.
Traditional TLS verification uses certificate authorities. The destination server presents a certificate, your server checks that it's signed by a trusted CA, and if so, proceeds. But this trust model has weaknesses.
First, there are too many trusted CAs. Your server probably trusts hundreds of certificate authorities by default. Any one of them could issue a certificate for any domain. A compromised CA in one country could issue certificates used to intercept email worldwide.
Second, opportunistic encryption is vulnerable to downgrade attacks. If an attacker can intercept the initial connection, they can strip out the TLS offer and force plaintext communication. The servers don't know they should require encryption.
DANE addresses both problems. It lets domain owners specify exactly which certificates are valid for their servers, published in DNS records that are cryptographically signed. No CA trust required. And because the policy is in DNS, sending servers know to require encryption before they even connect.
How DANE works
DANE uses a special DNS record type called TLSA (Transport Layer Security Authentication). This record specifies what certificate the server should present, published at a specific location in DNS.
The DNS name follows a pattern: _port._protocol.hostname. For a mail server at mail.example.com using SMTP (port 25), the TLSA record would be at _25._tcp.mail.example.com. This precision lets you specify different certificates for different services on the same host.
The TLSA record contains several fields. The usage field specifies how to validate the certificate—whether to check it against a CA, use it directly, or use it as a trust anchor. The selector field indicates whether you're specifying the full certificate or just the public key. The matching type field specifies whether you're including the full data or a hash.
Most email DANE deployments use usage type 3 (DANE-EE), which means "this is the exact certificate or public key the server will present, trust it directly." This completely bypasses the CA system—you're telling senders exactly what to expect.
DNSSEC: the foundation
DANE only works with DNSSEC. Without DNSSEC, an attacker who can manipulate DNS responses could publish fake TLSA records pointing to their own certificates. DNSSEC provides the cryptographic authentication that makes DANE trustworthy.
DNSSEC adds digital signatures to DNS records. Each record is signed by the zone's key, which is itself authenticated by the parent zone's key, all the way up to the root. A sending server can verify the entire chain, ensuring the TLSA record it received is authentic.
This is both DANE's strength and its limitation. DNSSEC provides strong authentication without trusting third-party CAs. But DNSSEC deployment remains incomplete. Many domains don't have DNSSEC, and many DNS resolvers don't validate it. If your domain doesn't have DNSSEC, you can't use DANE.
Setting up DANE for email
Implementing DANE requires several steps, and the order matters.
First, ensure your domain has DNSSEC. This typically means working with your DNS provider to enable signing and publishing DS records in the parent zone. Many DNS providers now support DNSSEC, but setup varies.
Second, obtain or identify the certificate your mail server uses. You need either the full certificate or its public key, depending on which selector type you choose. Using the public key (selector 1) is often preferred because it survives certificate renewals as long as you keep the same key.
Third, generate the TLSA record. You'll hash the certificate or public key using SHA-256 (matching type 1) and format it as a TLSA record. Tools exist to automate this—you don't need to do the hashing manually.
Fourth, publish the TLSA record in DNS. Remember the naming convention: _25._tcp.yourmailserver.example.com for SMTP. The record needs to be in place and DNSSEC-signed before senders will use it.
Finally, test thoroughly. DANE failures can cause email delivery failures, so verify everything works before relying on it. Several online tools can check your DANE setup and report problems.
DANE vs MTA-STS
DANE and MTA-STS solve similar problems—both prevent TLS downgrade attacks and certificate substitution. But they work differently and have different tradeoffs.
DANE requires DNSSEC but provides stronger security guarantees. The certificate authentication is cryptographic and doesn't depend on any third party beyond the DNS hierarchy. If DNSSEC is compromised, you have bigger problems than email security.
MTA-STS doesn't require DNSSEC but does require hosting a policy file over HTTPS. It relies on the web PKI (certificate authorities) for authenticating the policy file. This is arguably weaker than DNSSEC, but it's more deployable today.
In practice, MTA-STS has seen wider adoption because DNSSEC deployment remains limited. Google, Microsoft, and most major email providers support MTA-STS. DANE support is less universal, though it's growing.
If you have DNSSEC, implementing DANE provides the strongest protection. If you don't have DNSSEC and can't easily get it, MTA-STS is the practical choice. Implementing both provides defense in depth—senders that support DANE will use it, others will fall back to MTA-STS.
Common DANE mistakes
The most frequent DANE problem is TLSA records that don't match the actual certificate. This happens when certificates are renewed without updating DNS, or when the wrong certificate data is published initially. The result is delivery failures—sending servers see a mismatch and refuse to deliver.
Automation helps here. If you're using Let's Encrypt or another automated certificate system, integrate TLSA record updates into your renewal process. Some tools handle this automatically; others require scripting.
Another common issue is DNSSEC configuration problems. DANE requires valid DNSSEC all the way up the chain. If your DNSSEC signatures expire, or if there's a configuration error, DANE validation fails. Monitor your DNSSEC status continuously.
Publishing TLSA records before DNSSEC is fully deployed causes problems too. Senders that support DANE will try to validate, fail because DNSSEC isn't working, and may reject the email. Get DNSSEC working first, verify it thoroughly, then add TLSA records.
Is DANE worth implementing?
For organizations with high security requirements and existing DNSSEC infrastructure, DANE is the gold standard for email transport security. It provides cryptographic authentication without trusting certificate authorities, which matters if you're concerned about nation-state attackers or CA compromise.
For most organizations, the practical answer depends on DNSSEC. If you already have DNSSEC (perhaps for other reasons), adding DANE is relatively straightforward and provides real security benefits. If you don't have DNSSEC, the effort to implement it just for DANE may not be justified—MTA-STS provides similar protection with less infrastructure.
The email ecosystem is gradually moving toward requiring transport encryption. Whether through DANE, MTA-STS, or both, the direction is clear. Implementing one or both now puts you ahead of the curve and protects your email from interception.
Frequently asked questions
Can I use DANE without DNSSEC?
No. DANE fundamentally depends on DNSSEC for authentication. Without DNSSEC, an attacker could forge TLSA records, defeating the entire purpose. DNSSEC is a prerequisite, not optional.
What happens if my TLSA record is wrong?
Sending servers that support DANE will fail to deliver email to you. They'll see a mismatch between the TLSA record and your actual certificate and refuse to connect. This is why testing is critical before deployment.
Do major email providers support DANE?
Support is growing but not universal. Some European providers and security-focused organizations support DANE. Google has indicated support in some contexts. Check current compatibility before relying on DANE for critical email paths.
Should I use DANE or MTA-STS?
If you have DNSSEC, use DANE—it's more secure. If you don't have DNSSEC, use MTA-STS. If you have DNSSEC and want maximum protection, implement both. They're complementary, not competing.