How to Use DANE (DNS-Based Authentication of Named Entities) to Secure Email and TLS Without Relying on Certificate Authorities

Why DANE Matters: Escaping the Single Point of Failure in TLS

For years, the security of TLS—whether for web browsing, email, or other services—has depended on a fragile ecosystem of certificate authorities (CAs). A compromised CA can issue fraudulent certificates for any domain, enabling man-in-the-middle attacks. DANE (DNS-Based Authentication of Named Entities) offers a way to break that dependency by using the Domain Name System itself to vouch for certificates.

DANE works with DNSSEC (Domain Name System Security Extensions) to store certificate associations directly in DNS as TLSA (Transport Layer Security Authentication) records. When a client connects to a server, it looks up the TLSA record for the domain, verifies it with DNSSEC signatures, and then checks that the server’s certificate matches that record. No need to trust a long list of CAs—just the domain owner’s DNS.

This is especially powerful for email security, where traditional CA-based validation often falls short due to rogue or misconfigured CAs. DANE ensures that even if a CA is compromised, your domain’s TLS connections remain authentic.

How DANE Works: TLSA Records Explained

A TLSA record published in your domain’s DNS tells connecting clients what certificate to expect. It contains four fields:

• Usage – Defines the trust anchor (e.g., 3 for DANE-TA, meaning the certificate is trusted as a domain-issued anchor).
• Selector – Targets the full certificate (0) or the public key (1). Use 1 for easier rotation.
• Matching type – 0 (exact), 1 (SHA-256 hash), or 2 (SHA-512 hash). SHA-256 is standard.
• Certificate association data – The hash or full value of the certificate/public key.

For example, a typical TLSA record for SMTP might look like:

The client (e.g., a receiving mail server) must also have DNSSEC support. When it retrieves the TLSA record, it validates the DNSSEC chain. If the certificate presented by the server matches, the connection is trusted.

Securing Email with DANE

Email remains one of the most attacked services, often via downgrade attacks that strip STARTTLS. DANE (combined with MTA-STS) prevents this by insisting on a DNSSEC-verified TLSA record. When an outgoing mail server sees a DANE-enabled domain, it must establish a TLS connection that matches the TLSA record, or refuse to deliver mail.

Real-world example: A large German ISP, 1&1 Ionos, implemented DANE for inbound email. After enabling DNSSEC and publishing TLSA records for their mail servers, they eliminated a class of attacks where fake certificates could intercept email. Their security team reported a noticeable reduction in abuse complaints.

To implement DANE for your own email:

1. Enable DNSSEC on your domain via your registrar or DNS provider.
2. Generate a certificate (or use one from Let’s Encrypt) for your mail server. Compute the SHA-256 hash of the public key.
3. Publish a TLSA record for port 25 (_25._tcp.yourdomain.com) with usage=3, selector=1, matching type=1.
4. Test with our DNS Analyzer to verify the record is published and DNSSEC-signed.

Pro tip: Use usage=3 (DANE-TA) and selector=1 (public key). This allows certificate renewal without updating the TLSA record, as long as the private key remains the same.

DANE for HTTPS: An Alternative to CA Chains

Although less common, DANE can also secure HTTPS websites. Instead of relying on a CA to verify your web server, you publish a TLSA record for port 443. Browsers with DANE support (e.g., some Linux distributions or custom builds) will check that record. The advantage? No CA can issue a valid certificate for your domain without also controlling your DNS—which is protected by DNSSEC.

For a concrete example, the Swedish government domain myndighetswebb.se uses DANE for all public services. They publish TLSA records for _443._tcp.www.myndighetswebb.se. Visitors using a compatible browser get certificate validation without the risk of a compromised intermediate CA.

To check whether a domain uses DANE for HTTPS, you can use the SSL Checker to inspect the certificate chain, then manually verify the TLSA record with a dig command or the DNS Analyzer.

Actionable Tips for Implementation

• Combine DANE with MTA-STS: DANE provides cryptographically strong authentication, while MTA-STS offers policy flexibility. Many providers support both. Use DANE as the primary check and MTA-STS as a fallback.
• Monitor TLSA records regularly: Use your DNS provider’s monitoring or a third-party service that checks DNSSEC signatures. A broken TLSA record can cause email delivery failures if the client enforces DANE.
• Start with a test domain: Set up DANE on a low-risk subdomain first. Validate with tools like swaks (for SMTP) or the tlsa command-line utility.
• Plan for private key rotation: If you use selector=1 (public key), rotating keys means updating the TLSA record. Publish the new record before switching keys, and keep the old one valid for overlap until TTL expires.
• Inform your mail exchange partners: Some legacy email servers may not support DANE. Ensure your TLSA record includes a no DANE fallback? Actually, DANE is opt-in by the sending side. If the sender does not support DNSSEC, they will ignore TLSA and use normal CA-based TLS. That’s fine.

Pro tip: Use usage 3 (DANE-TA) for normal deployment—it gives you flexibility to change certificates as long as the private key stays the same. Only use usage 0 (CA constraint) if you have a specific CA that you trust exclusively.

Common Pitfalls and How to Avoid Them

• Missing DNSSEC: A TLSA record without DNSSEC is not DANE—it’s just a DNS record that can be spoofed. Make sure your domain’s DNS zone is signed and that the DS records are at the registrar.
• Wrong port or service: TLSA records are tied to a specific service (e.g., _25._tcp for SMTP). Don’t accidentally publish a record for port 443 on your mail server—it won’t match.
• Certificate mismatch: If your mail server uses a certificate chain with multiple intermediates, the TLSA record must match the certificate or public key actually presented during the TLS handshake. Use openssl s_client -showcerts -connect yourdomain:25 -starttls smtp to see exactly what is sent.
• Not testing before activating: Deploy on a test domain first. Many DNS providers offer free DNSSEC; experiment there.

Conclusion: The Future of TLS Trust

DANE isn’t a silver bullet—it still requires DNSSEC adoption, which lags globally—but it is a powerful step toward a more decentralized, resilient internet. By moving trust from hundreds of CAs to your own DNS, you drastically reduce the attack surface. For email administrators, DANE is practically mandatory for modern security (alongside MTA-STS). For web hosting, early adoption can give you a competitive edge in privacy and trust.

Start small, test thoroughly, and let DANE protect your domains from the next CA compromise.