DANE/TLSA troubleshooting: diagnose and fix common errors

You deployed DANE/TLSA on your mail server following best practices, everything was working, then one day emails start getting rejected by certain recipients. The error message mentions "failed DANE validation" or "TLSA record not found", but the logs don't tell you exactly what changed.

DANE doesn't fail because the protocol is complex. It fails because four independent systems must stay in sync at all times. DNSSEC, TLS certificate, TLSA record, MTA configuration: a single broken link is enough to break the entire chain. And the breakage almost always happens silently, weeks after deployment, when a certificate renews or a key rotates.

So how do you pinpoint the exact cause when something goes wrong? This guide covers the 5 most common DANE/TLSA errors, each with the symptom, diagnostic commands and the fix. It's intended for system administrators and DevOps who already have a working DANE setup. If you haven't deployed DANE yet, start with the first article in this series (see "Related guides" at the bottom of this page).

The 5 most common DANE errors

In practice, nearly every DANE failure traces back to one of 5 root causes. Each section below describes the observable symptom, the diagnostic command and the fix. Work through them in order: the most frequent causes come first.

Error 1: unsigned DNSSEC or expired signature

Symptom: sending servers report "DANE required but not available" or "no DNSSEC" in TLS-RPT reports. Emails are delivered in opportunistic mode (without DANE verification) or rejected. DNSSEC is the foundation that everything else rests on. If it breaks, your entire DANE setup becomes invisible.

Diagnosis:

# Check the AD (Authenticated Data) flag
dig +dnssec MX captaindns.com | grep flags
# Expected result: flags: qr rd ra ad

# Check RRSIG signature validity
dig +dnssec SOA captaindns.com | grep RRSIG
# The expiration date is in the RRSIG field

Common causes:

• The registrar disabled DNSSEC after a domain transfer
• DNSSEC keys (KSK/ZSK) expired without automatic rotation
• The DS record at the registrar no longer matches the active DNSKEY

Fix: verify that the DS record at your registrar matches your DNSKEY. If you use Bind9, check key expiration dates with dnssec-settime and configure automatic rotation.

Error 2: outdated TLSA hash after certificate renewal

Symptom: "TLSA validation failed" or "certificate mismatch" in the logs. This is the number one cause of DANE failures in production. It typically strikes 60 to 90 days after the initial deployment, exactly when the first Let's Encrypt renewal fires. Everything worked for weeks, so most admins don't suspect the certificate.

Diagnosis:

# Hash of the active certificate (selector 0: Full cert)
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -outform DER \
  | openssl dgst -sha256

# Hash published in DNS
dig TLSA _25._tcp.mail.captaindns.com +short
# Compare the 64 hexadecimal characters

Common causes:

• The Certbot renewal hook doesn't update the TLSA
• The selector is Full (0) instead of SPKI (1): each renewal changes the hash
• The usage is DANE-EE (3) without --reuse-key in Certbot

Fix:

• Quick fix: generate the new hash with our DANE TLSA Generator and update the DNS
• Long-term fix: use SPKI selector (1) with --reuse-key in Certbot, or switch to DANE-TA (2) with the Let's Encrypt CA certificate. See our Postfix/Bind/Let's Encrypt tutorial (article 2 in this series) for the automatic renewal hook configuration

Error 3: TLSA published at the wrong DNS name

Symptom: "no TLSA records found" even though you did create the record. This is the most common error among DANE beginners, and the most frustrating, because the record exists, just not where sending servers look for it.

Diagnosis:

# Find the MX hostname
dig MX captaindns.com +short
# Result: 10 mail.captaindns.com.

# Check the TLSA at the correct location (MX hostname)
dig TLSA _25._tcp.mail.captaindns.com +short

# Typical mistake: TLSA published on the domain instead of the MX
dig TLSA _25._tcp.captaindns.com +short
# This TLSA is IGNORED by sending servers

Cause: confusion between the domain (captaindns.com) and the MX hostname (mail.captaindns.com). The TLSA must be published at _25._tcp.<MX-hostname>, as specified in RFC 7672 section 2.1.1.

