← RFC Reference

DANE — DNS-Based Authentication for SMTP TLS

Why This Exists

SMTP with STARTTLS has two fundamental problems:

1. No authentication. A sending server has no reliable way to verify that the receiving server's TLS certificate is legitimate. SMTP doesn't use the web's CA trust model — historically, most mail servers used self-signed certificates, so senders learned to accept anything.
2. Downgrade attacks. An active network attacker can strip the STARTTLS advertisement from the EHLO response, forcing plaintext delivery.

MTA-STS (RFC 8461) solves these problems using HTTPS and the Web PKI. DANE solves them using DNSSEC and TLSA records. The two approaches are complementary: DANE is cryptographically stronger (no CA trust needed), while MTA-STS is easier to deploy (no DNSSEC required).

How It Works

DANE for SMTP (defined in RFC 7672, building on the base DANE spec in RFC 6698) works in three steps:

Step 1: DNSSEC-Signed Zone

The receiving domain's DNS zone — and the MX target's zone — must be signed with DNSSEC. This is non-negotiable. Without DNSSEC, an attacker could forge TLSA records, making DANE worse than useless.

Step 2: Publish TLSA Records

The domain publishes TLSA records for each MX host's SMTP port. A TLSA record binds a TLS certificate (or its public key, or its CA) to a specific service.

TLSA Record Fields

Step 3: Sender Validates

When a DANE-aware sending server delivers mail to example.com:

1. Resolves MX records for example.com with DNSSEC validation.
2. For each MX host (e.g., mail.example.com), looks up _25._tcp.mail.example.com TLSA with DNSSEC validation.
3. If DNSSEC-validated TLSA records exist: connects, performs STARTTLS, and validates the server certificate against the TLSA data.
4. If validation fails: does not deliver. The message is queued for retry.
5. If no TLSA records exist (or DNSSEC is not deployed): falls back to opportunistic TLS as before.

Key Technical Details

Recommended TLSA Configuration

For SMTP servers, RFC 7672 recommends DANE-EE(3) SPKI(1) SHA-256(1):

This is the most robust choice because:

• Usage 3 (DANE-EE) bypasses CA validation entirely. The certificate doesn't need to be signed by a public CA — self-signed works fine.
• Selector 1 (SPKI) matches the public key, not the full certificate. You can renew your certificate (changing serial number, expiry) without updating the TLSA record, as long as the key pair stays the same.
• Matching type 1 (SHA-256) stores a hash rather than the full key, keeping the DNS record compact.

Generating a TLSA Record

# Extract the SHA-256 hash of the server's public key
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# The resulting TLSA record:
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE vs. MTA-STS

Common Mistakes

• Publishing TLSA without DNSSEC. If your zone is not DNSSEC-signed, TLSA records are ignored. Worse, some implementations may treat unsigned TLSA as a signal to not require TLS, degrading security.
• Forgetting to update TLSA on key rotation. If you use selector 0 (full certificate) and renew your cert with a new key, the TLSA record must be updated before the new cert goes live. Use selector 1 (SPKI) and keep the same key pair across renewals to avoid this.
• TLSA on the domain, not the MX host. The TLSA record goes on the MX target hostname (e.g., _25._tcp.mail.example.com), not on the domain itself. If your MX points to a third-party host, the TLSA record must be in their zone.
• Rolling TLSA records incorrectly. When rotating keys, publish TLSA records for both old and new keys simultaneously. Remove the old record only after the certificate has been rotated and DNS caches have expired.
• Ignoring DNSSEC chain of trust. Every zone in the chain from root to the TLSA record must be DNSSEC-signed. A break anywhere invalidates the entire chain.

Deliverability Impact

• Strongest TLS guarantee. DANE provides cryptographic proof of the server's identity from DNS alone. No CA compromise, no TOFU window — secure from the very first connection.
• Widely deployed in Europe. The Netherlands, Germany, and Czech Republic have high DANE adoption for government and institutional mail. If you deliver to these regions, DANE support is a significant advantage.
• Postfix native support. Postfix has built-in DANE support (smtp_tls_security_level = dane). For senders using Postfix, DANE "just works" when the receiving domain has TLSA records.
• Complementary with MTA-STS. Deploy both. Senders that support DANE will use it (stronger guarantees); senders that only support MTA-STS will use that. Both are better than opportunistic TLS alone.

Related RFCs