Guides TLSA / DANE
What is DANE (TLSA)?
In a normal TLS connection you rely on certificate authorities (CAs): your server presents a certificate and the other side trusts it if a known CA signed it. DANE (DNS-based Authentication of Named Entities) adds a second anchor: in your own DNS you declare which certificate (or which CA) is valid. Because that's signed with DNSSEC, no one can tamper with it unnoticed. That's especially valuable for mail servers, where the certificate on the other end has traditionally hardly been checked at all.
How it works
You publish a TLSA record on a name that indicates the service and port, for example _25._tcp.mail.example.com for mail on port 25. That record holds a 'fingerprint' of the certificate your server should present, plus three digits saying how to check it. Example: _25._tcp.mail.example.com TLSA 3 1 1 <fingerprint>. That's the most common type, where the fingerprint is your server's public key.
When another mail server connects, it fetches the TLSA record (over DNSSEC, so trustworthy) and compares it with the certificate your server offers. If they don't match, it refuses the connection. A man-in-the-middle with a different certificate can't get through.
DNSSEC is a hard requirement
DANE lives or dies with DNSSEC. The whole idea is that the TLSA record can't be forged, and that guarantee comes from DNSSEC. Without DNSSEC, connecting servers ignore your TLSA record entirely. It then does nothing.
So read the DNSSEC guide first and make sure that's in order before you start on DANE.
Why mainly for mail?
For websites DANE is rare: browsers don't support it, so there you rely on CAs and MTA-STS-like mechanisms. For mail between servers (SMTP), DANE is popular, because there used to be no good certificate checking at all. Large mail operators validate DANE, and in some countries it's become almost the norm.
DANE and MTA-STS solve roughly the same problem. Many domains pick one, some do both.
Watch out: maintenance and key changes
Like DNSSEC, DANE is unforgiving: renew your certificate but forget to update the TLSA record, and the fingerprint no longer matches. Every sender that validates DANE then refuses the connection, and your incoming mail gets stuck.
So preferably tie the TLSA record to your server's public key, which you reuse at every renewal (the common '3 1 1' type). Not to one specific certificate, then, and preferably not to a CA intermediate either, since CAs rotate those regularly. Need to change the key after all? Publish the new fingerprint alongside the old one first, only then switch, and clean up the old one.
Frequently asked questions
Do I need DNSSEC for DANE?
Yes, absolutely. Without DNSSEC your TLSA record is ignored and DANE does nothing.
DANE or MTA-STS: which should I choose?
Both secure mail transport. MTA-STS works without DNSSEC and leans on HTTPS. DANE requires DNSSEC and pins the certificate in DNS. If you already have DNSSEC, DANE is a logical choice. Otherwise MTA-STS is easier. You can do both too.
Does DANE work for my website?
In practice no: browsers don't support DANE. It's mainly a mail thing (SMTP). For websites you rely on CAs and HSTS.
What does _25._tcp mean?
That indicates the service and port: _25 is port 25 (SMTP) and _tcp the protocol. The TLSA record thus attaches to a specific service of your server.