3. DANE Authentication
This section describes which TLSA records are applicable to SMTP
opportunistic DANE TLS and how to apply such records to authenticate
the SMTP server. With opportunistic DANE TLS, both the TLS support
implied by the presence of DANE TLSA records and the verification
parameters necessary to authenticate the TLS peer are obtained
together. In contrast to protocols where channel security policy is
set exclusively by the client, authentication via this protocol is
expected to be less prone to connection failure caused by
incompatible configuration of the client and server.
3.1. TLSA Certificate Usages
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
via combinations of three numeric parameters. The numeric values of
these parameters were later given symbolic names in [RFC7218]. The
rest of the TLSA record is the "certificate association data field",
which specifies the full or digest value of a certificate or
Since opportunistic DANE TLS will be used by non-interactive MTAs,
with no user to "click OK" when authentication fails, reliability of
peer authentication is paramount. Server operators are advised to
publish TLSA records that are least likely to fail authentication due
to interoperability or operational problems. Because DANE TLS relies
on coordinated changes to DNS and SMTP server settings, the best
choice of records to publish will depend on site-specific practices.
The certificate usage element of a TLSA record plays a critical role
in determining how the corresponding certificate association data
field is used to authenticate a server's certificate chain.
Sections 3.1.1 and 3.1.2 explain the process for certificate usages
DANE-EE(3) and DANE-TA(2), respectively. Section 3.1.3 briefly
explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not
applicable with opportunistic DANE TLS.
In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)",
with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second
choice, depending on site needs. See Sections 3.1.1 and 3.1.2 for
more details. Other combinations of TLSA parameters either (1) are
explicitly unsupported or (2) offer little to recommend them over
3.1.1. Certificate Usage DANE-EE(3)
Authentication via certificate usage DANE-EE(3) TLSA records involves
simply checking that the server's leaf certificate matches the TLSA
record. In particular, the binding of the server public key to its
name is based entirely on the TLSA record association. The server
MUST be considered authenticated even if none of the names in the
certificate match the client's reference identity for the server.
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.
With DANE-EE(3), servers need not employ SNI (they may ignore the
client's SNI message) even when the server is known under independent
names that would otherwise require separate certificates. It is
instead sufficient for the TLSA RRsets for all the domains in
question to match the server's default certificate. Of course, with
SMTP servers it is simpler still to publish the same MX hostname for
all the hosted domains.
For domains where it is practical to make coordinated changes in DNS
TLSA records during SMTP server key rotation, it is often best to
publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
certificates don't suddenly stop working when leaf or intermediate
certificates expire, nor do they fail when the server operator
neglects to configure all the required issuer certificates in the
server certificate chain.
TLSA records published for SMTP servers SHOULD, in most cases, be
"DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
implementations are required to support SHA2-256, this record type
works for all clients and need not change across certificate renewals
with the same key.
3.1.2. Certificate Usage DANE-TA(2)
Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing CA to create certificates for multiple TLS
services, it may be simpler to publish the issuing authority as a
trust anchor (TA) for the certificate chains of all relevant
services. The TLSA query domain (TLSA base domain with port and
protocol prefix labels) for each service issued by the same TA may
then be set to a CNAME alias that points to a common TLSA RRset that
matches the TA. For example:
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
With usage DANE-TA(2), the server certificates will need to have
names that match one of the client's reference identifiers (see
[RFC6125]). The server MAY employ SNI to select the appropriate
certificate to present to the client.
SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
for TLS authentication 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. Many SMTP
servers are not configured with a comprehensive list of trust
anchors, nor are they expected to be at any point in the future.
Some MTAs will ignore all locally trusted certificates when
processing usage DANE-TA(2) TLSA records. Thus, even when the TA
happens to be a public CA known to the SMTP client, authentication is
likely to fail unless the TA certificate is included in the TLS
server certificate message.
With some SMTP server software, it is not possible to configure the
server to include self-signed (root) CA certificates in the server
certificate chain. Such servers either MUST publish DANE-TA(2)
records for an intermediate certificate or MUST instead use
DANE-EE(3) TLSA records.
TLSA records with a matching type of Full(0) are discouraged. While
these potentially obviate the need to transmit the TA certificate in
the TLS server certificate message, client implementations may not be
able to augment the server certificate chain with the data obtained
from DNS, especially when the TLSA record supplies a bare key
(selector SPKI(1)). Since the server will need to transmit the TA
certificate in any case, server operators SHOULD publish TLSA records
with a matching type other than Full(0) and avoid potential
interoperability issues with large TLSA records containing full
certificates or keys.
TLSA Publishers employing DANE-TA(2) records SHOULD publish records
with a selector of Cert(0). Such TLSA records are associated with
the whole trust anchor certificate, not just with the trust anchor
public key. In particular, the SMTP client SHOULD then apply any
relevant constraints from the trust anchor certificate, such as, for
example, path length constraints.
While a selector of SPKI(1) may also be employed, the resulting TLSA
record will not specify the full trust anchor certificate content,
and elements of the trust anchor certificate other than the public
key become mutable. This may, for example, allow a subsidiary CA to
issue a chain that violates the trust anchor's path length or name
3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1)
Note that this section applies to MTA-to-MTA SMTP, which is normally
on port 25 -- that is, to servers that are the SMTP servers for one
or more destination domains. Other uses of SMTP, such as in
MUA-to-MSA submission on ports 587 or 465, are out of scope for this
document. Where those other uses also employ TLS opportunistically
and/or depend on DNSSEC as a result of DNS-based discovery of service
location, the relevant specifications should, as appropriate, arrive
at similar conclusions.
As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without
relying on DNSSEC for "secure" MX records and DANE for STARTTLS
support signaling, perform server identity verification or prevent
STARTTLS downgrade attacks. The use of PKIX CAs offers no added
security, since an attacker capable of compromising DNSSEC is free to
replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records
bearing any convenient non-PKIX certificate usage. Finally, as
explained in Section 1.3.4, there is no list of trusted CAs agreed
upon by all MTAs and no user to "click OK" when a server's CA is not
trusted by a client.
Therefore, TLSA records for the port 25 SMTP service used by client
MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or
PKIX-EE(1). SMTP client MTAs cannot be expected to be configured
with a suitably complete set of trusted public CAs. Lacking a
complete set of public CAs, MTA clients would not be able to verify
the certificates of SMTP servers whose issuing root CAs are not
trusted by the client.
Opportunistic DANE TLS needs to interoperate without bilateral
coordination of security settings between client and server systems.
Therefore, parameter choices that are fragile in the absence of
bilateral coordination are unsupported. Nothing is lost; since the
PKIX certificate usages cannot aid SMTP TLS security, they can only
impede SMTP TLS interoperability.
SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
or PKIX-EE(1) is undefined. As with any other unsupported
certificate usage, SMTP clients MAY treat such records as "unusable".
3.2. Certificate Matching
When at least one usable "secure" TLSA record is found, the SMTP
client MUST use TLSA records to authenticate the SMTP server.
Messages MUST NOT be delivered via the SMTP server if authentication
fails; otherwise, the SMTP client is vulnerable to MITM attacks.
3.2.1. DANE-EE(3) Name Checks
The SMTP client MUST NOT perform certificate name checks with
certificate usage DANE-EE(3) (Section 3.1.1).
3.2.2. DANE-TA(2) Name Checks
To match a server via a TLSA record with certificate usage
DANE-TA(2), the client MUST perform name checks to ensure that it has
reached the correct server. In all DANE-TA(2) cases, the SMTP client
MUST employ the TLSA base domain as the primary reference identifier
for matching the server certificate.
TLSA records for MX hostnames: If the TLSA base domain was obtained
indirectly via a "secure" MX lookup (including any CNAME-expanded
name of an MX hostname), then the original next-hop domain used in
the MX lookup MUST be included as a second reference identifier.
The CNAME-expanded original next-hop domain MUST be included as a
third reference identifier if different from the original next-hop
domain. When the client MTA is employing DANE TLS security
despite "insecure" MX redirection, the MX hostname is the only
TLSA records for non-MX hostnames: If MX records were not used
(e.g., if none exist) and the TLSA base domain is the
CNAME-expanded original next-hop domain, then the original
next-hop domain MUST be included as a second reference identifier.
Accepting certificates with the original next-hop domain in addition
to the MX hostname allows a domain with multiple MX hostnames to
field a single certificate bearing a single domain name (i.e., the
email domain) across all the SMTP servers. This also aids
interoperability with pre-DANE SMTP clients that are configured to
look for the email domain name in server certificates -- for example,
with "secure" DNS records as shown below:
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
example.com. IN MX 15 mx15.example.com.
example.com. IN MX 20 mx20.example.com.
mx10.example.com. IN A 192.0.2.10
_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
mx15.example.com. IN CNAME mxbackup.example.com.
mxbackup.example.com. IN A 192.0.2.15
; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
mx20.example.com. IN CNAME mxbackup.example.net.
mxbackup.example.net. IN A 198.51.100.20
_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
Certificate name checks for delivery of mail to exchange.example.org
via any of the associated SMTP servers MUST accept at least the names
"exchange.example.org" and "example.com", which are, respectively,
the original and fully expanded next-hop domain. When the SMTP
server is mx10.example.com, name checks MUST accept the TLSA base
domain "mx10.example.com". If, despite the fact that MX hostnames
are required to not be aliases, the MTA supports delivery via
"mx15.example.com" or "mx20.example.com", then name checks MUST
accept the respective TLSA base domains "mx15.example.com" and
3.2.3. Reference Identifier Matching
When name checks are applicable (certificate usage DANE-TA(2)), if
the server certificate contains a Subject Alternative Name extension
[RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs
are matched against the client's reference identifiers. The CN-ID
[RFC6125] is only considered when no DNS-IDs are present. The server
certificate is considered matched when one of its presented
identifiers [RFC5280] matches any of the client's reference
Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
The wildcard character must be the entire first label of the DNS-ID
or CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com"
and "*smtp.example.com" are not. SMTP clients MUST support wildcards
that match the first label of the reference identifier, with the
remaining labels matching verbatim. For example, the DNS-ID
"*.example.com" matches the reference identifier "mx1.example.com".
SMTP clients MAY, subject to local policy, allow wildcards to match
multiple reference identifier labels, but servers cannot expect broad
support for such a policy. Therefore, any wildcards in server
certificates SHOULD match exactly one label in either the TLSA base
domain or the next-hop domain.
4. Server Key Management
Two TLSA records MUST be published before employing a new EE or TA
public key or certificate: one matching the currently deployed key
and the other matching the new key scheduled to replace it. Once
sufficient time has elapsed for all DNS caches to expire the previous
TLSA RRset and related signature RRsets, servers may be configured to
use the new EE private key and associated public key certificate or
may employ certificates signed by the new trust anchor.
Once the new public key or certificate is in use, the TLSA RR that
matches the retired key can be removed from DNS, leaving only RRs
that match keys or certificates in active use.
As described in Section 3.1.2, when server certificates are validated
via a DANE-TA(2) trust anchor and CNAME records are employed to store
the TA association data at a single location, the responsibility of
updating the TLSA RRset shifts to the operator of the trust anchor.
Before a new trust anchor is used to sign any new server
certificates, its certificate (digest) is added to the relevant TLSA
RRset. After enough time elapses for the original TLSA RRset to age
out of DNS caches, the new trust anchor can start issuing new server
certificates. Once all certificates issued under the previous trust
anchor have expired, its associated RRs can be removed from the TLSA
In the DANE-TA(2) key management model, server operators do not
generally need to update DNS TLSA records after initially creating a
CNAME record that references the centrally operated DANE-TA(2) RRset.
If a particular server's key is compromised, its TLSA CNAME SHOULD be
replaced with a DANE-EE(3) association until the certificate for the
compromised key expires, at which point it can return to using a
CNAME record. If the central trust anchor is compromised, all
servers need to be issued new keys by a new TA, and an updated
DANE-TA(2) TLSA RRset needs to be published containing just the
SMTP servers cannot expect broad Certificate Revocation List (CRL) or
Online Certificate Status Protocol (OCSP) support from SMTP clients.
As outlined above, with DANE, compromised server or trust anchor keys
can be "revoked" by removing them from the DNS without the need for
client-side support for OCSP or CRLs.
5. Digest Algorithm Agility
While [RFC6698] specifies multiple digest algorithms, it does not
specify a protocol by which the SMTP client and TLSA record publisher
can agree on the strongest shared algorithm. Such a protocol would
allow the client and server to avoid exposure to deprecated weaker
algorithms that are published for compatibility with less capable
clients. When stronger algorithms are an option, deprecated
algorithms SHOULD be avoided. Such a protocol is specified in
[RFC7671]. SMTP clients and servers that implement this
specification MUST comply with the requirements outlined in Section 9
6. Mandatory TLS Security
An MTA implementing this protocol may require a stronger security
assurance when sending email to selected destinations. The sending
organization may need to send sensitive email and/or may have
regulatory obligations to protect its content. This protocol is not
in conflict with such a requirement and, in fact, can often simplify
authenticated delivery to such destinations.
Specifically, with domains that publish DANE TLSA records for their
MX hostnames, a sending MTA can be configured to use the receiving
domain's DANE TLSA records to authenticate the corresponding SMTP
server. Authentication via DANE TLSA records is easier to manage, as
changes in the receiver's expected certificate properties are made on
the receiver end and don't require manually communicated
configuration changes. With mandatory DANE TLS, when no usable TLSA
records are found, message delivery is delayed. Thus, mail is only
sent when an authenticated TLS channel is established to the remote
Administrators of mail servers that employ mandatory DANE TLS need to
carefully monitor their mail logs and queues. If a partner domain
unwittingly misconfigures its TLSA records, disables DNSSEC, or
misconfigures SMTP server certificate chains, mail will be delayed
and may bounce if the issue is not resolved in a timely manner.
7. Note on DANE for Message User Agents
We note that SMTP is also used between Message User Agents (MUAs) and
Message Submission Agents (MSAs) [RFC6409]. In [RFC6186], a protocol
is specified that enables an MUA to dynamically locate the MSA based
on the user's email address. SMTP connection security considerations
for MUAs implementing [RFC6186] are largely analogous to connection
security requirements for MTAs, and this specification could be
applied largely verbatim with DNS MX records replaced by
corresponding DNS Service (SRV) records [RFC7673].
However, until MUAs begin to adopt the dynamic configuration
mechanisms of [RFC6186], they are adequately served by more
traditional static TLS security policies. Specification of DANE TLS
for MUA-to-MSA SMTP is left to future documents that focus
specifically on SMTP security between MUAs and MSAs.
8. Interoperability Considerations
8.1. SNI Support
To ensure that the server sends the right certificate chain, the SMTP
client MUST send the TLS SNI extension containing the TLSA base
domain. This precludes the use of the Secure Socket Layer (SSL)
HELLO that is SSL 2.0 compatible by the SMTP client.
Each SMTP server MUST present a certificate chain (see [RFC5246],
Section 7.4.2) that matches at least one of the TLSA records. The
server MAY rely on SNI to determine which certificate chain to
present to the client. Clients that don't send SNI information may
not see the expected certificate chain.
If the server's TLSA records match the server's default certificate
chain, the server need not support SNI. In either case, the server
need not include the SNI extension in its TLS HELLO, as simply
returning a matching certificate chain is sufficient. Servers
MUST NOT enforce the use of SNI by clients, as the client may be
using unauthenticated opportunistic TLS and may not expect any
particular certificate from the server. If the client sends no SNI
extension or sends an SNI extension for an unsupported domain, the
server MUST simply send some fallback certificate chain of its
choice. The reason for not enforcing strict matching of the
requested SNI hostname is that DANE TLS clients are typically willing
to accept multiple server names but can only send one name in the SNI
extension. The server's fallback certificate may match a different
name acceptable to the client, e.g., the original next-hop domain.
8.2. Anonymous TLS Cipher Suites
Since many SMTP servers either do not support or do not enable any
anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
offer to negotiate a typical set of non-anonymous cipher suites
required for interoperability with such servers. An SMTP client
employing pre-DANE opportunistic TLS MAY also include one or more
anonymous TLS cipher suites in its TLS HELLO. SMTP servers that need
to interoperate with opportunistic TLS clients SHOULD be prepared to
interoperate with such clients by either always selecting a mutually
supported non-anonymous cipher suite or correctly handling client
connections that negotiate anonymous cipher suites.
Note that while SMTP server operators are under no obligation to
enable anonymous cipher suites, no security is gained by sending
certificates to clients that will ignore them. Indeed, support for
anonymous cipher suites in the server makes audit trails more
informative. Log entries that record connections that employed an
anonymous cipher suite record the fact that the clients did not care
to authenticate the server.
9. Operational Considerations
9.1. Client Operational Considerations
An operational error on the sending or receiving side that cannot be
corrected in a timely manner may, at times, lead to consistent
failure to deliver time-sensitive email. The sending MTA
administrator may have to choose between allowing email to queue
until the error is resolved and disabling opportunistic or mandatory
DANE TLS (Section 6) for one or more destinations. The choice to
disable DANE TLS security should not be made lightly. Every
reasonable effort should be made to determine that problems with mail
delivery are the result of an operational error and not an attack. A
fallback strategy may be to configure explicit out-of-band TLS
security settings if supported by the sending MTA.
SMTP clients may deploy opportunistic DANE TLS incrementally by
enabling it only for selected sites or may occasionally need to
disable opportunistic DANE TLS for peers that fail to interoperate
due to misconfiguration or software defects on either end. Some
implementations MAY support DANE TLS in an "audit only" mode in which
failure to achieve the requisite security level is logged as a
warning and delivery proceeds at a reduced security level. Unless
local policy specifies "audit only" or specifies that opportunistic
DANE TLS is not to be used for a particular destination, an SMTP
client MUST NOT deliver mail via a server whose certificate chain
fails to match at least one TLSA record when usable TLSA records are
found for that server.
9.2. Publisher Operational Considerations
Some MTAs enable STARTTLS selectively. For example, they might only
support STARTTLS with clients that have previously demonstrated
"proper MTA behavior", e.g., by retrying the delivery of deferred
messages (greylisting). If such an MTA publishes DANE TLSA records,
sending MTAs that implement this specification will not attempt the
initial cleartext SMTP transaction needed to establish the "proper
MTA behavior", because they cannot establish the required channel
security. Server operators MUST NOT implement selective STARTTLS if
they also want to support DANE TLSA.
TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].
TLSA Publishers SHOULD follow the TLSA publication size guidance
found in Section 10.1 of [RFC7671].
TLSA Publishers SHOULD follow the TLSA record TTL and signature
lifetime recommendations found in Section 13 of [RFC7671].
10. Security Considerations
This protocol leverages DANE TLSA records to implement MITM-resistant
Opportunistic Security [RFC7435] for SMTP. For destination domains
that sign their MX records and publish signed TLSA records for their
MX hostnames, this protocol allows sending MTAs to securely discover
both the availability of TLS and how to authenticate the destination.
This protocol does not aim to secure all SMTP traffic, as that is not
practical until DNSSEC and DANE adoption are universal. The
incremental deployment provided by following this specification is a
best possible path for securing SMTP. This protocol coexists and
interoperates with the existing insecure Internet email backbone.
The protocol does not preclude existing non-opportunistic SMTP TLS
security arrangements, which can continue to be used as before via
manual configuration with negotiated out-of-band key and TLS
Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
resistance and secure resolution of the destination name. If DNSSEC
is compromised, it is not possible to fall back on the public CA PKI
to prevent MITM attacks. A successful breach of DNSSEC enables the
attacker to publish TLSA usage 3 certificate associations and thereby
The authors would like to extend great thanks to Tony Finch, who
started the original version of a DANE SMTP document. His work is
greatly appreciated and has been incorporated into this document.
The authors would like to additionally thank Phil Pennock for his
comments and advice on this document.
Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated
me to begin work on this memo and provided feedback on early draft
versions of this document. Thanks to Patrick Koetter, Perry Metzger,
and Nico Williams for valuable review comments. Thanks also to
Wietse Venema, who created Postfix, and whose advice and feedback
were essential to the development of the Postfix DANE implementation.
P.O. Box 382
Davis, CA 95617