The Simple Mail Transfer Protocol (SMTP) is used for mail transport between mail servers and is traditionally not secured, making it vulnerable for eavesdropping.

DNS-based Authentication of Named Entities (DANE) for SMTP provides a more secure method for mail transport and is increasingly becoming more popular. Domains with DANE records include comcast.net, debian.org, gmx.de and protonmail.ch.

Key points

• Even with the STARTTLS extension installed, SMTP is at risk of man-in-the-middle attacks.
• DANE assists with mitigating against such attacks. See our how-to for guidance regarding the implementation of DANE.
• DANE is meant to be published on the MX domain. So, if you are using another domain’s mail server, make sure to ask the administrator of that domain to support DANE by setting up one or more TLSA records.

Risks of opportunistic SMTP using STARTTLS

By default, mail transport happens in plain text. With the introduction of the STARTTLS extension, opportunistic security was added to the SMTP protocol. This means that mail transport between mail servers is only secured when the receiving mail server requests the sending mail server to use an encrypted Transport Layer Security (TLS) connection. This is illustrated in Figure 1.

Figure 1: While STARTTLS is considered an improvement compared to a classic unencrypted SMTP connection, it still leaves email transport susceptible to risks.

Although STARTTLS can encrypt mail transport, the encryption is not enforced and there is no authentication of the receiving mail server by the sending mail server. This leads to the following risks.

Risk 1: STRIPTLS / downgrade attack

First of all, a sending mail server has no means to determine beforehand if the receiving server supports encrypted transport. It’s only after the communication has begun that the sending server may learn from the features the receiving server supports (in this case STARTTLS) that it allows for encrypted transport.

As a result, the initial connection from one mail server to another always starts unencrypted making it vulnerable to man-in-the-middle (MITM) attacks. If a mail server does not offer the ‘STARTTLS capability’ during the SMTP handshake (because it was stripped by an attacker), transport of mail occurs over an unencrypted connection.

Figure 2: This illustration shows what happens when an attacker performs a MITM attack and forces an unsecure connection by stripping the TLS capability from the receiving email server. When an attacker controls the network communication between the sending and receiving servers, the attacker may downgrade the session by removing the information that indicates the receiving server supports encrypted transport. The sending server would proceed and transport the message unencrypted making all data contained in the message visible to the attacker.

Risk 2: Divert mail traffic to attacker’s mail server

Secondly, mail servers by default do not validate the authenticity of another mail server’s certificate; any random certificate is accepted. While the delivery of mail was traditionally considered to be more important than the security of mail, from a more technical perspective it was unclear which names to verify in the certificate.

Hostnames for mail servers are obtained via DNS Mail eXchanger (MX) lookups, but without DNSSEC, these names cannot be trusted. As a result, an attacker can insert any random certificate into the connection process.

Figure 3: The illustration shows what happens when an attacker performs a MITM attack and inserts his/her own certificate into the connection process. This enables the attacker to unencrypt the traffic between the sending and receiving mail server.

In need of a more secure mail transport

Research and incidents have shown that these attacks are not theoretical but are happening  in daily practice leading to the leakage of information. We need a more secure mail transport method in order to neutralise an attacker’s attempt to defer and/or tamper mail transport. This is where DANE for SMTP comes in.

DANE for SMTP (RFC 7672) uses the presence of DNS TLSA resource records to securely signal TLS support and to publish the means by which sending mail servers can successfully authenticate legitimate receiving mail servers. This makes the secure connection resistant to downgrade and MITM attacks.

The previously described risks of SMTP with opportunistic TLS can be mitigated by using DANE. This is illustrated in Figure 4, which shows mail transport using DANE.

Figure 4: This illustration shows that the presence of a DNS TLSA record for the receiving domain’s mail server is interpreted by the sending mail server as the capability to use TLS. The use of TLS can therefore be forced when communicating with the receiving domain’s mail server. The fingerprint embedded inside the TLSA record can be used to verify the receiving mail server’s certificate. Receiving servers with published TLSA records, are therefore no longer vulnerable to the afore mentioned MITM attacks, given DANE verification by senders.

