What Is DANE? DNS-Based Certificate Authentication Explained (2026)
DANE (DNS-Based Authentication of Named Entities) lets domain owners publish their TLS certificate information directly in DNS, removing the need to blindly trust certificate authorities. This guide covers how DANE works, why DNSSEC is required, and how it protects both email and web traffic.
What Is DANE?
DANE stands for DNS-Based Authentication of Named Entities. Defined in RFC 6698, it is a protocol that allows domain owners to specify exactly which TLS certificates are valid for their services by publishing TLSA records in DNS. Instead of relying solely on the public certificate authority (CA) system, DANE binds certificates to domain names using the DNS infrastructure itself.
This means that even if a rogue or compromised CA issues a fraudulent certificate for your domain, a DANE-aware client will reject it because it does not match the TLSA record you published. DANE effectively gives you, the domain owner, full control over which certificates are trusted for your services.
How TLSA Records Work
A TLSA record is a DNS record that associates a TLS certificate or public key with a specific service on your domain. The record is published at a specific name that combines the port number, protocol, and domain name. For example, a TLSA record for HTTPS on example.com would be published at:
_443._tcp.example.comA TLSA record contains four fields:
- Certificate Usage — Specifies how the certificate should be matched: CA constraint (0), service certificate constraint (1), trust anchor assertion (2), or domain-issued certificate (3).
- Selector — Whether to match the full certificate (0) or just the public key (1).
- Matching Type — How to compare: exact match (0), SHA-256 hash (1), or SHA-512 hash (2).
- Certificate Association Data — The actual certificate data or hash to match against.
The most common configuration for email servers is usage 3, selector 1, matching type 1 (known as "3 1 1"), which publishes the SHA-256 hash of the server's public key. This approach is resilient to certificate renewals as long as the key pair stays the same.
DANE vs Traditional Certificate Authorities
The traditional TLS trust model relies on certificate authorities (CAs). Any of the hundreds of publicly trusted CAs can issue a certificate for any domain. If a single CA is compromised — as has happened with DigiNotar and others — attackers can obtain valid certificates for domains they do not own.
DANE solves this by moving trust to DNS. When a domain publishes a TLSA record, connecting clients can verify that the certificate presented during the TLS handshake matches what the domain owner explicitly authorized. Key differences include:
- No CA dependency. With DANE usage type 3, you can use self-signed certificates because trust is anchored in DNS, not a CA.
- Domain owner control. Only you decide which certificates are valid for your domain.
- Protection against CA compromise. A rogue CA cannot issue a certificate that will pass DANE validation.
- Requires DNSSEC. DANE only works if your domain has DNSSEC enabled, which adds cryptographic signatures to DNS responses.
The DNSSEC Requirement
DANE is completely dependent on DNSSEC (Domain Name System Security Extensions). Without DNSSEC, an attacker could spoof DNS responses and publish fake TLSA records pointing to their own certificate. DNSSEC prevents this by cryptographically signing DNS records, allowing resolvers to verify that responses have not been tampered with.
If your domain does not have DNSSEC enabled, DANE-aware clients will simply ignore your TLSA records. This is by design — unsigned TLSA records provide no security guarantee. Before deploying DANE, ensure your domain's entire DNS chain is DNSSEC-signed, from the root zone down to your domain.
DANE for SMTP (Email)
DANE's most significant adoption is in email. SMTP, the protocol used to transmit email between servers, has a well-known weakness: STARTTLS is opportunistic. A man-in-the-middle attacker can strip the STARTTLS command and force email to be sent in plaintext. Even when TLS is negotiated, the sending server typically does not verify the receiving server's certificate.
DANE for SMTP (defined in RFC 7672) solves both problems. When a sending mail server supports DANE, it looks up the TLSA record for the receiving server's MX host. If a valid, DNSSEC-signed TLSA record exists, the sender:
- Requires TLS — the connection will not fall back to plaintext.
- Verifies the certificate against the TLSA record — preventing man-in-the-middle attacks.
Major email providers including Gmail, Yahoo, and Comcast already support DANE for outbound email delivery. On the receiving side, providers like mail.de, Proton Mail, and many European ISPs have deployed DANE with TLSA records on their MX servers.
DANE for SMTP works alongside MTA-STS, another protocol that enforces TLS for email. While MTA-STS uses HTTPS to publish its policy (making it easier to deploy without DNSSEC), DANE provides stronger cryptographic guarantees when DNSSEC is available.
DANE for HTTPS
While DANE was originally designed to work for any TLS service including HTTPS, browser adoption has been limited. Major browsers (Chrome, Firefox, Safari) do not currently perform DANE/TLSA validation for web traffic. This is partly because DNSSEC deployment is not yet universal, and partly because browsers rely on Certificate Transparency (CT) logs and HSTS as alternative mitigations against CA compromise.
That said, DANE for HTTPS remains relevant in specific contexts such as server-to-server API communication, IoT devices, and custom applications where developers control the TLS client and can implement DANE validation directly.
DANE Adoption Status in 2026
DANE adoption has been growing steadily, particularly in the email ecosystem. Key highlights:
- Email (SMTP): DANE is widely deployed among European email providers and government domains. The Netherlands, Germany, and the Czech Republic lead in DANE adoption. Gmail supports DANE validation for outbound mail.
- DNSSEC: DNSSEC deployment continues to grow but remains a barrier. Many domain registrars now offer one-click DNSSEC activation, making it easier to adopt.
- HTTPS: Browser support remains absent, but server-to-server use cases continue to grow.
- Government mandates: Several European governments require DANE for official email domains, driving adoption in the public sector.
How to Check Your DANE Configuration
You can verify whether a domain has DANE configured correctly using our free tools:
- DANE Checker — Verify TLSA records, DNSSEC status, and certificate matching for any domain.
- MTA-STS Checker — Check the complementary MTA-STS policy for email TLS enforcement.
- SSL Checker — Inspect the TLS certificate currently served by any domain.