DANE for SMTP (RFC 7672)

DANE (DNS-Based Authentication of Named Entities) applied to SMTP (RFC 7672) lets a receiving domain publish, in DNSSEC-signed DNS, exactly which TLS certificate or key each of its MX hosts must present. The mere secure existence of a TLSA record tells sending MTAs that TLS is available and mandatory for that server — defeating STARTTLS stripping — and the record data authenticates the server without relying on public CAs.

DANE solves the same downgrade/impersonation problem as MTA-STS, but anchors trust in DNSSEC instead of the Web PKI + trust-on-first-use. The two coexist; see the comparison at the end.

Prerequisite: DNSSEC

Everything hinges on DNSSEC validation status. RFC 7672 uses four states:

State	Meaning	Sender treatment
secure	Cryptographically validated	Usable for DANE
insecure	Zone not DNSSEC-signed	No DANE; fall back to opportunistic (pre-DANE) TLS
bogus	Validation failed	Treated as lookup error
indeterminate	Validation status undeterminable	Treated as lookup error

Hard rule: if any DNS query used to locate TLSA records fails (bogus, indeterminate, timeout, malformed reply, SERVFAIL, …), the SMTP client MUST treat that server as unreachable and MUST NOT deliver via it. DNS tampering thus causes deferral, not silent downgrade.

To publish DANE, the zones containing the MX hostnames, their address records, and the TLSA records must all be DNSSEC-signed and validating.

TLSA record placement

TLSA records live at a name derived from the MX host (not the mail domain), prefixed with port and protocol:

_25._tcp.mx.example.com. IN TLSA 3 1 1 <sha256-digest>

For a non-standard SMTP port, substitute the port number in _<port>._tcp.

TLSA parameters for SMTP

A TLSA record has three parameter fields (certificate usage, selector, matching type) plus the association data. For SMTP, only two certificate usages apply:

