DNS-Based Authentication of Named Entities (DANE) is an internet standard that leverages DNSSEC and the TLSA DNS resource record to augment (or even replace) the Public Key Infrastructure (PKI).
When DANE is used in combination with SMTP, it forces the sender to use TLS encryption (
STARTTLS) for the SMTP session, much like MTA-STS does.
With DANE, a TLSA type DNS Resource Record is placed in a domain DNS zone, which can then be used to authenticate x.509 certificates. By requiring DNSSEC, the client can authenticate the TLSA record itself, to build a chain-of-trust.
DANE can work with all TLS encrypted communication protocols, including SMTP services that use rfc3207 SMTP over TLS (
DANE can be used to augment the traditional PKI by adding certificate pinning, this way DANE can help prevent man-in-the-middle and downgrade attacks.
DANE and the TLSA resource record are originally specified in rfc6698, and later updated in rfc7671. DANE usage in combination with SMTP is detailed in rfc7672.
DANE has the potential to leverage DNSSEC as a replacement for the Public Key Infrastructure (PKI), on which the chain of trust on the internet is currently based. However, there are concerns about the safety, resilience and robustness of the DNS. Security researchers have argued that DANE is not a viable replacement of the PKI.
In this article we'll restrict ourselves to exploring DANE as an augmentation of the existing PKI in the form of certificate pinning. We do not recommend attempting to use DANE as a PKI replacement in a production infrastructure.
With this article being part of the email hardening guide, we'll explore DANE in combination with SMTP, but the knowledge obtained from this article should also apply to other services such as HTTPS.
DANE uses the 'TLSA' DNS Resource Record, which is specified in rfc6698. A TLSA record contains information on an x.509 certificate that is to be expected from the service that is being connected to (such as HTTPS web services, or SMTP services).
The TLSA record is placed at DNS address
_[port]._[protocol].[domain], for example:
The TLSA record in this example would be used for TCP services on port 25 (which is SMTP) at
When combined with SMTP, DANE serves two purposes:
Note that if the domain does not support DNSSEC, then DANE cannot be used. In that case MTA-STS can be used to enforce TLS encryption for inbound email.
Example: A DANE capable SMTP service needs to deliver email to
example.mailhardener.com, SMTP works on TCP port 25.
The sender (the sending SMTP service) will first query the DNS for TLSA records at
_25._tcp.example.mailhardener.com. If TLSA records are returned, its contents are extracted and stored. The sending SMTP service must also verify the DNSSEC chain here, to ensure the fetched TLSA record is authentic.
The sender connects to the SMTP service at
example.mailhardener.com, and issues the
STARTTLS command. In the following TLS handshake sequence, the SMTP service at
example.mailhardener.com responds with a certificate.
Finally, the sender will verify that the certificate matches at least one of the TLSA DNS records, before continuing the TLS handshake. If the certificate does not match any of the TLSA DNS records, this is an indication that the SMTP service is not to be trusted. In that case the TLS handshake is aborted and the email will not be delivered.
rfc8460 SMTP TLS reporting is a reporting protocol used to report TLS related issues with SMTP. SMTP TLS reports contain the TLS authentication results as seen from the sender's perspective.
SMTP TLS reporting supports reporting DANE related failures, the following 3 DANE related failures can be expected in SMTP TLS reports:
||None of the TLSA records matched the certificate of the SMTP service.|
||This indicates that the recursive resolver was not returning any valid DNSSEC signed record|
||This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report.|
When DANE is used, it is highly recommended enabling SMTP TLS reporting for the domain, and using a report aggregation service such as Mailhardener to monitor for any TLS related email delivery issues.
Using DANE in combination with SMTP adds a trust anchor for the connecting party to authenticate the certificate. This can help against downgrade attacks, and Man-In-The-Middle attacks. DANE can also be leveraged as an effective certificate revocation method, in case a key is compromised.
The achieved result is similar to that when MTA-STS is used, except that with DANE trust is placed in the DNSSEC root keys, whereas with MTA-STS trust is placed in a Certificate Authority.
|Trust source||DNSSEC root keys||PKI Certificate Authority|
|Mechanism||DNS||HTTPS (DNS bootstrap)|
|PKI||Optional (but recommended)||Required|
|Certificate revocation||Possible||Not possible|
As with any form of certificate pinning, implementing DANE adds additional maintenance requirements. A certificate renewal, or key rotation will require updating (or rather: rotating) the TLSA records. Failure to do so may result in undeliverable email.
Another downside is that with DANE, more trust is now placed in DNSSEC, which many argue is not robust, nor cryptographically sufficient.
Finally, as with MTA-STS, DANE has a 'bootstrap' problem, it relies on a DNS record to discover the existence of a TLSA record. If an attacker can block the DNS query for the TLSA record (likewise the MTA-STS assertion record), the sender will not be aware of the DANE support of the service. In practice though, this kind of attack is very hard to perform, and DNSSEC NSEC3 should prevent this kind of attack from being practical.
Before adopting DANE for SMTP, considerations must be made whether the security benefits of DANE outweigh the risks.
DANE uses the TLSA DNS resource record, which is specified in rfc6698.
The TLSA DNS resource record contains 4 fields:
[usage] [selector] [matching type] [certificate association data]
3 0 1 370c66fd4a0673ce1b62e76b819835dabb20702e4497cb10affe46e8135381e7
The certificate usage field specifies which type of the certificate is represented in the Certificate Association Data field. In the DANE specification (rfc7671), slightly different names are used for the usage fields.
||PKI 'trust anchor' (CA root certificates)|
||PKI 'end-entity' (CA issued certificate)|
||DANE 'trust anchor' (root certificate)|
||DANE 'end-entity' (certificate)|
In rfc7671, section 5.1, the
DANE-EE (3) usage has been updated.
It states that with
DANE-EE (3) no domain-name validation should occur (and also no expiry date validation).
This makes it practical for SMTP services which accept email for a large number of domains to adopt DANE.
rfc7672 ('SMTP Security via Opportunistic DANE') specifies DANE usage in combination with SMTP.
Section 3.1.3 of rfc7672 explains why usage
PKIX-TA (0) and
PKIX-EE (1) should not be used with SMTP.
Hence, for SMTP in combination with DANE, only
DANE-TA (2) and
DANE-EE (3) should be used.
The selector field specifies which part of the certificate is represented in the Certificate Association Data field.
|0||Full certificate||The entire DER encoded certificate is used|
||Only the DER encoded public key of the certificate is used|
When using option 0, the TLSA record must be replaced every time the certificate is renewed or replaced.
When using option 1, the TLSA record must be replaced when the private key (and thus the public key) of the certificate owner changes. In a typical application, this is the key-pair that is created by the certificate owner during creation of the CSR.
The matching field specifies how the certificate should be matched to the Certificate Association Data field. This applies to the content specified in the Selector field.
|1||SHA2-256 hash digest|
|2||SHA2-512 hash digest|
In practice, option
0 is only practical in combination with a selector of type
SubjectPublicKeyInfo), due to the resulting size of the Certificate Association Data field.
DANE capable services are not required to support SHA2-512, so in practice, only option
1 (SHA2-256) should be relied on.
The fourth and final field in a TLSA DNS resource record contains the data as described in the 3 previous fields.
For example: if usage=1, selector=0 and match=1, then the Certificate Association Data field should contain the SHA2-256 hash digest of a full DER encoded certificate issued by a PKI CA.
Consider the following DNS record:
_25._tcp.mail.example.com. TLSA 3 1 1 (E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
We can decode this record as follows:
|DNS rr type||
|TLSA selector||subject public key (1)|
|TLSA match||SHA2-256 (1)|
|TLSA certificate association data||
tcpservice on port 25 (SMTP) at
Whenever a certificate is renewed (with
selector=0), or when a key is rotated, a new TLSA record must be published before the new certificate is installed, whilst keeping DNS propagation delays in mind.
Unlike for example with DKIM selectors, it is allowed for a DNS query to return more than one TLSA record. The receiver will accept the certificate if any of the TLSA records match. This allows for graceful rotation of the TLSA record.
The order of operation for rotating a TLSA record is as follows:
For SMTP services where TLS is applied (this only applies to inbound email), the certificate, and therefore the TLSA record, must be applied to the domain of the MX service.
example.com uses Microsoft 365 services. The
MX records for
example.com will point to the
*.onmicrosoft.com domain. The certificate presented by the Microsoft 365 SMTP service will be for
example.com. Hence, the certificates, and therefore the TLSA records are managed by Microsoft, not the customer.
So, third party SMTP providers that implement TLSA will place and manage the TLSA record under their own domain. The customer (which is you) should not have to perform any changes to their infrastructure.
For self-hosted (or on-premise) SMTP services, a TLSA record can be published to enable DANE certificate pinning, which protects DANE capable senders from man-in-the-middle attacks during delivery of email to your domain.
WARNING: Before adopting DANE, ensure that you understand the concepts of TLS certificate pinning. Also ensure that proper monitoring and procedures are in place to ensure that the certificates remain valid, and the TLSA records match the certificates. Failure to do so may result in email delivery failures.
Step 0: Ensure the SMTP services serve a valid certificate.
Step 1: Choose with kind of selector you want to use:
|0 (full certificate)||Allows for effective revocation of a certificate||TLSA must be renewed with each certificate renewal|
|1 (subject public key)||No TLSA record update required on certificate renewal (unless key is changed)||TLSA record renewal may be forgotten on eventual key rotation|
Step 2: Generate the TLSA record value, using
# When using selector=0 (Full Certificate) on the certificate: openssl x509 -in certificate.pem -outform DER | sha256sum # When using selector=1 (SubjectPublicKeyInfo) on a certificate: openssl x509 -in certificate.pem -pubkey -noout | openssl rsa -pubin -outform der | sha256sum # When using selector=1 (SubjectPublicKeyInfo) on the private key: openssl rsa -in private.pem -pubout -outform DER | sha256sum # When using selector=1 (SubjectPublicKeyInfo) on the public key: openssl rsa -pubin public.pem -outform DER | sha256sum
See also: how to create a DANE TLSA record with OpenSSL
Step 3: Create the TLSA record, the full TLSA record should be in the format:
[usage] [selector] [matching type] [data]
3 0 1 370c66fd4a0673ce1b62e76b819835dabb20702e4497cb10affe46e8135381e7
Alternatively, use a TLSA record generator to generate the TLSA record, for example https://www.huque.com/bin/gen_tlsa.
In the generator, choose usage=3 (
DANE-EE) and match=1 (
Note: it is safe to upload a certificate file to an online calculator, certificate files do not contain any secrets. Never upload a private key!
Mailhardener has now fully integrated DANE/TLSA support in the Mailhardener Dashboard application.
Mailhardener customers can use Mailhardener to monitor the TLSA status of their inbound email, as well as using SMTP TLS reporting to monitor for TLSA failures.
Mailhardener also offers a free to use DANE/TLSA validator tool.
DANE is an ambitious protocol originally aimed to replace the PKI by moving the chain-of-trust to DNSSEC. DANE has been subject to critique from security professionals, as DNSSEC is said to lack robustness and cryptographic strength.
Fortunately, DANE can also be used to augment, rather than replace, the PKI in the form of certificate pinning via the TLSA DNS record. Certificate pinning can be an effective email hardening technique for SMTP services to protect against man-in-the-middle and (to a certain extent) TLS downgrade attacks.
On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.
You can also follow and reach us on Twitter @Mailhardener.