DANE for Email: How to Set Up DNS-Based TLS Authentication

SPF, DKIM, and DMARC prove the message came from you. They say nothing about whether someone is sitting between your server and the recipient's. STARTTLS encrypts the channel, but it can be silently stripped. DANE is what prevents that.

The problem: STARTTLS without guarantees

When one mail server connects to another over SMTP, it can offer encryption via STARTTLS. The receiving server responds and presents its TLS certificate. The SMTP client typically doesn't check who that certificate was issued to — it accepts anything: self-signed, expired, issued to the wrong domain. There is encryption, but no authentication.

Worse: an attacker on the path between servers can remove the 250-STARTTLS line from the server response. The sending MTA concludes the recipient doesn't support encryption and sends plain text. This is STARTTLS stripping, and it has been observed in real networks, not just in threat models.

What DANE is and how it fixes the problem

DANE (DNS-Based Authentication of Named Entities) is RFC 6698, with the SMTP profile in RFC 7672. The idea: publish a fingerprint of your mail server's TLS certificate in DNS. That record is called TLSA. When a sending MTA looks up your MX, it also fetches the TLSA record, opens the TLS connection, and compares the certificate it receives against what DNS says it should be.

If the certificate doesn't match, the connection is dropped. If a TLSA record exists but the server doesn't offer STARTTLS, the message is not sent. No silent fallback to plaintext, no accepting a stranger's certificate.

One hard requirement: DANE only works over DNSSEC. Without a cryptographic signature on the zone, an attacker could replace the TLSA record itself. DNSSEC guarantees DNS data integrity; DANE uses that data to authenticate TLS.

Anatomy of a TLSA record

TLSA records live at a specific DNS name. For mail server mail.example.com on port 25:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 2bb183af2049...full_sha256_hash

The four numeric fields after TLSA define what is being checked and how.

Certificate Usage (first field)

• 0 (PKIX-TA) — certificate must be signed by the specified CA and pass standard chain validation.
• 1 (PKIX-EE) — a specific end-entity certificate, plus standard CA chain validation.
• 2 (DANE-TA) — trust the specified CA without requiring a globally trusted root. An internal CA works here.
• 3 (DANE-EE) — pin a specific certificate directly. No chain validation, no CA involvement. The standard choice for SMTP.

RFC 7672 recommends 3 (DANE-EE) for mail servers: with usage 3, hostname validation is not required and no CA chain is needed. This works well with Let's Encrypt, where certificates renew every 60–90 days. Pin the public key (selector 1) rather than the full certificate and you won't need to update DNS on every renewal.

Selector (second field)

• 0 — hash computed over the full certificate (DER).
• 1 — hash computed over the public key (SubjectPublicKeyInfo). If the certificate renews with the same key, the TLSA record stays valid.

Matching Type (third field)

• 0 — full content, no hashing. Long and impractical.
• 1 — SHA-256. The standard choice.
• 2 — SHA-512. Valid, but SHA-256 is sufficient and more compatible.

The recommended combination for SMTP is 3 1 1 — DANE-EE, public key, SHA-256. It survives certificate renewals without DNS changes and has no dependency on external CAs.

Step-by-step DANE setup

Step 1. Confirm DNSSEC is active

DANE without DNSSEC is invisible to conforming senders. Check whether your zone is signed:

dig +dnssec example.com A +short

If the response carries the ad (Authenticated Data) flag, the zone is signed and being validated. For a fuller check:

dig +dnssec +multi example.com SOA
# RRSIG records should appear in the answer
# Look for "ad" in the flags section

Most major registrars (Cloudflare, Route53, Hetzner DNS) enable DNSSEC in a few clicks. On a self-hosted DNS server you need to generate KSK/ZSK keys and publish a DS record with your registrar. That is a separate topic, but there is no point in proceeding without it.

Step 2. Configure TLS on the mail server

Your MTA must offer STARTTLS with a valid certificate. For Postfix in main.cf:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2

The value may means TLS is offered but not required — the right setting for inbound SMTP on port 25. DANE operates on the sender's side; it is the sending MTA that decides whether to trust the certificate by checking TLSA.

Step 3. Generate the hash for the TLSA record

For a 3 1 1 record you need the SHA-256 hash of the public key from the certificate:

openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem \
  -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 32

The output is 64 hex characters, for example:

2bb183af20492e69e42f5a83e91cf269c1837f2638898c1e045297b72a27bc4d

You can also use the tlsa utility from the hash-slinger package:

apt install hash-slinger

tlsa --create --selector 1 --mtype 1 \
  --certificate /etc/letsencrypt/live/mail.example.com/cert.pem \
  mail.example.com

Step 4. Publish the TLSA record in DNS

If your MX points to mail.example.com, the TLSA record for port 25 is:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 (
  2bb183af20492e69e42f5a83e91cf269
  c1837f2638898c1e045297b72a27bc4d )

The record name is built from the MX hostname, not the base domain. If MX points to mx1.example.com, the record goes at _25._tcp.mx1.example.com. Publishing TLSA under the base domain when your MX points elsewhere is the most common configuration mistake.

Step 5. Verify

dig TLSA _25._tcp.mail.example.com +short
dig +dnssec TLSA _25._tcp.mail.example.com
dig MX example.com +short
dig A mail.example.com +short
dig +dnssec _25._tcp.mail.example.com TLSA | grep -c RRSIG

The last command should return 1 or more — an RRSIG signature is present. If it returns 0, DNSSEC is not working for this record and DANE validation from senders will be ignored.

For external checks use check.sidnlabs.nl/dane or dane.sys4.de. Both test TLSA, DNSSEC, and the actual TLS connection to your MX.

Certificate rotation without downtime

With 3 1 1 (public key hash), renewing the certificate with the same key requires no DNS changes. Certbot keeps the key by default on renewal, so most of the time this section doesn't apply.

When the key does change (forced rotation, algorithm change, or compromise):

1. Generate the new key and obtain a new certificate.
2. Compute the hash of the new public key.
3. Add a second TLSA record with the new hash. Leave the old one in place.
4. Wait for the old record's TTL to expire and the new one to propagate (typically 1–24 hours).
5. Switch the server to the new certificate.
6. After one TTL period, remove the old TLSA record.

Two TLSA records at the same name is entirely normal. The RFC allows multiple records; a sending MTA considers validation passed if at least one matches.

; Old key (active certificate)
_25._tcp.mail.example.com.  IN  TLSA  3 1 1 2bb183af2049...old_hash

; New key (upcoming certificate)
_25._tcp.mail.example.com.  IN  TLSA  3 1 1 a1b2c3d4e5f6...new_hash

DANE vs MTA-STS: which to use

MTA-STS (RFC 8461) solves the same problem through HTTPS. The policy is published at .well-known/mta-sts.txt; a DNS TXT record just signals that it exists.

• DANE requires DNSSEC. MTA-STS does not. If your domain lacks DNSSEC, MTA-STS is the only option available right now.
• DANE pins a specific key or certificate. MTA-STS relies on WebPKI (standard CAs). DANE is stricter.
• MTA-STS uses TOFU (Trust On First Use) — the very first connection is unprotected. DANE protects from the first connection because the data is DNSSEC-signed.
• Postfix supports DANE out of the box. Gmail validates both. Outlook validates MTA-STS on outbound, but DANE support on the sending side is not fully implemented as of 2026.

If you can configure both, do it. They don't conflict. MTA-STS covers senders that don't check DANE; DANE gives stronger guarantees for those that do.

Bonus: outbound DANE validation in Postfix

Everything above covers publishing TLSA so incoming mail is protected. Postfix can also validate DANE when it sends:

# main.cf — enable DANE validation on outbound
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

With these settings, Postfix looks up the TLSA record for the recipient's MX on each outbound delivery. If a DNSSEC-signed record is found, it proceeds only with a matching certificate. No TLSA record means opportunistic TLS, no lost compatibility.

You need a local DNSSEC-validating resolver. Unbound or systemd-resolved with DNSSEC enabled both work. Verify the AD flag:

dig +dnssec example.com @127.0.0.1 | grep flags
# Look for "ad" in the flags list

Common DANE configuration mistakes

• TLSA without DNSSEC. The record is there, but the zone is unsigned. Senders implementing DANE per RFC will ignore it. Verify DNSSEC before publishing TLSA.
• TLSA pinned to the full certificate (selector 0) with Let's Encrypt. Certificates renew every 60–90 days. If the TLSA hash matches the old certificate, DANE validation fails after renewal. Use selector 1 (public key) or automate DNS updates.
• TLSA at the domain name instead of the MX hostname. A record at _25._tcp.example.com won't be found if MX points to mail.example.com. The correct name is _25._tcp.mail.example.com.
• Forgetting to update TLSA after a key change. New certificate, new key, old hash in DNS. Inbound DANE checks fail, which means lost messages from senders with strict DANE policies.
• TTL set too low on the TLSA record. DANE behaves more reliably with a TTL of at least one hour. Caching reduces exposure to transient DNS problems.

Who already uses DANE

In Europe, DANE for email is close to a standard. The Netherlands, Germany, and the Czech Republic lead on adoption. German providers (mail.de, posteo.de, mailbox.org) validate DANE on outbound and publish TLSA for inbound. Dutch government domains are required to support DANE under the "Comply or Explain" standard. Gmail has validated DANE on outbound since 2015. Comcast does too.

If your server receives mail from Gmail, Postfix servers with DANE configured, or European organizations, having a TLSA record improves the security of those connections today.