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.
- What is DANE? DNS-Based Authentication of Named Entities Explained (2026) - April 20, 2026
- VPN Security 101: Best Practices for Protecting Your Privacy - April 14, 2026
- MXtoolbox Review: Features, User Experiences, Pros & Cons (2026) - April 14, 2026
