As of 2019, email is still generally transmitted without proper transport encryption. DANE is a standard that has the potential to make widespread email transport encryption a reality. Halon, the MTA for service providers, have supported DANE since 2015.

DANE for SMTP does not only provide a trust scheme (like the certificate authority system) using DNSSEC, but also the means to know if a domain supports encrypted email transfer. Halon supports DANE since 2015.

How it works

DANE is only available over DNSSEC, and uses the TLSA record type. An email server (MTA) only needs to make one extra DNS query to use DANE, namely

$ dig freebsd.org mx +short
10 mx1.freebsd.org.
$ dig _25._tcp.mx1.freebsd.org tlsa +short
3 1 1 0A7E2F469913EA64CA98AF...

and the server's certificate is compared against the DNS record. The output (logs) from a Halon system with and without DANE look like

smtp_lookup_rcpt(["host" => "lookup-mx", "tls"=>"dane"], "", "[email protected]"); // DANE
smtp_lookup_rcpt(["host" => "lookup-mx", "tls"=>"dane"], "", "[email protected]"); // Insecure

Connecting to [2001:1900:2254:206a::19:1]:25 (DNSSEC)
X.509: /OU=Domain Control Validated/OU=Gandi Standard...
DANE: validated successfully
Connection is now using TLS
Connecting to [2a00:1450:4010:c06::1b]:25
DANE: insecure name gmail.com (falling back to optional TLS)
X.509: /C=US/ST=California/L=Mountain View/O=Google Inc...
X.509 error: unable to get local issuer certificate (20)
Connection is now using TLS

Halon's DANE implementation is based on the OpenSSL's DANE functions. Outbound SMTP connections are handled by our DANE-enabled SMTP client, which is used by both standard functions such as smtp_lookup_rcpt() as well as the queue process and its corresponding pre-delivery context.


DANE is proposed in RFC 6698 by Hoffman and Schlyter as an alternative to CAs (ICANN) . The CA system has been subject to criticism (Schneier, Wikipedia) during the last years, following compromise and mishaps of several major CAs (Ars Technica, The H Security, The Register, Ars Technica) . To make things worse, the revocation systems doesn't work very well in practice (ImperialViolet, Netcraft, Netcraft) . DANE builds on DNSSEC which provides a hierarchal scheme (the root, TLDs, domains and so on), as opposed to the flat CA system where any trusted CA can issue a certificate in the name of anyone.

As always, there are arguments for and against. While a hierarchal system sure is preferable, the transfer of control and responsibility to the DNS system's owners (governments, DNS admins) is a topic much discussion. There's also work to improve the CA system with supplementary techniques such as key pinning (ImperialViolet, TACK) and added perspective. Nevertheless, DANE stands strong to improve the security in many areas, such as email.

Postfix was probably the first email server to support RFC 7672 (DANE for SMTP), and Exim followed. The fact that those two are the most widely used SMTP servers, and the somewhat strong (APNIC, Internet Society) DNSSEC adoption, is a solid foundation for DANE.

How to enable DANE

It's fairly simple to start using DANE, and even if your domain doesn't use DNSSEC, we encourage you to enable DANE verification in your MTA right away. If your are a service provider you might want to look at our DANE bypass list.

In order to allow others to send DANE verified email to your server, you domain needs to be DNSSEC signed. In theory, it's no more difficult than publishing your SMTP servers' certificate signatures as TLSA records in your DNS using the same name as the MX points at, but prefixed with _25._tcp. As usual, everything's a bit more complicated in practice. The full certificate fingerprint (used with 3 0 1) can be extracted with

openssl x509 -noout -fingerprint -sha256 < path-to-cert | tr -d :

or you can use Huque's TLSA generator. The result should look like:

         mx1.freebsd.org.  IN  A
_25._tcp.mx1.freebsd.org.  IN  TLSA  3 0 1 2B73BB905F...
Are you operating email services?