SMTP commonly begins with a plaintext connection and upgrades it with STARTTLS. Opportunistic TLS improves confidentiality when both sides support it, but an unauthenticated upgrade can be suppressed or redirected by an active network attacker. DANE for SMTP, specified in RFC 7672, adds an authentication path rooted in DNSSEC.
The sending MTA does not treat every TLSA response as authoritative. It first needs a DNSSEC-secure result for the destination data that drives delivery. When usable TLSA records are securely obtained for the selected MX host, those records constrain the TLS server credentials that the sender accepts.
TLSA records are attached to the SMTP service
A TLSA record associates certificate material with a specific transport endpoint. For SMTP delivery to an MX host named mx.example.net on TCP port 25, the lookup name has this form:
_25._tcp.mx.example.netThe record contains four fields: certificate usage, selector, matching type, and certificate association data. RFC 6698 defines selectors for a full certificate and for SubjectPublicKeyInfo, plus matching modes for exact data, SHA-256, and SHA-512.
A frequently deployed DANE-EE form can be represented as:
_25._tcp.mx.example.net. IN TLSA 3 1 1 <sha256-of-spki>Here, usage 3 is DANE-EE, selector 1 selects SubjectPublicKeyInfo, and matching type 1 compares its SHA-256 digest. The digest is not a certificate fingerprint in the generic sense; its input is determined by the selector.
DNSSEC supplies the authentication root
A TLSA record only carries DANE security semantics when its DNS data is validated through DNSSEC. A sender that receives insecure DNS data cannot promote that data into an authenticated TLS requirement merely because a TLSA RR appears in the response.
This dependency extends beyond the final TLSA query. SMTP routing begins with MX resolution, and aliases or delegation paths can affect the names used for subsequent lookups. RFC 7672 defines processing rules so the sender can distinguish authenticated routing data from data that cannot support DANE authentication.
The resulting trust model differs from ordinary public-CA validation. With DANE-EE usage, a DNSSEC-authenticated TLSA association can directly authenticate the server’s end-entity certificate or public key. The DNS operator is asserting the credential association for that service endpoint through the DNSSEC chain.
DANE-EE can authenticate without public-CA PKIX validation
RFC 7672 recommends DANE-EE usage 3 with selector 1 and SHA-256 matching for SMTP DANE deployments. In that mode, the sender matches the TLS server’s leaf credential against the TLSA association.
For DANE-EE, the certificate does not need to chain to a public CA accepted by the sender. The certificate name is also not the source of the server identity binding in this mode. The authenticated TLSA record supplies that binding for the SMTP service.
This permits operational models that do not depend on the broad public Web PKI trust set. It does not remove certificate lifecycle work: operators still need to coordinate TLSA publication, DNS TTLs, DNSSEC validity, private keys, and server credential rotation.
A secure TLSA association changes failure handling
Without an authenticated policy, opportunistic SMTP TLS can fall back when TLS is unavailable. That behavior favors mail delivery but permits downgrade in the presence of an active attacker.
With applicable DNSSEC-authenticated TLSA records, the sender has authenticated information indicating the expected TLS credential. A failure to negotiate acceptable TLS or to match the server credential is therefore not equivalent to ordinary absence of opportunistic TLS. Delivery is deferred rather than silently continuing over an unauthenticated plaintext channel.
This distinction is the core security property. DANE does not merely request encryption; it gives the sender authenticated data against which the TLS session can be checked.
Multiple TLSA records support credential transitions
A TLSA RRset can contain more than one association. During a planned credential rotation, an operator can publish associations for both the current and replacement credentials before switching the server.
The safe sequence depends on DNS caching. The replacement association needs time to reach relevant caches before the server starts presenting only the replacement credential. After old cached RRsets have expired and the transition is complete, the obsolete association can be removed.
Publishing multiple records does not mean all of them must match. A sender can accept the TLS session when an applicable authenticated association matches according to the protocol rules. This overlap gives operators a way to rotate keys or certificates without creating an avoidable authentication gap.
DANE and MTA-STS protect SMTP through different control planes
DANE and MTA-STS can both make SMTP TLS downgrade-resistant, but their trust and publication mechanisms are distinct. DANE places authenticated service credential associations in DNS and relies on DNSSEC. MTA-STS publishes a policy retrieved over HTTPS and uses the Web PKI for that policy channel.
DANE can bind acceptance directly to certificate or public-key material through TLSA. MTA-STS instead specifies acceptable MX patterns and requires certificate validation under its policy model. Neither mechanism should be described as a drop-in representation of the other.
TLS-RPT is separate as well. It provides aggregate reporting about TLS delivery outcomes; it does not authenticate a TLSA record, a certificate, or an SMTP connection.
DNSSEC and credential operations become one deployment boundary
DANE for SMTP joins two operational systems that are often managed separately: DNSSEC and mail-server TLS. A valid server certificate is insufficient if the published TLSA association points elsewhere, while a correct TLSA record cannot compensate for broken DNSSEC validation on the path that establishes its authenticity.
That coupling is deliberate. The sender accepts the TLS credential because the DNSSEC-authenticated service data authorizes it. When the chain, record, and presented credential remain consistent, SMTP gains authenticated TLS without relying solely on opportunistic encryption or the public-CA trust model.