DANE for email (RFC 7672): TLSA records and DNSSEC

DANE (DNS-Based Authentication of Named Entities) for SMTP, defined in RFC 7672 (October 2015), is “a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record.” Where MTA-STS leans on the Web PKI and an HTTPS-served policy, DANE publishes the certificate expectation directly in DNSSEC-signed DNS. That single design choice - anchoring trust in the DNS hierarchy - is what makes DANE both stronger against downgrades and dependent on DNSSEC.

The 60-second version

• DANE publishes a TLSA record under _25._tcp.<mx-hostname> that names the exact certificate or public key your MX will present.
• The zone must be DNSSEC-signed. DANE without DNSSEC provides no security at all - the record could simply be forged.
• When a sender finds a usable (DNSSEC-”secure”) TLSA record, it MUST negotiate STARTTLS and authenticate the certificate against the record. A stripped 250 STARTTLS becomes a hard failure, not a silent downgrade.
• The recommended record to publish for SMTP is DANE-EE(3) SPKI(1) SHA2-256(1) (a SHA-256 hash of your server’s public key), with DANE-TA(2) Cert(0) SHA2-256(1) as a second choice.
• DANE is downgrade-resistant in a way MTA-STS is not: DNSSEC can prove a record is absent, so an attacker cannot fake “this domain has no TLS.”

The TLSA record

; A DANE-EE(3) SPKI(1) SHA2-256(1) record: hash of the MX public key
_25._tcp.mx1.example.com. IN TLSA 3 1 1 (
    0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6 )

The query name is built like any DANE name (RFC 6698 §3): the TCP port, then _tcp, then the host - for SMTP on port 25 at mx1.example.com, that is _25._tcp.mx1.example.com. The RDATA has four parts:

Field	Bytes	Purpose
Certificate usage	1	How the association is used (see table below)
Selector	1	0 = full certificate, 1 = SubjectPublicKeyInfo (the public key)
Matching type	1	0 = exact, 1 = SHA-256, 2 = SHA-512
Certificate association data	rest	The certificate, key, or hash (hex in presentation form)

So 3 1 1 <hash> reads as DANE-EE / public-key / SHA-256.

The four certificate usages

RFC 6698 defines four usages; RFC 7218 gave them the symbolic names in common use:

Usage	Name	Meaning
0	PKIX-TA	CA constraint: the named CA must appear in the chain and PKIX validation must pass
1	PKIX-EE	Service-certificate constraint: must match the end-entity cert and pass PKIX validation
2	DANE-TA	Trust-anchor assertion: the named cert is treated as the trust anchor for the chain
3	DANE-EE	Domain-issued: the named cert/key must match the server’s leaf cert; PKIX validation is not tested

For MTA-to-MTA SMTP on port 25, RFC 7672 is opinionated: publish DANE-EE(3) SPKI(1) SHA2-256(1) in most cases, with DANE-TA(2) Cert(0) SHA2-256(1) as the second option. It explicitly says TLSA records for port-25 SMTP “SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1),” because MTAs have no agreed-upon set of trusted CAs and no human to “click OK” when a CA is unknown.

Two properties make DANE-EE(3) the workhorse:

• Name checks are not required. The binding “is based entirely on the TLSA record association,” so the certificate need not match any particular hostname.
• Certificate expiration is ignored. “The expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature.” A DANE-EE(3) SPKI(1) record even survives certificate renewal as long as the key is reused.

DANE-TA(2) is for domains issuing many certificates under one in-house CA; the trust-anchor certificate MUST then be included in the TLS handshake chain, even if self-signed, because clients are not expected to have it.

The DNSSEC dependency (this is non-negotiable)

DANE’s security comes entirely from DNSSEC. RFC 7672 spells out why ordinary DNS is not enough: SMTP server names come indirectly through MX records, and “without DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning attacks. Active attackers can forge DNS replies with fake MX records.” Therefore “secure verification of SMTP TLS certificates matching the server name is not possible without DNSSEC.”

DNSSEC (RFC 4033) provides “origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of existence.” It adds four record types - RRSIG, DNSKEY, DS, and NSEC - and builds an authentication chain DNSKEY -> [DS -> DNSKEY]* -> RRset from the root down, anchored in a trust anchor (the root key). Critically, keys for a name “can only be signed by a key associated with the parent of that domain name,” which is what gives DANE the “principle of least privilege” the public CA model lacks. (DNSSEC signs DNS; it does not encrypt it - “DNSSEC is not designed to provide confidentiality.”)

A sender validates the TLSA lookup and acts on its DNSSEC state. The four states (RFC 4033 §5) drive the behaviour:

DNSSEC state	What it means	Sender behaviour (RFC 7672)
Secure	Full chain verified; a usable TLSA record exists	MUST negotiate STARTTLS and authenticate against the record
Insecure	Signed proof that the zone is unsigned below this point	Fall back to opportunistic TLS (possibly cleartext)
Bogus	Should validate but does not (missing/expired signatures, etc.)	MUST fall back to the next MX or delay delivery - never silently cleartext
Indeterminate	No trust anchor covers this part of the tree	Treated like the unsigned case

