What is DANE?

The record type is TLSA, published at _25._tcp.mail.yourdomain.com, and it carries a hash of the certificate or of the key that signed it.

A sending server that supports DANE looks it up, requires TLS, and checks the presented certificate against the hash. A mismatch means no delivery, with no fallback available.

The operational hazard is renewal. Rotate a certificate without publishing the new TLSA record first and mail stops arriving, which is why the rollover is staged with both hashes published.

Adoption is uneven and regional. It is widespread in the Netherlands, Germany and the Czech Republic and among large providers; MTA-STS is the more common choice elsewhere because it needs no DNSSEC.

Say Acme's mail is handled by mx1.acme.example. The DANE record sits at _25._tcp.mx1.acme.example, under the MX hostname and not the mail domain, and looks like TLSA 3 1 1 followed by 64 hexadecimal characters.

Those three numbers carry the policy. First comes the usage, and 3 means match the server's own certificate directly, with no certificate authority involved. Next is the selector, where 1 means match the public key alone instead of the whole certificate. Last is the matching type, and 1 says the data that follows is a SHA-256 hash.

That middle field has a practical payoff. Because 3 1 1 pins the key, you can renew the certificate as often as you like without touching DNS, as long as the renewal reuses the same key pair. You only need the staged two-record rollover when the key itself changes.

To check a live record, run dig +dnssec TLSA _25._tcp.mx1.acme.example. Look for the ad flag in the header, which means your resolver validated the signatures.

DANE's own failure mode is narrow: a wrong hash stops mail from DANE-aware senders. The dependency underneath it fails wider. If your zone's DNSSEC signatures expire because a signing job stopped, validating resolvers treat your whole domain as bogus and return errors for every lookup. Your website and all inbound mail go down with it, DANE or not.

So before you publish TLSA records, make sure signing is automated and that something alerts you when a signature is within a few days of expiry.

Two zones have to be signed for DANE to work. The sender needs a validated answer for your MX record, which comes from your domain's zone, and for the TLSA record, which lives in the zone of the MX host. If a third party hosts your mail, their zone has to be signed and they have to publish the TLSA record. No amount of work on your side can substitute for that.