Does DANE work without DNSSEC?
No. Without DNSSEC an attacker can forge or suppress the TLSA records themselves – the chain of trust breaks. A TLSA record in an unsigned zone is ignored by validating senders and offers no protection.
DANE test for mail servers – free TLSA check
This free test checks, for every MX of your domain, whether TLSA records exist, whether the zone is DNSSEC-signed and whether the TLSA data matches the certificate the server actually presents – the three conditions DANE cannot work without. Check your domain → Need a record? The free TLSA/DANE generator builds the recommended 3 1 1 record from your certificate.
What is DANE?
DANE (DNS-Based Authentication of Named Entities, RFC 6698; for SMTP: RFC 7672) anchors a mail server's certificate directly in the DNS: a TLSA record publishes a hash of the certificate or key that sending servers fetch before opening the connection and validate via DNSSEC. This lets senders enforce encryption – classic STARTTLS is opportunistic and can easily be stripped out by an attacker in the path (downgrade to plaintext). DANE closes exactly this gap and additionally makes mail transport independent of trust in individual certificate authorities.
The recommended TLSA record: 3 1 1
A TLSA record for the MX mail.example.com looks like this:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <SHA-256 hash of the public key>- Usage 3 (DANE-EE): the server certificate itself is what counts – no CA chain needed.
- Selector 1: only the public key (SubjectPublicKeyInfo) is hashed, not the whole certificate.
- Matching 1: SHA-256 as the hash algorithm.
The advantage of 3 1 1: certificate renewals (for example every 90 days with Let's Encrypt) do not change the record as long as the same key is reused. For a planned key change you publish the hash of the new key as a second TLSA record before the switch happens (rollover), and remove the old one afterwards.
DANE in Germany: BSI TR-03108
The technical guideline BSI TR-03108 ("Secure Email Transport") from Germany's Federal Office for Information Security (BSI) requires certified email providers to deploy, among other things, DNSSEC and DANE for inbound mail. Posteo is certified under this guideline; other German providers such as mailbox.org also meet its requirements and run DANE in production. By publishing your own TLSA records, you ensure that inbound mail from such providers is delivered only when it is encrypted and authenticated.
Common DANE mistakes – and how to fix them
- TLSA without DNSSEC: useless – validating senders ignore the records. Sign the zone first and lodge the DS record with your registrar.
- TLSA does not match the certificate: common after a server migration or a key change without rollover. Sending servers that validate DANE will then fail to deliver. With
3 1 1and a stable key this never happens on plain renewals. - Only one MX covered: every MX host needs its own TLSA records – including backup MX hosts.
- Record at the wrong name: the TLSA record belongs at
_25._tcp.<MX hostname>, not at the domain itself.
The domain security check uncovers all of these cases: it connects to every MX, matches the TLSA records against the certificate served live, and verifies the DNSSEC chain.
Frequently asked questions
Do I need DANE if I already have MTA-STS?
The two mechanisms complement each other. DANE anchors trust directly in the DNS via DNSSEC and works independently of the web PKI and CAs; MTA-STS distributes its policy over HTTPS and covers senders that do not validate DNSSEC. Publishing both gives you the broadest sender coverage.
Which TLSA record should I use?
The recommended one is 3 1 1: usage 3 (DANE-EE, the server certificate itself), selector 1 (only the public key), matching 1 (SHA-256 hash). This combination survives certificate renewals as long as the key stays the same; for a key change you publish the new hash as a second record in advance.
Sources
RFC 7672 (DANE for SMTP) ↗ · RFC 6698 (TLSA) ↗ · BSI TR-03108 ↗