What is DANE in Email Security and How Does it Work?

Many people think email security starts and ends with SPF, DKIM, and DMARC. These protocols are important because they help verify who sent an email. But they don’t protect the connection used to transfer that email from one mail server to another. If that connection isn’t secure, attackers may still be able to intercept the message while it’s in transit.

This is where DANE becomes important; it’s a security protocol that uses DNSSEC-protected TLSA records to verify TLS certificates and create a more trustworthy connection between servers. In this guide, we’ll explain how DANE DNSSEC works, why it matters for email security, and how it helps protect email communication from certificate-based attacks.

What is DANE?

DANE, or DNS-based Authentication of Named Entities, is an internet security protocol that helps verify TLS certificates using DNS. It lets a domain owner publish information about the TLS certificate used by a service directly in DNS through TLSA records.

These TLSA records are protected by DNSSEC, which helps make sure the DNS information is authentic and has not been changed in transit. When a client connects to a server, it can check the TLS certificate against the information published by the domain.

This adds another layer of protection to the traditional Certificate Authority (CA) system. Normally, clients trust CAs to confirm that a certificate belongs to the right domain. With DANE, the domain owner can also state which certificate or public key should be trusted.

DANE is especially useful for securing email traffic between mail servers. It helps prevent attackers from using fraudulent certificates to intercept or read email while it is being transmitted. It works alongside other email security technologies such as DMARC. While DMARC helps verify whether an email is authorized to use a domain, DANE helps verify whether the TLS connection used to deliver that email is secure.

How DANE Works

DANE brings together TLS certificates, DNS, and DNSSEC to verify that a client is connecting to the right server. Here is how the process works from publishing the certificate information to completing the TLS connection:

Step 1: The Domain Owner Adds a TLSA Record to DNS

The domain administrator creates a TLSA record for the service they want to protect. The record tells clients which certificate or public key they should expect when connecting to that service.

For example, an email domain could publish a TLSA record for its SMTP server under a name such as:

_25._tcp.mail.example.net

The TLSA record then contains information that can be used to identify the server’s valid TLS certificate. This gives the domain owner a way to declare certificate information through DNS instead of leaving certificate validation entirely to public Certificate Authorities.

Step 2: DNSSEC Protects the TLSA Record

A TLSA record is only useful if a client can trust that the record actually came from the domain owner. This is where DNSSEC DANE becomes important.

DNSSEC adds digital signatures to DNS data, including TLSA records. A validating resolver can use these signatures to check that the response is authentic and has not been modified between the authoritative DNS server and the client. This creates a chain of trust from the DNS root to the domain’s DNS records. Without DNSSEC, an attacker could potentially alter a TLSA response and provide false certificate information, defeating the purpose of DANE.

Step 3: The Client Queries the TLSA Record

When a client wants to establish a TLS connection, it needs to know which certificate the server is expected to use. For email, this can happen when one mail server connects to another over SMTP.

The client looks for the TLSA record at the service-specific DNS name. For SMTP on port 25, the lookup generally uses the _25._tcp prefix along with the receiving mail server’s hostname. The client does not simply trust any certificate returned by the server. It first obtains the certificate information published by the domain through DNS.

Step 4: DNSSEC Verifies the DNS Information

The client or its DNS resolver then checks whether the TLSA record is protected by valid DNSSEC signatures. This step is critical because DANE depends on DNS as a source of trust. DNSSEC allows the client to verify that the TLSA record is authentic and has not been altered.

If the DNSSEC validation fails, the client cannot safely rely on the TLSA information. This is why DANE DNSSEC is not just an optional combination. DNSSEC provides the trust needed for DANE’s DNS-based certificate authentication.

Step 5: The Server Presents its TLS Certificate

Once the client has obtained and validated the TLSA information, the TLS connection begins. During the TLS handshake, the server presents its TLS certificate. This certificate identifies the server and contains the public key and other information needed to establish the encrypted connection.

At this point, the client has two pieces of information to work with: the certificate presented by the server and the certificate information it previously obtained through the DNSSEC-protected TLSA record.

Step 6: DANE Checks the Certificate Against the TLSA Record

