DANE / TLSA
A TLS connection needs two things: encryption (provided by the handshake) and authentication of the server (usually provided by the public CA system). DANE is a different way to do the second part: publish a hash of your server's key in DNS, sign the DNS with DNSSEC, and let the client match the two.
Core spec: RFC 6698. Operational update with the current recommendations: RFC 7671. DANE is only as strong as the DNSSEC underneath it. Without a signed zone, there is no DANE.
What it is
DANE defines a new DNS record type called TLSA (type 52). The record is published at a hierarchical name that encodes the port and protocol:
_25._tcp.mx.example.com. 3600 IN TLSA 3 1 1 a1b2c3...A client resolving mx.example.com for an SMTP connection looks up _25._tcp.mx.example.com TLSA, computes the matching hash from the cert the server presents, and compares. If they match, the connection is authenticated. If not, the connection is aborted.
The TLSA record
Four fields: usage, selector, matching, and data. The interesting cell is usage.
3 = DANE-EE: match the server's own certificate. Ignore the public CA system entirely.
1 = SPKI: match the SubjectPublicKeyInfo (the key), not the whole cert. Survives cert rotation when the key stays the same.
1 = SHA-256: match the SHA-256 hash of the selected data. Compact and strong.
the 32-byte SHA-256 hash of your server's SubjectPublicKeyInfo
The spec defines four usage values. In practice only two matter:
- DANE-EE (3): match the server's own end-entity certificate. The public CA chain is ignored; the TLSA alone is the trust decision. This is the common case. You rotate certs by publishing a new TLSA a few days before rotation.
- DANE-TA (2): match a trust anchor you control (for example, your own internal CA). The server must include that CA in its TLS handshake so the client can verify.
Usage 0 (PKIX-TA) and 1 (PKIX-EE) combine DANE with the public CA system. RFC 7671 says both should be avoided: they duplicate what the CA system already does, and no major client honours them in practice.
SMTP DANE
DANE for SMTP (RFC 7672) is where DANE actually runs in production. It makes TLS on SMTP mandatory and verifiable between servers, which plain STARTTLS cannot do.
- 01·sending MTAactionMX? example.comresultMX 10 mx.example.com
- 02·sending MTAactionTLSA? _25._tcp.mx.example.com (DNSSEC)resultTLSA 3 1 1 a1b2c3...
- 03·sending MTAactionTCP connect to mx.example.com:25resultSTARTTLS; server presents cert
- 04·sending MTAactionhash SPKI of presented cert; compare to TLSA dataresultmatch → accept TLS; mismatch → abort delivery
The sending MTA looks up the TLSA, connects, verifies the cert's hash, and delivers. If the TLSA exists but the cert does not match, delivery is aborted instead of falling back to plaintext. That is the whole point: STARTTLS by itself is trivially downgraded by an attacker on the path; DANE is not.
Where it is used
DANE for SMTP is the main deployment in 2026. Supported by Postfix, Exim, and the large Dutch and German mail operators. Microsoft Exchange Online enables DANE validation for outbound. Google Workspace has been piloting it.
DANE for the web (HTTPS) never took off. Browsers do not validate TLSA, and there is no major initiative to change that. For HTTPS, HSTS and the public CA system remain the practical answer. For SMTP, DANE is the answer.
DANE also sits alongside MTA-STS. Both solve similar problems for mail. MTA-STS uses a DNS TXT pointer plus an HTTPS-served policy file, no DNSSEC required. DANE uses DNS alone but requires DNSSEC. Many operators ship both; they do not conflict.
What it is not
- Not for web browsers. No major browser validates TLSA. A TLSA on your website does nothing.
- Not standalone. DANE without DNSSEC is trivially forgeable. DNSSEC is the whole root of trust.
- Not a pinning replacement. Key pinning (HPKP) was a browser mechanism; it has been deprecated and removed. DANE sits at the DNS layer and is consumed by servers, not browsers.
Common mistakes
An attacker who can spoof DNS can replace the TLSA with their own hash. DNSSEC signs the DNS responses so the TLSA cannot be tampered with in transit.
DANE-EE with selector 1 (SPKI) survives cert rotation as long as the key stays the same. Selector 0 (full cert) does not. If you rotate the key, publish the new TLSA alongside the old one, wait out the TTL, then remove the old.
No client honours these. Stick to DANE-EE (3) or DANE-TA (2).
If your MX points at a host that is itself a CNAME, publish the TLSA at the CNAME's final name. Getting this wrong breaks delivery.
Browsers do not check it. No harm done, but no benefit either. Spend the energy on HSTS instead.
Check whether your zone is DNSSEC-signed, whether your mail server publishes TLSA, and whether the TLSA matches the live cert: scan your domain.