What Is DANE and How It Secures Email Transport

What Is DANE

DANE (DNS-based Authentication of Named Entities) is a security mechanism that allows domain owners to publish TLS certificate information directly in DNS records. It is defined in RFC 6698, with operational guidance in RFC 7671.

DANE addresses a fundamental weakness in the traditional Certificate Authority (CA) model: any CA can issue a certificate for any domain. A domain owner has no control over which CA issues a certificate on their behalf. DANE returns this control — the domain owner declares directly in DNS which certificate is valid for their services.

DANE requires DNSSEC to be active on the domain. Without cryptographically signed DNS responses, an attacker could forge a TLSA record just as easily as the certificate itself.

How DANE Works

DANE introduces a new DNS record type — TLSA (Transport Layer Security Authentication). This record contains a fingerprint (hash) of the server's TLS certificate or public key. A client connecting to the server retrieves the TLSA record from DNS and compares it against the certificate presented during the TLS handshake.

TLSA Record Structure

A TLSA record is published at a specific DNS name that combines the port, protocol, and domain:

_25._tcp.mx.example.com IN TLSA 3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a8d0bdf6d27c4b3b7e6b32

The record has four parameters:

Certificate Usage Modes

For email servers, only values 2 (DANE-TA) and 3 (DANE-EE) are used in practice. Value 3 is the most common — it allows self-signed certificates as long as their fingerprint matches the TLSA record.

Selector and Matching Type

The most common combination for SMTP is 3 1 1 — DANE-EE, public key, SHA-256 hash. This variant survives certificate renewals as long as the same key is reused (e.g., when renewing with Let's Encrypt).

DANE for SMTP

The specific application of DANE to email is defined in RFC 7672 (SMTP Security via Opportunistic DANE TLS). It adds rules for how a sending mail server authenticates the receiving server.

Verification Process

1. The sending server wants to deliver an email to example.com.
2. It queries DNS for the domain's MX records — receiving e.g. mx.example.com.
3. It checks whether the MX response is signed by DNSSEC. If not, TLSA records are not looked up and DANE is not applied — the email is delivered via standard opportunistic STARTTLS.
4. It queries DNS for the TLSA record at _25._tcp.mx.example.com.
5. If the TLSA record exists and is DNSSEC-signed, the server initiates a STARTTLS connection.
6. It compares the receiving server's certificate against the fingerprint in the TLSA record.
7. If the certificate matches, the email is delivered encrypted. If not, the server tries the next MX host. If all fail verification, delivery is deferred (temporary failure with retries).

The key difference from opportunistic STARTTLS: when a receiving domain publishes a TLSA record, the sending server must use TLS and must verify the certificate. No downgrade to plaintext is allowed.

Protection Against Attacks

DANE for SMTP protects against two primary threats:

• Downgrade attack: an attacker suppresses the STARTTLS response, forcing plaintext transmission. DANE prevents this — if a TLSA record exists, TLS is mandatory.
• Man-in-the-Middle (MITM) attack: an attacker presents their own certificate to intercept communication. DANE blocks this — the certificate must match the fingerprint in DNS, which is protected by DNSSEC.

DANE vs. MTA-STS

MTA-STS (RFC 8461) solves the same problem as DANE — enforcing encrypted email transport. The two protocols differ in approach.

DANE is technically more robust — it verifies certificates directly via DNS without relying on the CA trust model. MTA-STS is more pragmatic — it does not require DNSSEC, making it deployable by virtually anyone.

The two protocols are not mutually exclusive. A sending server that supports both prefers DANE (when DNSSEC and TLSA records are available) and falls back to MTA-STS. For a detailed MTA-STS deployment guide, see MTA-STS and TLS-RPT — Securing Email Transport.

How to Deploy DANE for Your Email Server

Prerequisites

• Your domain has active DNSSEC with a working chain of trust
• Your mail server supports TLS (STARTTLS)
• Your DNS hosting allows publishing TLSA records

1. Verify DNSSEC

Check your domain — the analyzer will verify DNSSEC status. Alternatively, in the terminal:

dig example.com DNSKEY +short

If the command returns no keys, activate DNSSEC first.

2. Generate the Certificate Fingerprint

For DANE-EE (usage=3) with a SHA-256 hash of the public key (selector=1, matching-type=1):

openssl s_client -starttls smtp -connect mx.example.com:25 < /dev/null 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -hex

The output includes a (stdin)= prefix followed by the hex hash. Copy only the hex portion — that is the value for your TLSA record.

3. Publish the TLSA Record

Add a DNS record for each MX server:

_25._tcp.mx.example.com IN TLSA 3 1 1 b2a7d4f1e8c3960573bfa21de8045c9ab0e1f7d3c8264a95e0d4127bf3c68e51

4. Verify the Configuration

Test the TLSA record via DNS lookup or in the terminal:

dig _25._tcp.mx.example.com TLSA +short

5. Enable TLS-RPT

For visibility into TLS connection status, add a TLS-RPT record. Sending servers will report on successful and failed TLS connections:

_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=mailto:example.com@rua.spfmonitor.com"

Managing TLSA Records During Certificate Renewal

The most common operational issue with DANE is a mismatch between the TLSA record and the certificate after renewal. If the server presents a new certificate but the TLSA record still references the old one, DANE-capable sending servers will defer delivery.

Strategies for Seamless Renewal

Option A — Reuse the key: When renewing the certificate, use the same private key (CSR with the same key). If the TLSA record references the public key (selector=1), it remains valid after the certificate swap. This is the recommended approach for DANE with parameters 3 1 1.

Option B — Pre-publish the new TLSA record: Before swapping the certificate, add a second TLSA record with the new certificate/key fingerprint. After the swap, remove the old TLSA record. Two TLSA records exist temporarily in DNS:

_25._tcp.mx.example.com IN TLSA 3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a8d0bdf6d27c4b3b7e6b32
_25._tcp.mx.example.com IN TLSA 3 1 1 4f7c91e85a14d3a9bc831f2c05e47190dae1bc83a7b6f4e028350712b4c9f3a1

With option B, account for DNS propagation time (TTL) — the new record must be available before the certificate swap occurs.

Who Supports DANE

On the Receiving Side (Your Domain)

You can deploy DANE on any domain that meets the prerequisites: DNSSEC, TLS on the mail server, and TLSA records in DNS. Deployment depends on your DNS provider — not all support publishing TLSA records.

On the Sending Side (Who Validates Your TLSA Records)

• Postfix — native DANE support since version 2.11 (2014)
• Exim — DANE support since version 4.91
• Google (Gmail) — does not support DANE, relies on MTA-STS

On the Receiving Side (Who Publishes TLSA Records)

• Microsoft Exchange Online — inbound DANE support since 2024 (domains hosted on Exchange Online can publish TLSA records)
• Any mail server with TLS and DNSSEC on the domain

DANE adoption is strongest in Europe, particularly in Germany, the Netherlands, and the Czech Republic, where DNSSEC deployment is high. Google, the largest email sender, relies exclusively on MTA-STS.

DANE as Part of Domain Security

DANE complements the SPF, DKIM, and DMARC trio by adding a transport security layer. While authentication protocols verify who sent the email, DANE ensures the message content cannot be read or modified in transit — and that the recipient is communicating with the real server, not an impostor.

Check your domain's security — the analyzer verifies SPF, DKIM, DMARC, and DNSSEC in one go and shows where the gaps are.