TLS for mail: DANE (TLSA) and DNSSEC in practice
How DANE/TLSA and DNSSEC fit into transport security for services like Postfix.
Summary
DANE stores TLS fingerprints in DNSSEC-signed records so MTAs can authenticate remote servers without relying solely on WebPKI trust anchors. When it works, it removes the downgrade gap between opportunistic and mandatory TLS.
Record planning
TLSA records live under _port._tcp.service.example. For SMTP, publish _25._tcp.mail.example.org TLSA 3 1 1 style entries with SHA-256 hashes of the certificate or public key. Every record must sit inside a DNSSEC signed zone, so plan for key rollovers and monitoring.
Postfix behavior
With smtp_tls_security_level = dane, Postfix validates TLSA responses and refuses delivery if the record does not match the presented certificate. Logging reveals whether the TLSA RRset was unsigned, missing, or failed verification. Always test with delv or dnssec-trigger to confirm the chain of trust.
Operational safeguards
Automate TLSA regeneration whenever certificates rotate. Keep an unsigned fallback MX so critical senders without DNSSEC support can still reach you if necessary. For an overview of cipher choices, continue with the TLS cipher suite explainer.
Further reading (German)
Keywords
DANE, TLSA, DNSSEC, Postfix, TLS