When using DANE, it is a best practice for the sending mail server to abort the connection and try another server or defer the message whenever the certificate does not validate.

For those wondering about MTA-STS as an alternative to DANE: this relatively new method seems mostly suitable for the large cloud mail providers, is not adopted as widely as DANE, and is considered less secure than DANE because of trust-on-first-use and caching, which is acknowledged in RFC 8461. However, you can use it next to DANE since both standards can intentionally co-exist next to each other.

Tips and tricks for implementing DANE

If you’re planning on implementing DANE, here a couple of tips and tricks.

Getting started

First publish DANE records on your MX domains or ask your mail provider to do so.

The next step is to enable DANE verification on your sending mails servers (or ask your provider/vendor to enable or implement it). Our how-to might be useful for these steps.

Note: DANE is backwards compatible. So, if your mail server supports DANE and a connecting mail server does not support it yet, usually STARTTLS or plain text still will be used.

Publishing DANE records

• DANE is meant to be published on the MX domain. So, if you are using another domain’s mail server, make sure to ask the administrator of that domain to support DANE by setting up one or more TLSA records.
• Another thing to be mindful of is that DANE relies on the security that is provided by DNSSEC. Make your primary domain and MX domain support DNSSEC before implementing DANE.
• Note: DNSSEC tooling has matured a lot and is fully automatable. Furthermore, DNSSEC is supported by many DNS providers including some of the bigger players.
• Purchasing of expensive certificates for mail servers has no or little added value for confidentiality since mail servers don’t validate certificates by default.
• It is recommended to use a certificate’s public key for generating a TLSA signature (selector type ‘1’) instead of the full certificate (selector type ‘0’), because this enables the reuse of key materials. Although it is wise to refresh your key material once in a while, note that the use of Forward Secrecy decreases the need to use a new key-pair on every occasion.
• An issuer certificate (usage type ‘2’) validates only when the full certificate chain is offered by the receiving mail server.
• Make sure the time-to-live (TTL) of your TLSA records is not too high. This makes it possible to apply changes relatively fast in case of problems. A TTL between 30 minutes (1,800 seconds) and 1 hour (3,600 seconds) is recommended.
• A TLSA record identifies a certificate. If the certificate is replaced with a new one, the associated TLSA record also needs to be updated in time. Otherwise there will be a mismatch, verification will fail, and DANE-aware servers will not send messages to the receiver’s domain. DANE allows you to publish multiple TLSA records to overcome this problem. By using multiple TLSA records you can create a rollover scheme.
• Implement monitoring of the validity of your DANE records.

Verifying DANE records

• More and more mail server software (like Postfix, Exim, Cloudmark, Halon, Cisco and PowerMTA) support DANE verification. If you are using this type of software you can enable DANE verification.
• Make sure you keep an eye on the logs of your sending mail server to see what domains fail DANE verification. 
• Some software allows for a test mode. This means that DANE verification is done and logged but there’s no consequence for delivery if DANE verification fails. 

Support by mail providers

DANE is supported by an increasing number of mail providers, like Comcast, GMX, Mailbox.org, One.com, Posteo and XS4ALL. DANE is not supported yet by Microsoft Office 365. However, on the Office 365 UserVoice Forums, the feature request for DNSSEC and DANE is the second most popular in the category “Security & Compliance”. Google already offers alternative DNSSEC-signed MX hosts for G Suite (mx[1-4].smtp.goog) that a user can configure. There is also a request for DANE on Google’s feature ideas platform that G Suite users can support.

Test your own domain

You can test if your domain’s mail server supports DNSSEC and DANE using our free service, Internet.nl or this free DANE SMTP Validation tool.

If you are interested in learning more tips and tricks on implementing DANE, please take a look at our DANE for SMTP how-to. Feel free to contribute!

Contributors: Special thanks to Bart Knubben, who works for the Dutch Standardisation Forum for his contributions to this blog.