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.
DANE is only available over
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
$ 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
Halon's DANE implementation is based on the OpenSSL's
Outbound SMTP connections are handled by our DANE-enabled SMTP client,
which is used by both standard functions such as
as well as the queue process and its corresponding
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.
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
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 126.96.36.199 _25._tcp.mx1.freebsd.org. IN TLSA 3 0 1 2B73BB905F...