What it is
DANE publishes the expected certificate or public key of each MX host as a TLSA record at _25._tcp.mx.example.com. Because the record is signed with DNSSEC, a sending server can trust it and must use TLS with a matching certificate.
Why it matters
It closes the same downgrade gap as MTA-STS, but through DNS instead of a web server, and it does not depend on a sender trusting every public CA. Several mailbox providers and governments validate it by default.
How to implement
Each MX host must already offer STARTTLS. Sign both the domain and the MX host’s zone with DNSSEC. Publish a 3 1 1 TLSA record (SHA-256 of the server’s public key) for each MX, or 2 1 1 for the issuing CA. Before a key or certificate changes, publish the new record next to the old one and wait at least the record’s TTL before switching.
Common mistakes
- Publishing TLSA records in a zone that is not DNSSEC-signed, so nobody can use them.
- Rotating the key before the new TLSA record is published, which makes compliant senders stop delivering.
- Pinning a
3 1 1record to a certificate whose key changes on every automatic renewal. - Forgetting MX hosts run by another provider, who must publish their own records.
Verification
Query the TLSA records with a validating resolver, check that the DNSSEC chain is intact, and compare the hash with each MX’s certificate after STARTTLS. Read TLS reports for tlsa-invalid or dnssec-invalid failures.