If you made your domain names secure with DNSSEC, you may then use your domains as a foundation to secure other services, including email; thus, if you are not already familiar with it, we recommend you to read the page about DANE before proceeding.
As with any recent standard, deployment is only in its infancy – but it is steadily growing, and many sources now recommend DANE as the best way to authenticate servers over the Internet. Also, you do not need to install any software or add any message processing to authenticate your mail server with DANE; you just need to add a DNS record.
For each server, you need to start from the TLS certificate that it is using for STARTTLS, to encrypt the email traffic that it receives; even a self-signed certificate is ok. You then need to extract a hash of this certificate and use it to create a TLSA record. There are several ways to do it, and some recent mail server applications will do this for you, but you could also use this free TLSA record generator: as you only need to publish your public certificate or key, and not the private key, it is safe to use an external source for processing it.
For this purpose, you need to generate a DANE-EE (usage field = 3) TLSA record; we also recommend to use some hashing for the match (SHA-256 or SHA-512, usually the first). You will have to decide whether to publish the entire certificate or only the public key, by setting the selector field to 0 or to 1; this depends on your certificate rollover policy (we will discuss that later).
Once you generate your “3 0 1” or “3 1 1” TLSA record in this way, you just have to publish it in your DNS zone, associating it to the hostname of the server using that key/certificate.
This means that you must have your certificate and your TLS encryption up and running on your server before publishing the record. Also, as per RFC 7672, the very act of publishing a valid TLSA record for your email server indicates that you are requiring any other server to only connect to it on encrypted connections: up-to-date email servers that support DANE authentication on delivery will not fallback to unencrypted or non-authenticated connections to your server, but will rather throttle or ignore it altogether.
To reduce the chances of losing email, many server operators willing to support DANE publish a second TLSA record for every server. This can be done by exploiting certificate usage 2, that allows you to publish a certificate or key that does not belong to your server, but to an authority that released your server’s certificate.
In case you are getting your certificates from an external certification authority, you need to get that authority’s certificate (usually a root certificate). In case you are self-signing your certificates, you should then create your own root keys and root certificate, and use them to sign the other keys and certificates that you will use for your email servers. In both cases, using the same mechanisms for TLSA record generation, you then have to use your root certificate to create and publish a “2 0 1” or “2 1 1” TLSA record for your server’s hostname.
In this way, even if the validation of the “3 0 1” or “3 1 1” TLSA record fails for whatever reason, the “2 0 1” or “2 1 1” record will match the root certificate as supplied by the server, which should be configured to use and provide the full chain of certificates; and the DANE authentication will be successful.
Whenever you change the server’s public key or certificate, you will need to publish an updated TLSA record and allow it to propagate, before you are able to start using the new certificate in TLS connections; failure to do so will break your DANE authentication. This implies that the certificate rollover process needs time and care, especially as the technology is still in its infancy and many operations are not automated yet; but you still want to rollover your keys at regular intervals to prevent brute force attacks.
Also, if you choose to publish the additional “2 0 1” or “2 1 1” record, every time you or your certification authority roll over the public key used for the root certificate, you need to apply the same process to that as well, which may imply watching your certification authority carefully to get advance notice of any possible rollover – though, if the rollover happened for security reasons, it is unlikely that you would get advance notice.
To mitigate this impact, one of the possibilities is to use only “3 1 1” and “2 1 1” records instead of “3 0 1” and “2 0 1” ones; this will publish the public key, rather than the full certificate. If you rollover keys and certificates at the same time, this does not make any difference, but if you can rollover the certificate while keeping the same key, then you will be able to do a rollover without having to change the TLSA records.
Finally, as you publish your DANE certificate association to let others authenticate you before delivering email to you, you should also configure your own mail transfer agent to use DANE when delivering email to others.
To activate DANE for your own deliveries, your email server must be using a local DNSSEC-enabled name server to query and verify DNS records, so first you need to make sure about that.
Then, recent versions of many mail transfer agent applications will provide a DANE “client” implementation that you can enable in their configuration. The behaviour mandated in RFC 7672 is designed to cope with the gradual deployment of DANE; if a correct TLSA record is found, positively validated through DNSSEC (“usable”), either the DANE authentication is successful or the connection will be terminated; if TLSA records are found, but DNSSEC validation says that they are fake, or if any other lookup error happens, the connection will be terminated; if TLSA records are found, but they have invalid parameters or other errors (“unusable”), then this is taken as a signal that TLS is required but DANE authentication is not, and so any opportunistic encryption will do, but cleartext transmission will be refused; otherwise, if no TLSA records exist, or if they exist in a domain name not secured with DNSSEC, mail delivery will proceed as usual, either with opportunistic encryption or in cleartext. This policy will offer security while maintaining backward compatibility with servers not supporting DANE authentication.
To further increase security, you could manually create delivery tables that mandate DANE authentication for major destinations that certainly support it; this is actually what was done in the “Email made in Germany” effort.
As with any configuration change, after deploying outgoing DANE authentication you should keep an eye over your logs to check whether any new errors appear.
