SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)

DANE-EE(3) SPKI(1) SHA2-256(1) is the RECOMMENDED TLSA record type for SMTP because it does not fail when leaf or intermediate certificates expire, it survives incomplete server certificate chains, and it requires no changes across certificate renewals when the key is unchanged.

tls, email, crypto

Shared end-entity TLSA CNAME records (multiple MX hosts pointing to a common TLSA RRset bearing a shared end-entity certificate) SHOULD be avoided because they expose the domain to substitution attacks where an MITM can reroute traffic to a different server sharing the same certificate. Shared trust anchor (DANE-TA(2)) CNAMEs do not have this problem.

tls, email, security

SMTP channel security must be opportunistic because email recipient addresses cannot encode transport security policy (unlike HTTPS URIs), STARTTLS offers over a cleartext connection can be trivially suppressed by an MITM attacker, and no TLS security feature can prevent a downgrade to cleartext in the pre-DANE model.

email, tls, security

TLSA certificate usages PKIX-TA(0) and PKIX-EE(1) SHOULD NOT be used for port 25 SMTP because MTAs have no agreed-upon comprehensive CA list, there is no user to 'click OK' when CA verification fails, and a DNSSEC breach allows an attacker to substitute DANE-EE(3) records, making PKIX usages provide no additional security.

email, tls, pkix, security

TLSA records with matching type Full(0) are discouraged for DANE-TA(2) because client implementations may not be able to augment the server certificate chain with DNS-supplied data, especially for bare-key SPKI(1) selectors. Servers should publish non-Full(0) matching types to avoid interoperability issues with large TLSA records.

tls, email, dns

SMTP client TLS HELLO messages SHOULD offer a typical set of non-anonymous cipher suites for interoperability with servers that do not support anonymous suites. Pre-DANE opportunistic TLS clients MAY also include anonymous cipher suites; servers SHOULD be prepared to handle both.

tls, email

Some large email provider nameservers mishandle TLSA queries for unsigned zones, returning SERVFAIL or NOTIMP instead of NXDOMAIN. To avoid consistent delivery failures, the SMTP client MUST perform A/AAAA lookups before TLSA lookups; if address records are 'insecure', TLSA lookup SHOULD be skipped.

dns, email, tls

A security-aware DNS resolver MUST be used. Security-oblivious stub resolvers MUST NOT be used. An MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability to signal DNSSEC validation status obtained from an upstream validating recursive resolver via a secure channel.

dns, email, security, tls

An RFC 4035 'indeterminate' security status MUST be treated by the SMTP client as though a 'bogus' or error result had been returned. All 'insecure' RRsets MUST be handled identically; non-validated data cannot be used for authentication.

dns, email, security

If any DNS queries used to locate TLSA records fail (bogus, indeterminate, timeouts, malformed replies, SERVFAIL, etc.), the SMTP client MUST treat that server as unreachable and MUST NOT deliver the message via that server. If no servers are reachable, delivery is delayed.

dns, email, security, tls

If at any stage of CNAME expansion an 'insecure' CNAME record is encountered, then it and all subsequent results (including the final result) MUST be considered 'insecure', regardless of whether earlier CNAME records were 'secure'.

dns, email, security

MX records MUST be sorted by preference. An MX hostname with a worse (numerically higher) preference that has TLSA records MUST NOT preempt one with a better (lower) preference that lacks TLSA records. Prevention of delivery loops by obeying MX preferences MUST take precedence over channel security.

email, dns, tls

Server operators MUST NOT implement selective STARTTLS (e.g., only with clients demonstrating 'proper MTA behavior' via greylisting) if they also publish DANE TLSA records, as this prevents DANE clients from completing the required TLS negotiation.

email, tls, security

SMTP clients and servers implementing this specification MUST comply with the digest algorithm agility requirements in Section 9 of RFC 7671. When stronger algorithms are available, deprecated algorithms SHOULD be avoided.

tls, email, crypto

SMTP servers relying on DANE-TA(2) TLSA records MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message, even when it is a self-signed root certificate, because clients may not have it locally.

tls, email, pkix

The SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3). The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.

tls, email, security

The SMTP client MUST perform A and/or AAAA queries for the destination before attempting to locate TLSA records. If address records are found but the DNSSEC validation status of the first response is 'insecure', the client SHOULD NOT proceed to search for TLSA records.

dns, email, tls

The SMTP client MUST send the TLS SNI extension containing the TLSA base domain to ensure the server sends the correct certificate chain. Servers MUST NOT enforce the use of SNI by clients; if the client sends no SNI or an SNI for an unsupported domain, the server MUST send a fallback certificate chain.

tls, email

To match a server via certificate usage DANE-TA(2), the client MUST perform name checks and MUST employ the TLSA base domain as the primary reference identifier. When the TLSA base domain was obtained via a secure MX lookup, the original next-hop domain MUST be included as a second reference identifier.

tls, email, pkix, security

Two TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and one matching the new key. Servers may only switch to the new key after sufficient time for all DNS caches to expire the previous TLSA RRset.

tls, dns, email, crypto

When a 'secure' non-empty TLSA RRset where all records are unusable is found, any connection MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.

tls, email, security

When a 'secure' TLSA RRset with at least one usable record is found, any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.

tls, email, security

With certificate usage DANE-EE(3), 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.

tls, crypto, pkix, email

DANE-EE(3) certificate usage authenticates the server by matching the leaf certificate directly against the TLSA record. No name checks or certificate expiry checks are performed; the binding of server public key to name is based entirely on the TLSA record secured by DNSSEC.

tls, email, crypto, pkix

DANE-TA(2) certificate usage identifies a trust anchor; the server certificate chain is validated against this TA with name checks required. Servers must include the TA certificate in the TLS handshake. TLSA records SHOULD use selector Cert(0) rather than SPKI(1) to enforce full TA certificate constraints.

tls, email, pkix, crypto

TLSA records are queried at '_<port>._tcp.<base-domain>'. The TLSA base domain is derived from the MX hostname (or its CNAME-expanded form); when a secure CNAME exists, the fully expanded name is tried first, then the unexpanded name. The first candidate yielding a secure TLSA RRset becomes the actual base domain.

dns, tls, email

Opportunistic SMTP TLS depends critically on DNSSEC for downgrade resistance. A successful DNSSEC breach allows an attacker to publish usage DANE-EE(3) certificate associations, bypassing any protection from PKIX-TA(0) or PKIX-EE(1) records; this further reinforces avoiding those usages in SMTP.

security, tls, dns, email

To prevent downgrade attacks, implementations must strictly follow the sections specifying when non-authenticated or cleartext connections are permissible (Sections 2.1.2, 2.1.3, 2.2, 2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1) and MUST NOT initiate a connection when the specification indicates a server must be considered unreachable.

security, tls, email

TLS discovery defines four states based on TLSA lookup outcome: (1) secure usable TLSA → MUST authenticate via TLS or skip/delay; (2) secure all-unusable TLSA → MUST use TLS without authentication or skip/delay; (3) insecure or absent TLSA → SHOULD use opportunistic TLS, MAY fall back to cleartext; (4) any lookup error → MUST skip that server or delay delivery.

tls, email, security, dns

TLSA records for SMTP are queried using the service label '_25._tcp' prefixed to the SMTP server's candidate base hostname, e.g., '_25._tcp.mx.example.com. IN TLSA ?'. Custom MTA routes using a non-standard port MUST use the actual port number in place of '25'.

dns, tls, email