This is where DANE performs its main certificate check. The client examines the part of the certificate specified by the TLSA record’s selector and applies the specified matching type. It then compares the resulting value with the certificate data stored in the TLSA record.

The TLSA record also contains a usage value, which tells the client how the certificate should be treated. Depending on the configuration, DANE can work with the existing PKI system or allow the domain to define trust directly through DNS. This means DANE does not simply ask, “Is this certificate issued by a trusted CA?” It can also ask, “Does this certificate match what the domain has explicitly published?”

Step 7: A Successful Match allows the Connection

If the server’s certificate passes the TLSA check and the other TLS requirements are satisfied, DANE validation succeeds. The client can then continue establishing the encrypted TLS connection. For email, this helps protect communication between mail servers by making it harder for an attacker to substitute a different certificate during the connection.

DANE therefore adds certificate authentication at the DNS level while TLS continues to provide encryption for the actual connection.

Step 8: A Failed Match Stops the Connection

If the certificate presented by the server does not match the valid TLSA information, DANE validation fails. In a properly configured DANE deployment, the client will not accept the connection as secure. This can prevent an attacker from successfully using a different certificate to impersonate the intended server.

For email security, this is particularly useful against man-in-the-middle attacks. Even if an attacker obtains a certificate that appears valid under the traditional CA system, it may still fail the DANE check because it does not match the certificate information published by the domain.

What is a TLSA Record?

A TLSA record is the DNS record that DANE uses to publish information about a TLS certificate or public key. It tells a client what part of the certificate to check and how that information should be compared.

A TLSA record has four main fields:

<usage> <selector> <matching-type> <certificate-data>

For example, a domain might publish:

_25._tcp.mx.example.net. IN TLSA 3 1 1 7B91C4E2…

This is a simplified example, but it shows the basic structure. The _25._tcp portion identifies the SMTP service running on TCP port 25. The remaining values describe how the certificate should be validated.

Each field has a specific purpose:

• Usage: Defines how the certificate is trusted and what role DANE plays in the validation.
• Selector: Tells the client whether to use the complete certificate or the certificate’s public key for the comparison.
• Matching Type: Defines whether the selected certificate data is compared directly or through a cryptographic hash.
• Certificate Data: Contains the certificate or public-key value, or its hash, that the client compares against the server’s certificate.

TLSA Certificate Usage Values

The first value in a TLSA record is the certificate usage. It tells the client how the certificate information in the record should be used.

There are four possible values:

• 0 (PKIX-TA): Uses a trust anchor from the traditional PKI system and adds a DANE constraint.
• 1 (PKIX-EE): Uses the end-entity certificate while still relying on normal PKI validation.
• 2 (DANE-TA): Defines a trust anchor through DNS rather than relying only on the public CA system.
• 3 (DANE-EE): Specifies the end-entity certificate directly through DNS.

For email deployments, usage values 2 and 3 are especially important because they allow certificate trust to be tied directly to information published by the domain.

Where are TLSA Records Published?

TLSA records are published under a service-specific DNS name. The format identifies the port, transport protocol, and hostname of the service.

For SMTP on port 25, the name generally follows this structure:

_25._tcp.mail.example.net

The same principle can be used for other TLS-enabled services by changing the port and service hostname.

For email security, this makes the TLSA record particularly useful because it connects the certificate check to a specific mail server. When DANE is combined with DNSSEC, the client can verify both the certificate information and the authenticity of the DNS data used to obtain it.

This is the core idea behind DANE DNS: use DNS to publish certificate information, and use DNSSEC to make that information trustworthy.

Why is DANE Important

Traditional TLS connections depend heavily on Certificate Authorities (CAs). If a certificate is issued by a trusted CA, most clients will accept it and continue with the connection. While this model has worked for years, it is not perfect. Certificate Authorities can make mistakes, certificates can be issued to the wrong party, and attackers can sometimes exploit weaknesses in the certificate issuance process.

This is where DANE becomes valuable.

By allowing domain owners to publish certificate information directly in DNS, DANE DNS gives organizations greater control over certificate validation. Instead of relying entirely on external authorities, a domain can define which certificates should be trusted and protect that information through DNSSEC.

Here are some of the biggest advantages of implementing DANE DNSSEC:

