DANE for SMTP (TLSA)

What it is

DANE (DNS-based Authentication of Named Entities) lets you publish, in DNSSEC-signed DNS, which certificate or public key your mail server presents. Sending servers that support DANE require TLS and verify the certificate against the TLSA record.

Because the information is protected by DNSSEC, DANE does not depend on public certificate authorities and cannot be stripped by an attacker.

How it works

• TLSA records live at _25._tcp.<mx-host> for each MX host.
• Usage 3 (DANE-EE) pins the server's own certificate or key; usage 2 (DANE-TA) pins a trust anchor. These are the two recommended for SMTP.
• Selector 1 (SubjectPublicKeyInfo) survives certificate renewals that reuse the key; selector 0 pins the full certificate.
• Matching type 1 (SHA-256) is the common choice.
• Both the MX host zone and the domain zone must be DNSSEC-signed.

Example

3 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3

Common mistakes

• Rotating keys without updating TLSA

  Publish the new key's TLSA record before deploying the new key (key rollover: "3 1 1 current" + "3 1 1 next").

• DANE without DNSSEC

  TLSA records in an unsigned zone are ignored.

• Using usage 0/1 for SMTP

  PKIX usages are not recommended for SMTP (RFC 7672); use 3 or 2.

• Missing records for some MX hosts

  Every MX host should publish TLSA records, including backup MX.

Specifications

• RFC 7672