Usage	Name	SMTP applicability
0	PKIX-TA	Not applicable. An attacker who can defeat DNSSEC could replace the record anyway, so PKIX adds no security; MTAs also lack a canonical public-CA trust store for opportunistic use
1	PKIX-EE	Not applicable (same reasoning)
2	DANE-TA	Trust-anchor mode: the record designates a CA (often the operator's own); the server must include that trust-anchor certificate in its TLS handshake chain
3	DANE-EE	End-entity mode: the record matches the server's leaf certificate/key directly. Primary recommendation

Recommended parameter combinations:

Combination	Reading	Notes
3 1 1 (DANE-EE, SPKI, SHA2-256)	SHA-256 digest of the server's public key	Primary recommendation. Record survives certificate renewal as long as the key is unchanged
2 0 1 (DANE-TA, Cert, SHA2-256)	SHA-256 digest of the trust-anchor certificate	Secondary. Selector Cert(0) preferred over SPKI(1) to preserve trust-anchor constraints (path length, name constraints). Enables one shared TLSA RRset for many servers under the same CA, via CNAME

SHA2-256 support is mandatory for all DANE implementations, so 1 (SHA2-256) as matching type is safe everywhere.

Name checks and certificate lifetime

	DANE-EE(3)	DANE-TA(2)
Certificate name check	MUST NOT be performed — the TLSA match alone authenticates	Required: a reference identifier must match an RFC 6125 DNS-ID (or CN-ID if no DNS-IDs). Reference identifiers: the TLSA base domain (primary), the original next-hop domain, and the CNAME-expanded domain if different. Wildcards valid only as the entire first label
Certificate expiration	Ignored — validity derives from the DNSSEC signature lifetime of the TLSA record	Checked as part of chain validation

SNI: the SMTP client MUST send SNI containing the TLSA base domain. Servers must not require SNI from clients, and need not send SNI in their own hello if the default certificate matches the TLSA records.

Sending MTA algorithm

1. MX resolution. Look up MX for the next-hop domain. If the MX RRset is secure, proceed per MX host. If insecure: opportunistic DANE falls back to regular (pre-DANE) TLS handling; a locally-configured mandatory DANE policy defers instead. The MTA is not obligated to prefer the MX host offering more security — normal MX preference ordering applies.
2. Address resolution. Resolve A/AAAA for the MX host first — both to confirm reachability and to learn the DNSSEC status of the name chain. If address records are insecure, skip TLSA lookups (avoids lookup errors on unsigned zones). CNAME handling determines candidate TLSA base domains: a secure CNAME chain yields two candidates (fully expanded name first, then the original name); an insecure initial CNAME leaves only the original name.
3. TLSA lookup. Query _25._tcp.<candidate> for each candidate; the first candidate returning a secure TLSA RRset becomes the TLSA base domain. Follow CNAMEs in TLSA responses only while the whole chain stays secure.
4. Apply the outcome:

TLSA lookup outcome	Sender obligation
secure RRset with ≥1 usable record	TLS mandatory, authentication via TLSA matching required. Auth failure ⇒ do not deliver via this server; try next MX or defer
secure non-empty RRset, but all records unusable (unknown parameters, etc.)	TLS (encryption) mandatory, but authentication not required. TLS connection failure ⇒ next server or defer
insecure RRset, or authenticated denial of existence	No DANE: fall back to pre-DANE opportunistic TLS (cleartext acceptable if STARTTLS unavailable)
Any lookup error (bogus/indeterminate/SERVFAIL/timeout)	Server is unreachable; defer if no other servers remain

Delivery failures under DANE are deferrals (transient), never a downgrade to cleartext. Failures are reportable via TLS-RPT result-types tlsa-invalid, dnssec-invalid, and dane-required.

Operational guidance for publishers

Key/certificate rotation — always pre-publish:

1. Publish two TLSA records: one matching the current key/cert, one matching the next.
2. Wait at least the TLSA TTL for caches to expire.
3. Switch the server to the new key/cert.
4. Remove the old TLSA record once no longer needed.

Rotating the server key without pre-publishing the new TLSA record causes strict senders to defer all mail until DNS converges.

• With 3 1 1 (SPKI digest), routine certificate renewals that keep the same key need no TLSA change.
• DANE-TA(2) with CNAME centralization: point each server's _25._tcp name at a shared central TLSA RRset; the CA operator pre-publishes new trust-anchor digests there before servers adopt new keys. If one server's key is compromised, replace its CNAME with a direct DANE-EE(3) record until its certificate expires.
• No selective STARTTLS: if a server advertises STARTTLS only to some clients (e.g., after greylisting-style probes), DANE-aware senders — for whom cleartext is forbidden — can never complete the expected first transaction. Operators publishing TLSA records MUST NOT run selective STARTTLS.
• Monitor your own TLSA/DNSSEC health continuously: an expired DNSSEC signature makes your domain unreachable (not just unauthenticated) for DANE-validating senders.

DANE vs MTA-STS

	DANE (RFC 7672)	MTA-STS (RFC 8461)
Trust anchor	DNSSEC	Web PKI (CA certificates) + HTTPS
Requires DNSSEC	Yes (signed MX, address, and TLSA zones)	No
First-contact protection	Yes — secure denial of existence is itself authenticated	No — trust on first use; protection begins once a policy is cached
Downgrade resistance	Strong (DNS tampering ⇒ deferral)	Weaker (attacker can suppress discovery before first cache)
Granularity	Per MX host and port	Per mail domain (MX name patterns)
Certificate model	Pinned key/cert (DANE-EE) or private trust anchor (DANE-TA); public CA not needed	CA-signed certificate with matching SAN required on every MX
Failure mode	Defer (temp-fail)	Defer under enforce; deliver + report under testing
Reporting	Via TLS-RPT (policy-type: tlsa)	Via TLS-RPT (policy-type: sts)

Precedence when both are published: RFC 8461 requires that senders implementing both MUST NOT let a passing MTA-STS policy override a failing DANE validation. DANE is the stronger mechanism; MTA-STS extends coverage to senders and domains that can't do DNSSEC. Publishing both is legitimate and increasingly common; a sender's per-day results for each appear as separate policy entries in TLS-RPT reports.