DANE for SMTP (RFC 7672)

If your mail servers sit in DNSSEC-signed zones, you can tell every sending server exactly which TLS certificate or key your MX hosts must present, and stop attackers from stripping STARTTLS. DNS-Based Authentication of Named Entities (DANE), applied to SMTP in RFC 7672, does this with records published in DNSSEC-signed DNS.

The secure existence of a TLSA record is enough on its own to tell sending mail transfer agents (MTAs) that TLS is available and mandatory for that server, which defeats STARTTLS stripping. The record data then authenticates the server without relying on public certificate authorities (CAs).

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

Prerequisite: DNSSEC

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

A hard rule: if any DNS query used to locate TLSA records fails (bogus, indeterminate, timeout, malformed reply, SERVFAIL, and so on), the SMTP client MUST treat that server as unreachable and MUST NOT deliver through it. Tampering with DNS therefore causes a deferral, not a silent downgrade.

To publish DANE, the zones that contain the MX hostnames, their address records and the TLSA records must all be signed with DNSSEC and must validate.

TLSA record placement

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

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

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

TLSA parameters for SMTP

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

Recommended combinations of parameters:

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

Name checks and certificate lifetime

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

Sending MTA algorithm

1. MX resolution. Look up the MX records for the next-hop domain. If the MX RRset is secure, continue for each MX host. If it is insecure, opportunistic DANE falls back to regular TLS handling as before DANE, while a locally configured policy that makes DANE mandatory defers instead. The MTA is not required to prefer the MX host that offers more security; the normal order of MX preference applies.
2. Address resolution. Resolve the A and AAAA records for the MX host first, both to confirm that it is reachable and to learn the DNSSEC status of the chain of names. If the address records are insecure, skip the TLSA lookups (this avoids lookup errors on unsigned zones). CNAME handling determines the candidate TLSA base domains: a secure CNAME chain gives two candidates (the fully expanded name first, then the original name), and an insecure initial CNAME leaves only the original name.
3. TLSA lookup. Query _25._tcp.<candidate> for each candidate. The first candidate that returns 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:

Delivery failures under DANE are deferrals (transient), never a downgrade to cleartext. They can be reported through the TLS-RPT result types tlsa-invalid, dnssec-invalid and dane-required.

Operational guidance for publishers

When you rotate keys or certificates, always publish in advance:

1. Publish two TLSA records: one that matches the current key or certificate, and one that matches the next.
2. Wait at least the TTL of the TLSA records, so that caches expire.
3. Switch the server to the new key or certificate.
4. Remove the old TLSA record once it is no longer needed.

If you rotate the server key without publishing the new TLSA record in advance, strict senders defer all mail until DNS converges.

• With 3 1 1 (an SPKI digest), routine certificate renewals that keep the same key need no change to the TLSA records.
• DANE-TA(2) with CNAME centralization: point the _25._tcp name of each server at a shared central TLSA RRset. The CA operator publishes digests of new trust anchors 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 (for example, after probes in the style of greylisting), senders that support DANE, for which cleartext is forbidden, can never complete the expected first transaction. Operators that publish TLSA records MUST NOT run selective STARTTLS.
• Monitor the health of your own TLSA records and DNSSEC continuously. An expired DNSSEC signature makes your domain unreachable, not only unauthenticated, for senders that validate DANE.

DANE vs MTA-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, and MTA-STS extends coverage to senders and domains that cannot use DNSSEC. Publishing both is legitimate and increasingly common. A sender's daily results for each appear as separate policy entries in TLS-RPT reports.