What is DANE? Secure email with TLSA and DNSSEC

DANE (DNS-based Authentication of Named Entities) is a security standard that lets you record in your DNS which TLS certificate belongs to your domain. Instead of relying only on certificate authorities, you publish a fingerprint of your certificate in a dedicated DNS record and protect it with DNSSEC. This article explains what DANE is, how it works with TLSA records, how it differs from ordinary SSL/TLS, and why DNSSEC is required for DANE.

What is DANE?

DANE stands for DNS-based Authentication of Named Entities. It is an internet standard, described in RFC 6698 from 2012, that ties a TLS certificate to a domain name through the Domain Name System (DNS). This lets the other side check whether the certificate a server presents really is the certificate you designated.

You record that link in a TLSA record. Because ordinary DNS can be spoofed, DANE relies on DNSSEC: it signs your DNS records digitally, so an attacker cannot change the TLSA record unnoticed. Without DNSSEC, DANE offers no real protection.

A CAA record records which certificate authority is allowed to issue a certificate for your domain. DANE goes a step further and records which certificate or key is valid in the first place.

Why ordinary SSL/TLS is not always enough

An ordinary TLS connection, such as the padlock of HTTPS or TLS for email, trusts certificate authorities, or CAs for short. Your browser or mail server holds a list of hundreds of CAs it trusts, and any CA can in principle issue a certificate for any domain. If one of those CAs is hacked or tricked, an attacker can obtain a valid-looking certificate for your domain.

Email has a second problem. Mail servers usually use STARTTLS, an opportunistic form of encryption. An attacker sitting between two servers can strip the STARTTLS announcement, a so-called downgrade or strip attack, so the message is sent unencrypted after all. And even when TLS is used, the sending server often does not verify the certificate. DANE addresses both problems.

How does DANE work?

With DANE you publish a TLSA record in your DNS zone that holds a fingerprint of your certificate or of its public key. The checking side, for example a sending mail server, then takes three steps:

1. Look up the TLSA record at the correct name in DNS.
2. Verify the DNSSEC signature, so it is certain the record is genuine and unchanged.
3. Compare the certificate the server presents with the fingerprint from the record.

If the certificate matches, the connection is trusted. If it does not match, or a valid DNSSEC signature is missing, the connection is refused. For email this means encryption becomes mandatory and verified instead of optional.

The TLSA record and its fields

Other email security, such as SPF, DKIM and DMARC, is published in a TXT record. DANE uses a dedicated record type for this: the TLSA record. It sits at a special name built from the port, the protocol and the host name, in the form _port._protocol.hostname. For a mail server that uses SMTP on port 25, that is for example _25._tcp.mail.yourdomain.com. For HTTPS it would be _443._tcp.www.yourdomain.com.

The record itself consists of three parameters and the associated data:

After that comes the certificate association data: the actual fingerprint. A common combination for email is 3 1 1, meaning the server certificate, the public key and a SHA-256 hash. A complete record then looks like this:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 29c8d5f8e1b3a47c9d0e6f2a1b8c3d4e5f60718293a4b5c6d7e8f9012a3b4c5d6

The difference between DANE and ordinary SSL/TLS

The big difference is who decides which certificate to trust. With ordinary SSL/TLS that is the CA system: you trust every CA in the list, and you have no say in which CA may sign for your domain.

With DANE you decide, by recording in DNS which certificate, which key or which CA is valid. The client checks the presented certificate against that, and the information is protected by DNSSEC. DANE does not replace your certificate: you still need an ordinary TLS certificate. It adds an extra checkpoint that you control, and it makes encryption for email mandatory rather than optional.

Why DNSSEC is required for DANE

DANE stands or falls with DNSSEC. Ordinary DNS has no built-in security: an attacker who intercepts the traffic or fools a resolver can return different answers than the real ones. If that attacker could also spoof the TLSA record, they would simply point to their own certificate as valid and the protection would be gone.

DNSSEC signs your DNS records digitally. A resolver can then check that an answer really comes from your domain and was not altered along the way. Only once the TLSA record has been confirmed as valid through DNSSEC may the other side rely on it. That is why DNSSEC is not a recommendation but a requirement: without a signed zone, DANE does nothing. If needed, first read what DNSSEC is before you start with DANE.

Where is DANE used in practice?

DANE is mainly used to secure email between mail servers. The rules for that are set out in RFC 7672. Large providers now support it: Microsoft rolled out DANE with DNSSEC for inbound email on Exchange Online during 2024 and 2025, and Google Workspace has checked recipients' TLSA records for outbound email since 2023.

In the Netherlands, the Standardisation Forum promotes its use: STARTTLS and DANE are on the comply-or-explain list and are mandatory for government organisations. You can test your domain at internet.nl.

For ordinary websites, DANE is a different story. Browsers such as Chrome and Firefox do not support DANE and have no plans to. A TLSA record on port 443 therefore has no effect in the browser. In practice, DANE is mainly an email measure.

Setting up DANE and a TLSA record

Enabling DANE involves a few steps. The exact screens differ by DNS provider and mail server, but the approach is always the same:

1. Enable DNSSEC on your domain. This is the foundation: without DNSSEC, DANE does not work. At LJPc hosting, DNSSEC is available for domains registered with LJPc that use the LJPc name servers; you can have it checked or switched on through support.
2. Make sure your mail server offers TLS with a valid certificate.
3. Create a TLSA record from that certificate, usually in the form 3 1 1, the SHA-256 hash of the public key.
4. Publish the TLSA record at the correct name, for example _25._tcp next to your mail server's host name, in your DNSSEC-signed zone.
5. Check the configuration before you rely on it (see below).

What you can do with TLSA records depends on your DNS provider and mail server. Because DANE requires both DNSSEC and careful certificate management, it is best to arrange the setup together with support or your DNS provider. If you are unsure how this works for your domain, get in touch with support.

Checking your DANE configuration

Always check that your TLSA record is correct before you assume it works. On the command line you request the record with dig:

dig TLSA _25._tcp.mail.yourdomain.com +short

It is also important that DNSSEC is valid for your zone, because otherwise the other side ignores the record. Online you can check this with internet.nl or with a TLSA checker, for example. These tools show whether the fingerprint matches the certificate your server presents.

Common problems

Most DANE problems come from DNSSEC or from a TLSA record that no longer matches the certificate. This table helps you on your way:

With DANE you tie your TLS certificate to your domain through DNSSEC, so the other side knows for sure that the certificate really is yours. For email in particular, that makes your connections much harder to intercept. Cannot work it out? Get in touch with support at LJPc hosting and we will be glad to help.