DANE and TLSATamper-proofemail transport
DANE binds the receiving mail server's certificate firmly in DNS via DNSSEC. This enforces TLS encryption between mail servers and protects it against downgrade as well as man-in-the-middle attacks, without any dependency on the public certificate world.
_25._tcp.mx.example.de. IN TLSA ( 3 1 1 d2abef7c... ) mx.example.de. IN RRSIG ( TLSA ECDSAP256SHA256 ... )
DANE closes the last major gap in email encryption during transport. SPF, DKIM and DMARC secure the authenticity of the sender. DANE and TLSA ensure that the path a message takes between mail servers is actually encrypted and that the receiving server is the genuine one.
Classic STARTTLS encrypts only opportunistically. An attacker on the transmission path can disable the encryption or substitute their own certificate without it being noticed. DANE ends this risk by publishing the fingerprint of the expected certificate in a TLSA record in DNS and signing it tamper-proof via DNSSEC.
DANE, TLSA and DNSSEC explained clearly
Three building blocks that together deliver verified transport encryption.
DANE
DNS-based Authentication of Named Entities
A method under RFC 7672 that tells the sending mail server via DNS which certificate the receiving server must present. If the binding does not match, delivery is refused rather than continued unencrypted.
TLSA record
the DNS entry behind DANE
The TLSA record holds the hash of the mail server certificate or of the public key. It is published under the name of the mail server, not under the recipient domain. The sending server compares this hash with the certificate from the TLS handshake and detects any deviation immediately.
DNSSEC
the cryptographic protection of DNS
DANE strictly requires DNSSEC. Only the signature of the DNS zone ensures that the TLSA record itself has not been manipulated. Without DNSSEC there would be no trustworthy basis for the certificate binding.
Why opportunistic STARTTLS is not enough
The standard encryption in SMTP transport can be undermined without sender or recipient noticing.
encrypts only when both sides offer it, and otherwise falls back silently to plaintext
an attacker on the path can present their own certificate without being detected
the TLS negotiation can be actively removed so that the message travels in plaintext
With opportunistic encryption, the sending server does not check whether the remote party's certificate is genuine. This is exactly where stripping and downgrade attacks come in. They remove the TLS hint from the server response or substitute a forged certificate. The message is delivered, but the protection was an illusion. DANE prevents this because the expected certificate binding is already established before the connection is set up.
How certificate binding with DANE works
Four steps from the DNS lookup to enforced encryption.
- 1
DNSSEC lookup of the recipient domain
The sending mail server determines the responsible mail server from the MX RRset and checks whether the DNS responses are validly signed. Only signed responses can serve as the basis for the binding.
- 2
Retrieve the TLSA record at the MX hostname
The record is queried under the name _25._tcp. followed by the MX hostname, not under the recipient domain. Only when a domain carries no MX entry at all does the domain itself take that place. The record contains the expected certificate fingerprint.
- 3
Match the TLS handshake
In the handshake, the receiving server presents its certificate. The sending server compares it with the hash from the TLSA record.
- 4
Enforce or refuse
If the binding matches, the message flows encrypted. If it does not match, delivery is refused and not continued unencrypted.
DANE and MTA-STS compared
Both enforce TLS in transport, with a different trust anchor. In practice they complement each other.
| Property | DANE and TLSA | MTA-STS |
|---|---|---|
| Trust anchor | DNSSEC-signed TLSA record | public certificate world and HTTPS policy |
| Protection on first contact | effective immediately | trust only after first contact |
| Prerequisite | DNSSEC required | no DNSSEC needed, but a web server for the policy |
| Downgrade protection | cryptographically enforced | policy-based enforcement |
| BSI TR-03108 | mandatory | optionally recognized |
Conbool supports both methods. DANE covers all senders that evaluate DNSSEC, MTA-STS complements it for senders without DNSSEC. The combination closes the first-contact gap completely.
DANE is mandatory under BSI TR-03108
The Technical Guideline BSI TR-03108 for secure email transport makes DANE binding for certified service providers.
The Federal Office for Information Security classifies DANE as effective and scalable protection against man-in-the-middle threats in encrypted email transport. MTA-STS is recognized in version 2.0 as an optional complement, but does not replace DANE. Anyone who wants to demonstrate transport security according to the current state of the art cannot avoid DANE.
- Binding certificate association via the TLSA record
- DNSSEC as a signed trust basis
- Demonstrable protection against downgrade and manipulation
- Compatible with NIS2 and industry-specific requirements
DANE with Conbool MailGuard: enforced outbound, inbound at your own MX
Outbound, Conbool MailGuard checks every delivery against the recipient certificate binding. Inbound DANE requires a mail server you operate yourself, in OnPrem operation or as a partner with your own MX.
TLSA record derived from the certificate
Conbool derives the matching TLSA record from the certificate the MX presents in the handshake and shows it with the full record name. The record belongs at the MX hostname, not at your own domain. The same check shows whether a record that is already published still matches the certificate and whether it is DNSSEC-secured.
Outbound validation
Outbound messages check the recipient's TLSA record and deliver only when the binding is correct.
DNSSEC-validating resolver
A dedicated validating resolver ensures that only signed DNS responses serve as the basis.
Safe fallback
Temporary DNS errors lead to a controlled deferral instead of unencrypted delivery. Protection is never silently switched off.
Tooling for certificate changes
Conbool shows the TLSA record of the certificate currently being served and reports as soon as a published record no longer matches it. The value for a new certificate is derived by the operator of the MX from the new key; old and new belong in DNS side by side for a while, and the new certificate is served only after propagation.
Every decision in the log
Every DANE decision, with its outcome, is recorded in the delivery log and can be traced there.
Frequently asked questions about DANE and TLSA
What is the difference between DANE and TLSA?
Does DANE strictly require DNSSEC?
How does DANE differ from MTA-STS?
Is DANE relevant for Microsoft 365 or Exchange?
What happens during a certificate change?
Does DANE break delivery if a recipient has configured it incorrectly?
How can you check whether a domain uses DANE?
Is DANE alone enough for secure email transport?
Is DANE also possible when operated with your own provider?
Further building blocks of transport security
MTA-STS
Enforced TLS encryption for all senders, even without DNSSEC.
TLS-RPT
Reports on transport errors, so that no silent encryption gap goes undetected.
Directory harvesting protection
Defense against attacks that scrape valid email addresses at the server.
MailGuard
The email security gateway that bundles all transport and content protection functions.
Make transport security demonstrable
The free mail check shows within minutes whether DANE, DNSSEC and transport encryption of your own domain take effect correctly.