Set Up DANE — TLSA Records for Your Mail Server

Prerequisite: DNSSEC

DANE stands or falls with DNSSEC. Without a signed zone a sending server cannot trust the TLSA record, and the whole mechanism is not half effective but ineffective. What must be signed is the zone holding the MX hostnames, which is not necessarily the sender domain's zone.

Check that before creating anything:

If that yields 0 the zone is unsigned and DANE is not yet on the table. MTA-STS is then the fitting mechanism, because it works without DNSSEC.

The record

The TLSA record hangs off the port and the MX hostname, not the domain:

The three numbers are usage, selector and matching type. For SMTP 3 1 1 is the right choice and practically the only one to use:

• 3 — the certificate itself is the anchor. No public CA has to endorse it, so DANE works with a self-issued certificate too.
• 1 — what is bound is the public key, not the whole certificate. That is the decisive difference: a renewal with the same key leaves the record valid.
• 1 — SHA-256 as the digest.

The value comes straight out of the certificate:

Rollover — the actual sticking point

A TLSA record that no longer matches the served certificate makes validating senders refuse delivery entirely. Which is exactly why every renewal follows this pattern:

1. Publish the new record alongside while the old certificate is still live. Two TLSA records at the same name are allowed; a sender accepts whatever matches either.
2. Wait out the TTL — at least one full TTL, so resolvers holding old answers also learn the new record.
3. Swap the certificate and reload the service.
4. Remove the old record, no earlier than another TTL later.

The simpler route: keep the key at renewal. The fingerprint then stays the same and the record never needs touching. With Let's Encrypt that means a fixed key file rather than a fresh key per renewal.

What happens on failure

Without DANE a sending server falls back to unencrypted delivery on a certificate problem — the mail arrives. With a published TLSA record that fallback is forbidden: the far side aborts and queues the message until things match again. That is the point of the mechanism and simultaneously its risk.

DANE therefore requires monitoring: remaining certificate validity, validity of the DNSSEC signatures, and agreement between record and certificate. The MX check reads TLSA records and certificate in one pass and shows whether the two match.

Alongside MTA-STS

The two mechanisms are not mutually exclusive. If you run DNSSEC, setting up both makes sense — sending servers support different mechanisms, and what one can do the other cannot.