What Is DANE? TLSA Records and DNS-Anchored TLS Explained

DANE (DNS-based Authentication of Named Entities, RFCs 6698/7671) is a mechanism for pinning the expected TLS certificate of a service directly in DNS, protected by DNSSEC. A DNS-anchored PKI alternative to the traditional public CA system.

In practice, DANE lives almost entirely in SMTP: senders and receivers use it to force TLS on inbound mail and to defeat STARTTLS downgrade attacks. Browser support was killed years ago.

The Record — TLSA

DANE data is carried in TLSA records published at a specific DNS name:

_{port}._{protocol}.{hostname}

For SMTP inbound on port 25:

_25._tcp.mx.example.com.  TLSA  3 1 1  A1B2C3D4E5F6...

The four fields:

Prerequisites — DNSSEC

DANE cannot function without DNSSEC. If an attacker can spoof your DNS, they can spoof your TLSA record and defeat the pin.

To deploy DANE:

1. Enable DNSSEC on your zone — publish DNSKEY records, sign records with RRSIG
2. Submit the DS record to your registrar so it lands in the parent zone (.com, .org, etc.)
3. Publish TLSA records for each service
4. Test with a DANE validator

If DNSSEC isn’t practical for your zone, use MTA-STS instead (see below).

SMTP DANE — the Real Use Case

The reason DANE exists in production is SMTP. The STARTTLS problem:

Without DANE, receiving MX servers advertise STARTTLS opportunistically. A sender connects, sees the STARTTLS advertisement, upgrades to TLS. Great.

Problem: an on-path attacker can strip the STARTTLS advertisement from the server’s response. The sender doesn’t see STARTTLS advertised, falls back to plaintext, delivers the message unencrypted. Silent downgrade attack.

With DANE:

• The sender’s MTA looks up TLSA at _25._tcp.{mx-hostname}
• If TLSA is present and DNSSEC validates, TLS is required
• If the cert the MX presents doesn’t hash to the TLSA record, the connection fails closed

No downgrade possible. The sender knows in advance that TLS is required and what cert to expect.

DANE vs MTA-STS

Two ways to solve the same SMTP downgrade problem:

Read the MTA-STS glossary entry for the alternative.

Most modern operators deploy both. Modern Postfix, Exim, and Sendmail support both. The receiver publishes both; the sender uses whichever it validates first.

The Certificate Usage Modes

TLSA field 1 — how to interpret the hash:

For SMTP, 3 1 1 (DANE-EE, SPKI, SHA-256) is the most common — pins the cert’s public key, allows self-signed, resistant to renewals that keep the same key.

Why Browser DANE Died

Chrome removed DANE support in 2015. Firefox never shipped native support. Reasons:

• DNSSEC adoption plateau — only ~30% of recursive resolvers validate, and browser-side validation requires DNSSEC-aware clients that most OSes don’t provide
• Performance cost — DNSSEC + TLSA lookup on every HTTPS handshake adds latency
• Alternatives filled the gap — Certificate Transparency (all certs public), CA/Browser Forum baseline requirements, HSTS Preload

For the browser-facing web, the modern trust anchor is CA + CT logs, not DANE. For SMTP, DANE lives on.

Practical Deployment

If you want to deploy DANE for your inbound SMTP:

1. Enable DNSSEC — talk to your registrar and DNS host. Some (Cloudflare, Route 53, Google DNS) make this a checkbox.
2. Generate TLSA hash — from your cert’s SPKI. openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
3. Publish TLSA record — _25._tcp.mx1.example.com. TLSA 3 1 1 <hash>
4. Test with DomainScan’s TLSA lookup — verify DNSSEC validates and the record is served
5. Update TLSA whenever you rotate the cert — otherwise sender-side DANE validation will fail-closed and mail stops

Tools

• TLSA record lookup — inspect any domain’s DANE records
• DS record lookup — verify the DNSSEC chain of trust anchors properly
• DNSSEC glossary entry — how the chain of trust works

Related

Check the TLSA glossary entry, the DNSSEC entry, and the MTA-STS entry for the DNSSEC-free alternative.