What Is DANE? DNS-Based Authentication Of Named Entities Explained

Key Takeaways

DANE shifts TLS certificate validation from third-party Certificate Authorities to DNS, using DNSSEC-signed TLSA records to establish trust.
It prevents STARTTLS downgrade attacks by enforcing encrypted connections instead of allowing silent fallback to plaintext.
DANE reduces the risk of misissued or compromised certificates by letting domain owners define exactly which certificates are valid.
DNSSEC is mandatory for DANE to work. Without it, TLSA records cannot be trusted or verified.
While powerful, DANE adoption is still limited, so it’s often used alongside MTA-STS and complemented by DMARC for complete email security.

DNS-Based Authentication of Named Entities, or DANE, is a method for verifying TLS certificates using DNS. It relies on DNSSEC and TLSA records to make sure encrypted connections are not intercepted or downgraded.

The Problem DANE Was Designed to Solve

Email delivery over Simple Mail Transfer Protocol (SMTP) often uses STARTTLS to upgrade connections to encryption. The issue is that STARTTLS is opportunistic. This means that if encryption fails, the connection can fall back to plaintext. This downgrade can happen silently, making it easy for attackers to exploit this behavior to intercept emails.

The Normal Path:

The Attack Path:

There is also a second problem with traditional TLS:

TLS certificates are validated through commercial Certificate Authorities (CAs). These CAs can be compromised or may issue certificates incorrectly. If an attacker obtains a valid certificate for a domain, they can impersonate that server.

These two issues make man-in-the-middle attacks possible even when TLS is used. DANE addresses both problems by moving certificate validation into DNS, secured by DNSSEC. This removes dependence on external CAs and prevents silent downgrade attacks.

What Is DANE?

DANE is an internet security protocol that allows domain owners to publish information about their TLS certificates directly in DNS using TLSA records.

These records are protected by DNSSEC, which ensures:

The records cannot be altered in transit
The client can verify that the response is authentic

Instead of trusting a third-party CA, the client validates the certificate against what the domain itself has published.

How DANE Works: Step by Step

Step 1: The domain owner publishes a TLSA record in DNS

The domain administrator creates a TLSA (Transport Layer Security Authentication) resource record and publishes it in their DNS zone. This record contains the certificate data that clients will later use for verification.

Step 2: The DNS zone is signed using DNSSEC

DNSSEC (DNS Security Extensions) cryptographically signs the entire DNS zone, including the new TLSA record. This creates a chain of trust from the root DNS zone down to the domain’s records, preventing tampering.

Step 3: A client connects to the server and queries the TLSA record

When a client (such as a mail server or browser) wants to establish a TLS connection to the server, it first queries the DNS for the domain’s TLSA record.

Step 4: The client validates the DNS response using DNSSEC

Before trusting the TLSA record, the client’s resolver validates the DNSSEC signatures by walking up the chain of trust.

Step 5: The server presents its TLS certificate

During the TLS handshake, the server sends its TLS certificate to the client, to prove its identity by presenting its certificate chain.

Step 6: The client compares the certificate with the TLSA record

This is the most important part of the DANE check. In this step, the client extracts the relevant part of the server’s certificate and compares it against the data stored in the TLSA record.

Step 7: If they match, the connection proceeds

When the certificate data matches the TLSA record, DANE validation succeeds, thereby establishing the TLS connection successfully.

Step 8: If they do not match, the connection is rejected

When the certificate does not match the TLSA record, the client treats this as a security failure and refuses to complete the TLS handshake. This prevents man-in-the-middle attacks from succeeding in the first place.

What Is a TLSA Record?

A TLSA record is a DNS record used by DANE to define how a TLS certificate should be validated.

The format looks like this: <usage> <selector> <matching-type> <certificate-data>

Example TLSA Record:

_25._tcp.mail.example.com. IN TLSA 3 1 1 (

2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)

Each field has a specific role:

Usage: Defines how the certificate should be matched and trusted
Selector: Specifies which part of the certificate is used (full certificate or public key)
Matching Type: Indicates how the data is stored (full value or hash)
Certificate Data: The actual value or hash to compare against

Certificate Usage Values

There are four usage types:

0 (PKIX-TA): Trust anchor constraint using traditional PKI
1 (PKIX-EE): End-entity certificate validated via PKI
2 (DANE-TA): Trust anchor defined by DNS
3 (DANE-EE): End-entity certificate defined directly in DNS

For email security, usage values 2 and 3 are the most relevant because they remove reliance on public CAs.

Where TLSA Records Are Published

TLSA records are published under specific service-based subdomains. For SMTP, this typically looks like: _25._tcp.mail.example.com

DANE for Email: How It Secures SMTP

DANE helps the sending server to verify the authenticity of the receiving server’s certificates. This verification helps prevent STARTTLS downgrade and man-in-the-middle attacks, helping secure SMTP communications.

DANE enforces TLS for email transmission, which prevents messages from being sent in plaintext or tampered with in transit.