The single most important rule: once at least one “secure” TLSA record is found, the host “has signaled its commitment to implement TLS. The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS. This is required to avoid MITM STARTTLS downgrade attacks.” That is the line that defeats the stripping attack plain STARTTLS cannot.

MX preference still wins

A subtlety operators miss: DANE does not let security reorder your MXes. RFC 7672 requires MX records be “sorted by preference,” and “an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records.” Loop prevention via MX preference takes precedence over channel security. If you want secure inbound mail, every MX needs its own valid TLSA records.

Key rollover and revocation

Because the certificate expectation lives in DNS, rollover is a DNS operation. RFC 7672 requires publishing two TLSA records before changing a key or trust anchor - one matching the live key, one matching its replacement - and waiting for DNS caches to expire the old RRset before switching. Revocation is equally simple: a compromised key is “revoked” by removing its TLSA record from DNS, with “no need for client-side support for OCSP or CRLs.” RFC 7671 adds the operational guidance layer on top of RFC 6698 - certificate-usage selection, digest-algorithm agility (RFC 7671 §9, which RFC 7672 mandates), and publisher synchronization.

Mandatory DANE TLS

A sender MAY require DANE for selected destinations. With mandatory DANE TLS (RFC 7672 §6), “when no usable TLSA records are found, message delivery is delayed,” so “mail is only sent when an authenticated TLS channel is established.” This is the model two organisations use when they exchange sensitive mail and agree to require it - but it also means a partner who breaks their DNSSEC or TLSA records will see your mail to them delayed and possibly bounced, so it demands monitoring.

DANE vs MTA-STS

Both technologies enforce authenticated TLS and resist downgrades. They differ in trust anchor, prerequisites, and failure modes. RFC 8461 was explicitly designed for domains where “deploying DNSSEC is undesirable or impractical.”

Aspect	DANE (RFC 7672)	MTA-STS (RFC 8461)
Trust anchor	DNSSEC chain from the root	Web PKI (public CAs)
Prerequisite	DNSSEC-signed zone (mandatory)	A valid HTTPS certificate on the mta-sts host
Where the policy lives	TLSA record in DNS	TXT signal in DNS plus an HTTPS-served policy file
Proves “no record”?	Yes - authenticated denial of existence	No - first-contact discovery can be blocked
Downgrade resistance	Strong, including first contact	Strong after a policy is cached; weaker on first contact
Per-MX granularity	Yes - publish TLSA per MX host	Policy-wide MX list, no per-MX testing
Certificate type	Often self-issued (DANE-EE/DANE-TA)	Must be a publicly trusted CA cert
Testing/staging mode	No built-in mode; stage with partial MX deployment	Built-in testing mode
Revocation	Remove the TLSA record from DNS	Reissue/rotate the CA certificate

When each applies

• Use DANE when your zone is DNSSEC-signed (or you are willing to sign it). It gives the strongest guarantee, including on the very first contact, and frees you from the public CA system for your MX certificates.
• Use MTA-STS when DNSSEC is impractical, or to cover the large population of senders who honor MTA-STS but not DANE. It needs only a valid web certificate.
• Use both. They coexist by design. RFC 8461 requires that “senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation” - DANE wins ties. Publishing both maximises the set of senders who will encrypt and authenticate mail to you.

Common confusion

• “I published a TLSA record, so DANE is on.” Only if the zone is DNSSEC-signed. A TLSA record in an unsigned zone is insecure to validators and provides no protection - it is just data an attacker can rewrite.
• “DANE-EE(3) ignores expiry, so my cert never matters.” The leaf certificate’s expiry is ignored, but the TLSA record’s DNSSEC signature has its own validity, and your key must still match the published hash. Rotate records when you rotate keys.
• “DANE replaces MTA-STS.” For DNSSEC-signed domains it is stronger, but most senders today honor one or the other, so publishing both reaches more of them. They are complementary, not exclusive.
• “A higher-priority MX with DANE protects me.” Only if every MX has valid TLSA records. A lower-preference MX without them is still reachable, and MX preference is honored ahead of security.
• “PKIX-TA(0)/PKIX-EE(1) are fine for SMTP.” RFC 7672 says they SHOULD NOT be used for port-25 SMTP; MTAs lack a common trusted-CA set. Use DANE-EE(3) or DANE-TA(2).

What this means for you, and what Egressif does

Where a domain we operate is DNSSEC-signed, we publish DANE TLSA records - DANE-EE(3) SPKI(1) SHA2-256(1) on each MX - so senders that support DANE get downgrade-resistant, authenticated delivery from the first connection, with no dependence on the public CA system for our MX certificates. We treat key rollover as a staged DNS operation, publishing the new association alongside the old and waiting out the TTL before cutting over, and we pair DANE with MTA-STS so the senders who honor only one of the two are still covered. TLS-RPT watches both: dnssec-invalid or tlsa-invalid in the reports is our early warning that a rollover or a signing problem needs attention before it turns into delayed mail. We are candid that DANE only helps where DNSSEC is deployed - it is not a universal switch - but for signed domains it is the most conservative trust model available, trusting only the DNS that already controls the name.