Enhanced Certificate Validation

Traditional certificate validation depends on a client’s list of trusted Certificate Authorities. If a certificate chains back to one of those trusted authorities, the connection is usually considered secure.

DANE introduces an additional verification layer; before accepting a certificate, the client compares it with the TLSA record published by the domain owner. This means the certificate must satisfy both the traditional TLS checks and the DNS-based validation rules defined by the domain. This extra verification step reduces the risk of unauthorized certificates being accepted. It also gives domain owners greater control over which certificates can be used with their services.

Protection Against Certificate Mis-Issuance

Certificate mis-issuance occurs when a certificate is issued to someone who should not have received it. This can happen because of administrative errors, weaknesses in the verification process, or social engineering attacks that trick a Certificate Authority into approving a certificate request.

Without DANE, a fraudulently issued certificate may still appear legitimate because it comes from a trusted CA. With DANE DNSSEC, the certificate must also match the information stored in the domain’s TLSA record. If it doesn’t, the client can reject the connection.

This additional validation makes it significantly more difficult for attackers to use unauthorized certificates to impersonate legitimate services.

Support for Self-Signed Certificates

Traditional TLS environments usually depend on publicly trusted Certificate Authorities. As a result, self-signed certificates are often treated as untrusted.

DANE provides another option; instead of depending entirely on a public CA, a domain owner can publish certificate information directly through DNS and protect it with DNSSEC. Clients can then validate the certificate against the published TLSA record. This approach can be particularly useful for organizations that operate internal services, private applications, or specialized infrastructure. It also reduces dependence on third-party Certificate Authorities in environments where organizations prefer to manage certificate trust themselves.

Better Protection for Email Security

One of the most important use cases for DANE is securing email communication. Emails travel between multiple mail servers before they reach their final destination. During this process, messages often pass through servers operated by different organizations.

Most modern mail servers use STARTTLS to encrypt these connections. However, encryption alone does not always protect against certificate-based attacks or downgrade attempts. An attacker who intercepts the connection may try to force mail servers to use an unencrypted connection or present an unauthorized certificate.

DANE helps prevent these attacks by allowing the sending mail server to verify that it is communicating with the correct receiving server. This is particularly important because email security involves more than sender authentication. Also, protocols such as SPF, DKIM, and DMARC verify whether an email is authorized to use a domain. DANE, on the other hand, protects the encrypted connection used to deliver that message.

When combined with email authentication protocols, DANE DNS helps create a more secure email infrastructure.

DANE and DNSSEC

It’s impossible to discuss DANE without discussing DNSSEC because the two technologies are designed to work together. In fact, DNSSEC DANE is a dependency, not just a recommended combination.

The TLSA records used by DANE are stored in DNS, which was originally designed without built-in security protections. Traditional DNS responses can potentially be intercepted, modified, or spoofed.

DNSSEC solves this problem by adding cryptographic signatures to DNS records. When a client requests a TLSA record, it validates the DNSSEC signatures to confirm that the information actually came from the domain owner and wasn’t changed during transmission.

Without DNSSEC, there would be no reliable way to determine whether a TLSA record was authentic. An attacker could simply replace the legitimate record with a malicious one. This is why DNSSEC DANE should be viewed as a complete security model rather than two separate technologies.

Their roles are different but complementary:

• DNSSEC protects DNS records from tampering.
• DANE uses those protected records to validate TLS certificates.

Organizations planning to deploy DANE DNSSEC should enable DNSSEC first and confirm that their DNS provider supports DNSSEC signing before creating TLSA records.

Stronger Email Security Starts With Better Trust Models

Many organizations think email security can be fixed by setting up one protocol and forgetting about it. But that’s not how it works. Different technologies protect different parts of your email system. For example, authentication protocols help verify who sent the email. Encryption helps protect the message while it’s traveling between servers. DNS security makes sure DNS information hasn’t been changed. DANE adds another layer by helping servers verify TLS certificates through DNS.

The takeaway isn’t that every company needs to start using DANE right away. It’s that strong email security comes from using multiple layers that work together.

At EasyDMARC, we believe that understanding these technologies is the first step toward building a stronger and more secure email environment.

Frequently Asked Questions