DNS Security
DANE for Email
DANE lets sending mail servers verify recipient TLS certificates with DNSSEC-protected TLSA records. It strengthens transport authenticity between MTAs.
How DANE works
For SMTP, TLSA records are published at names like _25._tcp.mx1.example.com. A sending mail server that supports DANE looks up the TLSA record for the MX host it is about to connect to. If the record is DNSSEC-validated, the sender requires STARTTLS and checks that the server's certificate or public key matches the record before it hands over the message (RFC 7672).
Prerequisites and records
DANE depends on DNSSEC, and the three DNSSEC states lead to different results:
| State of the MX host's zone | What a DANE-aware sender does |
|---|---|
| Signed and valid, TLSA present | Requires TLS and a certificate that matches the TLSA record; otherwise it defers delivery |
| Signed and valid, no TLSA record (validated as absent) | No DANE; ordinary opportunistic TLS |
| Unsigned (insecure) | Ignores any TLSA record, because it cannot be trusted; ordinary opportunistic TLS |
| Bogus (DNSSEC fails to validate) | Cannot resolve the MX host or its TLSA record safely, so mail is delayed rather than sent without protection |
A TLSA record for SMTP usually looks like the example below. The digest is shortened here and will not work if copied; a real SHA-256 digest is 64 hex characters.
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 9A1B...F0C2- Sign the zone and verify the DNSSEC chain end-to-end.
- Publish TLSA for each MX host serving inbound SMTP, at the MX host's own name.
- Prefer usage 3 (DANE-EE) with selector 1 (the public key) and matching type 1 (SHA-256), written 3 1 1. Usage 3 pins the server's own key, so it works with a self-signed certificate and no public CA is involved. Usage 2 (DANE-TA) pins a CA you choose instead.
- Rotate keys by publishing the new TLSA record alongside the old one, waiting at least the TLSA TTL, and only then switching the certificate. Removing the old record comes last.
FAQ
Can DANE replace PKI completely?
For SMTP it can: with usage 3 a sender trusts the key pinned in DNS and does not need a public CA. Senders without DANE support still rely on ordinary TLS, so many operators also keep a publicly trusted certificate.
Is DANE the same as MTA-STS?
No. Both aim to improve SMTP TLS security, but use different trust and policy mechanisms.