What Is DANE? Certificate Binding Through DNSSEC Explained
When email is delivered encrypted between two mail servers, an awkward question arises: how does the sending server actually know it is talking to the real destination and not to a substituted counterpart? Protocols like STARTTLS encrypt, but often do not check whether the certificate presented is even the one expected. DANE closes exactly this gap.
This guide explains in plain terms what DANE and the TLSA record are, why DNSSEC forms the foundation, how DANE differs from MTA-STS, and how organisations can introduce tamper-proof transport encryption.
What is DANE?
TL;DR: DANE, short for DNS-based Authentication of Named Entities, binds TLS certificates directly to a domain in DNS. The core is standardised in RFC 6698, and for email transport specifically in RFC 7672. A domain publishes in DNS which certificate its server uses. The other side compares the certificate actually presented against this record and accepts the connection only if the two match. So the record cannot be forged, the DNS zone must be signed with DNSSEC.
DANE joins two worlds that were long separate: the Domain Name System and TLS certificates. Instead of relying solely on the fact that some certificate authority issued a certificate, DANE lets the domain state directly: my server uses exactly this certificate, please verify it. An attacker can then no longer substitute their own valid-looking certificate, because it will not match the published record.
DANE is not limited to email. In principle it can secure any protocol that uses TLS, from HTTPS to SMTP. By far the most important use case, however, is encrypted transport between mail servers, and that is the focus of this guide.
Like MTA-STS, DANE secures transport between mail servers, not the end-to-end encryption of individual messages.
Why is opportunistic STARTTLS not enough?
STARTTLS encrypts the connection but in practice accepts almost any certificate. Two problems follow:
- No requirement to encrypt: If the other side offers no TLS, or an attacker removes the encryption signal, delivery silently falls back to plain text.
- No identity check: Even when encryption happens, it remains open whether the certificate truly belongs to the expected server. A man in the middle with their own certificate goes unnoticed.
DANE removes both problems at once. If a TLSA record exists, encryption is mandatory and the certificate must match the record exactly. Otherwise delivery does not happen.
How does DANE work step by step?
Certificate binding runs in four steps:
Step 1, a signed zone: The domain's DNS zone is signed with DNSSEC. Only then are the following records tamper-proof.
Step 2, publish the TLSA record: Under a name like _25._tcp.mail.your-domain.com, a TLSA record is published. It contains a fingerprint of the expected certificate and parameters describing which part of the certificate chain is checked.
Step 3, a lookup on delivery: A sending server that supports DANE queries the recipient domain's TLSA record before delivery and uses DNSSEC to ensure the answer is genuine.
Step 4, the comparison: The server compares the certificate presented during the TLS handshake against the TLSA record. If it matches, the message is delivered encrypted. If it does not match or is missing, delivery is refused.
The TLSA record at a glance
The TLSA record does not describe the certificate itself, but how it is verified. Three parameters control this:
| Parameter | Meaning |
|---|---|
| Usage | Whether the certificate authority or the end certificate is bound |
| Selector | Whether the whole certificate or only the public key is compared |
| Matching | Whether the full value or a hash is stored |
For mail servers, binding to the public key is common, because it makes certificate renewal easier as long as the key is retained.
A concrete TLSA record looks like this, for example: _25._tcp.mail.your-domain.com. IN TLSA 3 1 1 a1b2c3...e5f6. The three numbers map to the parameters in the table above: 3 binds the server's end certificate directly, 1 checks only the public key, and 1 stores it as a SHA-256 hash. The long hex value is exactly that fingerprint. A sending server that supports DANE reads the record before delivery and compares it against the certificate from the TLS handshake.
DANE and DNSSEC: the inseparable bond
DANE stands or falls with DNSSEC. Without a signed zone, an attacker could forge the DNS answer carrying the TLSA record and so defeat the check. DNSSEC signs the answers cryptographically so the sending server can trust the certificate information. This tight coupling is also why DANE is not available everywhere: a domain without DNSSEC cannot use DANE.
Advantages, limits and adoption of DANE
The great advantage of DANE is its independence from the public certificate world. Trust rests solely in the domain's signed DNS zone, not in whether one of hundreds of certificate authorities has been compromised. And because the TLSA record is verifiable in a forgery-proof way from the very first contact through DNSSEC, there is no window of blind first-use trust.
These strengths come with clear limits. DANE strictly requires a DNSSEC-signed zone; without DNSSEC it is technically impossible. In operation it demands care, because every certificate renewal can break the TLSA record if the record is not updated in time. And the protection only takes effect if the sending party also evaluates DANE.
Adoption is mixed. DANE for email transport is strong among providers that use DNSSEC, especially in Germany and Europe and in the public-sector and research space, where the German BSI requires it for certified service providers. Large international freemail services increasingly support outbound DANE checking but do not always publish TLSA records for their own domains. The trend clearly points toward wider use, driven by regulation such as NIS2 and the BSI guidelines.
Placing DANE: MTA-STS comparison and the compliance question
Two questions come up around DANE almost every time. Each has its own dedicated, in-depth article.
DANE or MTA-STS? MTA-STS pursues the same goal as DANE but derives its trust from public certificate authorities and HTTPS rather than from DNSSEC. The two do not compete, and the German BSI even recommends running both in parallel. The full comparison with a decision guide is in MTA-STS or DANE.
Is DANE mandatory? No single law names DANE for every company. Through the BSI Technical Guideline TR-03108, the NIS2 implementation and section 30 of the German BSIG, however, demonstrable transport encryption becomes effectively mandatory for many organisations. DANE is the recognised measure for meeting that state-of-the-art requirement under Article 32 GDPR.
Setting up DANE with Conbool MailGuard
DANE is demanding in operation: DNSSEC must be active, the TLSA records must match the certificate exactly, and above all a certificate renewal must not break the binding. If the key is swapped without updating the TLSA record in time, email gets stuck. Conbool MailGuard handles this in both directions: inbound, the TLSA records are published and safely rolled over on a key change; outbound, the service checks the DANE binding of recipient domains and logs the result.
The current state of a domain is shown by the free transport security check. Details of the managed solution are on the DANE and TLSA page.
Frequently asked questions about DANE
What is DANE?
DANE stands for DNS-based Authentication of Named Entities. A domain publishes information in DNS about the expected TLS certificate of its mail server. A sending server checks the actual certificate against it and delivers only on a match.
What is a TLSA record?
The TLSA record is the DNS record through which DANE publishes the certificate binding. It contains a fingerprint of, or reference to, the expected certificate plus verification parameters. The zone must be signed with DNSSEC for this.
Why does DANE strictly require DNSSEC?
Without DNSSEC the TLSA record could be manipulated and the protection would be worthless. DNSSEC signs DNS answers cryptographically so the certificate information can be trusted. DNSSEC is therefore the basis of trust for DANE.
How does DANE differ from MTA-STS?
Both enforce encrypted transport but trust differently. DANE binds the certificate through DNSSEC, MTA-STS relies on certificate authorities and HTTPS. The BSI recommends running both in parallel in TR-03108.
Does DANE protect inbound or outbound email?
Both. Inbound, a domain publishes TLSA records for its own certificate. Outbound, the own mail server checks the TLSA records of recipient domains. Conbool MailGuard covers both directions.
Conclusion
DANE brings the missing identity check into email transport. Through a TLSA record signed with DNSSEC, the expected certificate is fixed in a binding way, so neither a silent downgrade nor a substituted certificate goes unnoticed. Together with MTA-STS and TLS-RPT it builds demonstrable transport protection that matches the BSI's recommendations and the obligations under NIS2.
The next step is yours: check your domain with the transport security check and see how Conbool MailGuard handles DANE.
Further reading:
