Mail transport & reputation

What is DANE? DNS-based Authentication of Named Entities (TLSA) explained

DANE publishes the fingerprint of the mail server certificate in a DNSSEC-signed TLSA record. Sending servers use it to enforce an encrypted connection to the real server.

How DANE works

Every MX host gets a TLSA record at _25._tcp.<mx-host>. It contains three parameters and a hash. Recommended are "3 1 1" (hash of the public key of the server certificate) or "2 1 1" (hash of the key of the issuing certificate authority).

Because the TLSA record is signed with DNSSEC, an attacker cannot forge it. A sending server that supports DANE delivers only if the presented certificate matches the TLSA record – without relying on public certificate authorities.

DANE requires DNSSEC for the zone of the MX host. It is used by web.de, GMX, Posteo and Microsoft Exchange Online, among others.

Example

_25._tcp.mx1.example.com.  TLSA  3 1 1 8f2d6a…c41e

The hash changes when the certificate is renewed with a new key.

Common mistakes

Renewing the certificate with a new key without publishing the new TLSA record first – mail is then not delivered. Fix: publish the new hash in advance as well, or reuse the key on renewal.
TLSA records without DNSSEC – they are then ignored.
Only some of the MX hosts have TLSA records.

How the Domain Trust Check rates DANE

Criterion “DANE/TLSA for mail” (weight 4 of 5): MX hosts signed with DNSSEC, TLSA records at _25._tcp for every MX and recommended parameters (3 1 1 or 2 1 1).

Standard: RFC 6698, RFC 7672