Why DANE Requires DNSSEC

DANE depends entirely on the integrity of DNS records. Without DNSSEC, TLSA records could be spoofed, and attackers could redirect clients to malicious certificates. Here’s how the dependency works: DNSSEC signs DNS responses using cryptographic keys. This allows the client to verify that the response has not been altered and that the data is authentic. Hence, without DNSSEC, DANE does not provide any real security benefit.

Who Uses DANE?

DANE adoption varies globally, with the highest rates among European government agencies and organizations in the US. Adoption is growing among sectors where email confidentiality is critical. Common users of DANE include:

Email administrators as a layer of authentication and security
Government agencies in European countries and the US, to secure public sector email transmission (example: Germany’s T-Online is a real-world adopter of DANE)
Email providers such as Comcast, Protonmail, etc.
Microsoft announced support for DANE inbound SMTP starting in July 2024.

DANE vs. MTA-STS: What’s the Difference?

Both DANE and Mail Transfer Agent – Strict Transport Security (MTA-STS) are designed to secure SMTP connections, but they use different trust models. While MTA-STS relies on HTTPS and Certificate Authorities (CA), DANE relies on DNSSEC and DNS. Here are some of the key differences between the two:

Feature	DANE	MTA-STS
DNSSEC required	Yes	No
Policy location	DNS	HTTPS policy file
CA dependency	Optional	Required
Downgrade protection	Strong	Strong
Adoption	Low	High

To learn more about MTA-STS, read our complete guide on what is MTA-STS. To learn how to implement MTA-STS on your domain, check out our MTA-STS implementation guide.

How TLS-RPT Works Alongside DANE and MTA-STS

TLS-RPT is a reporting protocol that provides visibility into TLS negotiation failures and delivery issues caused by DANE or MTA-STS misconfigurations. Think of TLS-RPT as a visibility layer on top of DANE and MTA-STS (security layers). While both DANE and MTA-STS help enforce TLS to secure email transmissions, there is a critical gap in clarity as to when or why delivery fails.

That’s where TLS-RPT comes in. The SMTP TLS reporting (TLS-RPT) protocol sends back daily aggregate feedback reports to receiving servers about:

TLS negotiation failures
Certificate validation issues
Policy mismatches (MTA-STS or DANE)
Delivery failures due to TLS enforcement

How to Check If Your Domain Has a DANE/TLSA Record

To verify DANE setup, you need to check:

Whether a TLSA record exists for your mail server
Whether DNSSEC is enabled and valid
Whether the certificate matches the TLSA record

You can use PowerDMARC’s free DANE Record Checker to quickly validate your configuration.

How to Implement DANE for Email

To implement DANE for your email, you can follow the steps below:

Step 1: Enable DNSSEC

DANE cannot work without DNSSEC, so the first step is to configure DNSSEC through your DNS provider or registrar. You can check if you already have it configured for your domain using our DNSSEC checker tool.

Step 2: Get Your TLS Certificate Data

Extract the certificate or public key hash from your mail server.

Step 3: Create the TLSA Record

Define the correct usage, selector, and matching type, then publish your TLSA record under the appropriate subdomain.

Step 4: Validate the Record

Use our DANE checker tool to confirm that the record is correct and DNSSEC is working.

Step 5: Monitor Certificate Changes

When your TLS certificate is renewed or changed, the TLSA record must be updated. Failure to do this can break mail delivery.

Final Words

If you aren’t already securing your email’s transport layer using MTA-STS, DANE can be a great starting point. Especially in sectors handling sensitive data, such as financial institutions and public sector agencies, securing messages against interception is critical.

However, DANE cannot prevent spoofing or phishing attacks using your own domain name. For that, DMARC is essential. Want a full-stack domain security suite that handles your email authentication from start to finish? Book a demo with our experts today.

Frequently Asked Questions

Is DANE the same as DNSSEC?

No, DANE and DNSSEC are not the same, though DANE requires DNSSEC to function. DNSSEC secures DNS records, while DANE uses DNSSEC to securely publish certificate information.

Do I need both DANE and MTA-STS?

Not necessarily, but using both provides broader compatibility and stronger protection. Overall, MTA-STS has a higher adoption rate than DANE.

Does DANE replace SPF, DKIM, or DMARC?

No. DANE secures the transport layer while SPF, DKIM, and DMARC handle email authentication and spoofing prevention. For well-rounded email security, a multi-layered approach that combines all protocols along with consistent monitoring and updates is necessary.

What happens if my TLSA record is wrong?

If your TLSA record is incorrect, mail servers that enforce DANE will reject connections. This can lead to email delivery failures. It’s important to validate your DANE configuration (including the validity of your TLSA record) to troubleshoot any issues.

Which email providers support DANE?

The support for DANE varies worldwide. Some European providers and security-focused organizations enforce it, but global adoption is still limited.

About
Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

What is DANE? DNS-Based Authentication of Named Entities Explained (2026)