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, is described for email in RFC 7672. A domain publishes in DNS which TLS certificate its mail server uses. A sending server compares the certificate actually presented against this record and delivers 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 mail 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.
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.
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.
DANE or MTA-STS?
DANE and MTA-STS solve the same problem in different ways:
| Criterion | DANE | MTA-STS |
|---|
| Trust anchor | DNSSEC and TLSA | Certificate authorities and HTTPS |
| Requirement | Signed DNS zone | Reachable HTTPS subdomain |
| First contact | Protected immediately | Trust on first use |
| Adoption | Strong with DNSSEC providers | Broad platform support |
The two do not compete. A domain can offer both at once and so reach different sending systems. This is exactly what the German BSI recommends in its Technical Guideline TR-03108.
DANE and compliance: BSI TR-03108 and NIS2
For secure email transport, the BSI Technical Guideline TR-03108 names DANE as a central building block, alongside MTA-STS and TLS-RPT. Through the NIS2 Directive and section 30 of the German BSIG, secured communication becomes mandatory for many organisations. DANE is a concrete, technically demonstrable measure that maps onto these requirements and onto the state of the art 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:
