DANE/TLSA: How to Secure Email with DNS-Based Certificate Authentication

What Is DANE?

DANE (DNS-Based Authentication of Named Entities) is defined in RFC 6698, with operational guidance in RFC 7671 and SMTP-specific usage in RFC 7672. It allows you to publish your mail server's TLS certificate information directly in DNS, cryptographically binding the certificate to the domain via DNSSEC.

Without DANE, SMTP TLS is opportunistic — a sending server has no way to verify that the certificate presented by your mail server is legitimate. An attacker performing a man-in-the-middle attack can present a fraudulent certificate, and the sender has no basis to reject it.

DANE solves this by publishing a TLSA record in DNSSEC-signed DNS. Sending servers that support DANE can look up this record and verify that the certificate presented during the TLS handshake matches what's published in DNS. If it doesn't match, the sender refuses to deliver.

DANE vs MTA-STS: Both prevent TLS downgrade attacks, but they use different trust anchors. MTA-STS relies on WebPKI (HTTPS certificate authorities). DANE relies on DNSSEC. They complement each other — deploy both if possible, since not all senders support both.

Prerequisites

DNSSEC is a hard requirement. DANE without DNSSEC provides no security — an attacker who can tamper with DNS responses can simply forge or remove the TLSA record. Without DNSSEC validation, the TLSA record is meaningless.

Before setting up DANE, you must:

1. Enable DNSSEC on your domain. This is done at your DNS provider/registrar. The zone must be signed, and DS records must be published in the parent zone.
2. Enable DNSSEC on the MX hostname's zone. If your MX points to mail.example.com, the example.com zone must be DNSSEC-signed. If your MX is in a different zone (e.g., mail.hosting.net), that zone must also be signed.
3. Verify DNSSEC is working. Use dig +dnssec example.com A and confirm you see ad (Authenticated Data) flag, or use DNSViz to visualize your DNSSEC chain.

Your mail server must also have a valid TLS certificate (self-signed is acceptable with DANE-EE usage type, since trust comes from DNS rather than a CA).

TLSA Record Format

A TLSA record is published at _port._protocol.hostname. For email (SMTP on port 25):

_25._tcp.mail.example.com. IN TLSA <usage> <selector> <matching-type> <certificate-data>

Usage Field

Selector Field

Matching Type Field

Recommended Configuration: 3 1 1

For mail servers, the standard recommendation is Usage 3, Selector 1, Matching Type 1 (DANE-EE with SPKI SHA-256):

• Usage 3 (DANE-EE): No dependency on certificate authorities. Works with self-signed certs and Let's Encrypt alike.
• Selector 1 (SPKI): Matches the public key only. This means you can renew your certificate (even change CAs) without updating the TLSA record, as long as you reuse the same private key.
• Matching Type 1 (SHA-256): Standard hash, compact and widely supported.

Generate Your TLSA Record

From a Live Server

Connect to your mail server and extract the certificate, then hash the SPKI:

# Get the certificate from your mail server
openssl s_client -connect mail.example.com:25 -starttls smtp < /dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 64

This outputs a hex string like:

a]29b3e4f7c8d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6

From a Certificate File

If you have the certificate file (PEM format):

# For selector 1 (SPKI) + matching type 1 (SHA-256):
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 64

From a Private Key (for pre-publication)

If you want to publish the TLSA record before deploying the certificate (useful for key rollovers):

# Extract SPKI hash from private key:
openssl pkey -in /etc/letsencrypt/live/mail.example.com/privkey.pem -pubout -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 64

Assemble the Record

Combine the fields into the full TLSA record:

_25._tcp.mail.example.com. IN TLSA 3 1 1 a29b3e4f7c8d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6

Publishing the Record

Add the TLSA record to your DNS zone. The record name must match your MX hostname exactly:

1. Find your MX records: dig MX example.com — e.g., mail.example.com
2. Publish the TLSA record at _25._tcp.mail.example.com
3. If you have multiple MX hosts, publish a TLSA record for each one

DNS Provider Examples

BIND zone file:

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 (
    a29b3e4f7c8d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5
    a6b7c8d9e0f1a2b3c4d5e6 )

Cloudflare / web panel: Create a TLSA record with:

• Name: _25._tcp.mail
• Usage: 3
• Selector: 1
• Matching Type: 1
• Certificate data: (your hex hash)

Important: After publishing, wait for DNS propagation and verify DNSSEC signatures are intact before relying on the record.

Testing & Verification

After publishing your TLSA record, verify the full chain:

1. Verify DNSSEC

# Check DNSSEC validation on the TLSA record itself:
dig +dnssec TLSA _25._tcp.mail.example.com

# Look for the 'ad' flag in the response header

2. Verify the TLSA Record Resolves

dig TLSA _25._tcp.mail.example.com +short
# Should output: 3 1 1 A29B3E4F7C8D1E2F3...

3. Test DANE Validation (Postfix)

# If you have Postfix installed:
posttls-finger -c -l dane mail.example.com

4. Online Tools

• DANE SMTP Validator (sys4.de) — tests DANE for mail servers
• SIDN DANE Test — comprehensive DANE checker
• Huque DANE Check — validates TLSA records

Use our Domain Security Scanner to automatically check your DANE/TLSA configuration alongside other email security settings.

Common Mistakes

1. No DNSSEC

The most common mistake. Publishing a TLSA record without DNSSEC provides zero security. An attacker who can modify DNS responses will simply remove or replace the TLSA record. Always verify DNSSEC is fully deployed and validated before publishing TLSA records.

2. Wrong Usage Field

Using Usage 0 or 1 (PKIX-TA/PKIX-EE) requires the certificate to pass traditional CA validation in addition to matching the TLSA record. If you use Let's Encrypt or any CA that might change intermediates, this can break unexpectedly. Use Usage 3 (DANE-EE) for mail servers unless you have a specific reason not to.

3. Certificate Rotation Breaks DANE

If you use Selector 0 (full certificate) or generate a new key pair on each renewal, the TLSA record becomes invalid every time you renew. Solutions:

• Use Selector 1 (SPKI) and reuse the same private key across renewals.
• Pre-publish the next TLSA record before rotating keys (publish both old and new records during the transition).
• Automate TLSA updates as part of your certificate renewal process.

4. TLSA Record on Wrong Hostname

The TLSA record must be at _25._tcp.<mx-host>, not _25._tcp.<domain>. If your MX record for example.com points to mail.example.com, the TLSA record goes at _25._tcp.mail.example.com.

5. Forgetting Additional MX Hosts

If you have multiple MX records (e.g., primary and backup), each MX hostname needs its own TLSA record. A missing TLSA record on a backup MX can cause delivery failures when senders try that host.

6. Stale TLSA Records After Key Change

If you regenerate your private key (new key pair) without updating the TLSA record, DANE-aware senders will reject your server. Plan key rollovers carefully:

1. Generate the new key and compute its SPKI hash
2. Publish both old and new TLSA records
3. Wait for DNS TTL to expire
4. Deploy the new certificate
5. Remove the old TLSA record after confirming the new one works