Fix: publish the TLSA at _25._tcp.mail.captaindns.com (or whatever hostname your MX record returns). If your domain has multiple MX records, each hostname needs its own TLSA.

Error 4: STARTTLS unavailable or misconfigured

Symptom: DANE is configured on the DNS side but the server doesn't offer STARTTLS, or the presented certificate doesn't match the hostname. Logs show "TLS handshake failed" or "certificate hostname mismatch". DNS tells the world you support DANE, but your server can't deliver on that promise.

Diagnosis:

# Test if STARTTLS is offered
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Check the Common Name and SANs of the certificate
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Common causes:

• smtpd_tls_cert_file points to the wrong file in Postfix
• The certificate doesn't include the MX hostname in its Subject Alternative Names
• The firewall blocks STARTTLS or port 25 is not accessible over TLS

Fix: in Postfix, verify that smtpd_tls_security_level is at least may and that the certificate paths are correct:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

Error 5: incomplete DNS propagation

Symptom: DANE works intermittently. Some sending servers validate the TLSA, others report an error. Intermittent failures are the hardest to diagnose because the problem depends on which resolver the sender queries. The issue often appears after a recent DNS update.

Diagnosis:

# Compare responses between NS servers
dig TLSA _25._tcp.mail.captaindns.com @ns1.captaindns.com +short
dig TLSA _25._tcp.mail.captaindns.com @ns2.captaindns.com +short

# Check the remaining TTL
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Common causes:

• Incomplete zone transfer between primary and secondary DNS servers
• High TTL on the old record (DNS caches retain the old value)
• A NS server is unresponsive or returns an outdated version of the zone

Fix: verify that all your NS servers return the same TLSA value. If you just updated the TLSA, wait for the previous TTL to expire before removing the old record. For certificate rotations, publish the new TLSA 2x TTL before the actual rotation.

Monitoring DANE in production

Fixing a one-off error isn't enough. DANE is a living system: certificates rotate, keys expire, DNS zones get updated. Without monitoring, the next failure is just a renewal cycle away. The following 3 monitoring mechanisms prevent recurring incidents.

TLS-RPT: enable TLS-RPT reports (RFC 8460) to receive DANE failure notifications from sending servers. The failure-type field in the JSON report indicates the exact error type:

Certificate monitoring: set up an alert 14 days before TLS certificate expiration. Automatic renewal doesn't mean automatic DANE compliance. Let's Encrypt renews the certificate, but the TLSA hook can fail silently, leaving DNS and the server out of sync.

Automated verification: schedule a daily check with our DANE TLSA Syntax Checker or a cron script that compares the published hash to the active certificate:

#!/bin/bash
# Daily DANE verification
TLSA_HASH=$(dig TLSA _25._tcp.mail.captaindns.com +short | awk '{print $4}')
CERT_HASH=$(openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 | awk '{print $2}')

if [ "$TLSA_HASH" != "$CERT_HASH" ]; then
  echo "ALERT: TLSA hash differs from the active certificate" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Recommended action plan

1. Diagnose: use the 5-step methodology above or our DANE TLSA Checker to identify the problem
2. Identify: classify the error into one of the 5 categories (DNSSEC, hash, DNS name, STARTTLS, propagation)
3. Fix: apply the corresponding solution using the provided commands
4. Verify: test the fix with dig +dnssec and openssl s_client before considering the issue resolved
5. Prevent: set up TLS-RPT, certificate monitoring and automated verification

📚 Related DANE/TLSA guides

• DANE/TLSA: the complete guide to authenticating email certificates via DNS: how it works, TLSA anatomy, recommended usages and comparison with MTA-STS
• Set up DANE/TLSA with Postfix, Bind and Let's Encrypt: step-by-step tutorial with copy-paste commands, renewal automation and verification
• Deploy DANE for Exchange Online and Microsoft 365

Sources

• RFC 7672 - SMTP Security via Opportunistic DANE TLS
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• Postfix TLS README - DANE
• ISC BIND 9 DNSSEC Guide