DANE for SMTP: Implementation Guide

SMTP is where DANE actually gets enforced in practice — DANE-aware mail servers check TLSA records before delivering mail and refuse to downgrade or accept a mismatched certificate when one is published. This guide walks through the concrete deployment steps, in order, rather than re-explaining what DANE is in general (see What Is DANE? for that).

🔒 Prerequisite: DNSSEC Must Already Be Signed

Before touching TLSA records at all, confirm the mail domain's zone is DNSSEC-signed and validating cleanly. This isn't optional groundwork — a TLSA record on an unsigned zone provides no real protection, since it can be stripped or forged in transit without detection. Check status with our DNSSEC Checker before proceeding to any step below.

1️⃣ Step 1: Identify Your MX Hostnames

TLSA records for SMTP go on the hostname your MX record points to — not the bare sending domain. If example.com's MX record points to mail.example.com, the TLSA record belongs at _25._tcp.mail.example.com. If you have multiple MX hosts (common for redundancy), each one needs its own matching TLSA record.

2️⃣ Step 2: Choose Usage, Selector & Matching Type

For SMTP, the common, operationally practical choice is usage 3 (DANE-EE), selector 1 (SPKI), matching type 1 (SHA-256). This combination pins the certificate's public key directly rather than the whole certificate, meaning a routine renewal on the same key pair doesn't require a DNS update. Usage 1 (PKIX-EE) is a reasonable alternative if you want to keep CA validation as an additional layer, at the cost of slightly more operational complexity.

3️⃣ Step 3: Generate the Certificate Association Data

The association data is a hash of either the full certificate or its public key, depending on the selector chosen. With OpenSSL, extracting the SPKI hash for selector 1 / matching type 1 looks like:

openssl x509 -in mailcert.pem -pubkey -noout | \
openssl pkey -pubin -outform DER | \
openssl dgst -sha256

The resulting hex digest is the fourth field of your TLSA record.

4️⃣ Step 4: Publish the TLSA Record

_25._tcp.mail.example.com.  3600  IN  TLSA  3 1 1 8bf1c86e4a2f...(hex from step 3)

Add this through your DNS provider's normal record-management interface, using TLSA as the record type (some providers require it be added as a raw/custom record if TLSA isn't in their standard type list). Set a TTL that balances propagation speed against query load — 3600 seconds (1 hour) is a reasonable default for most setups.

5️⃣ Step 5: Verify It Resolves Correctly

Once published, confirm the record is visible and correctly formatted using TLSA Lookup against _25._tcp.mail.example.com (adjusting for your actual MX hostname). Cross-check the decoded usage, selector, and matching type match what you intended in Step 2, and that the association data matches what you generated in Step 3.

🔄 Handling Certificate Renewal

With selector 1 (SPKI) and the same key pair reused across renewal, no DNS change is needed when the certificate itself renews — only the certificate's expiry date changes, not its public key. If you rotate to a new key pair (rather than just renewing on the existing one), the TLSA record must be updated before or immediately alongside the certificate switch, or DANE-enforcing senders will reject the mismatch.

🚀 Safe Rollout Strategy

Publish the TLSA record and confirm it resolves correctly for at least a full TTL cycle before treating it as load-bearing. Many organizations keep a second, upcoming-certificate TLSA record alongside the current one during any planned rotation window, removing the old entry only after the new certificate is confirmed live — this avoids a validation gap where DANE-enforcing senders reject mail during the transition.

🧪 Testing Your Setup

Beyond confirming the record resolves, the more meaningful test is whether a DANE-aware sender would actually accept your certificate against it — dedicated SMTP/DANE testing tools exist that simulate this check end-to-end, including DNSSEC chain validation, which a plain DNS lookup alone won't verify.

❌ Common Deployment Mistakes

❓ FAQ

🔗 More Guides