Set up DANE for SMTP: TLSA records and DNSSEC for your mail server

What it means

By default, servers that deliver email to you use TLS (STARTTLS) only "if possible", and they do not check your certificate. An attacker on the network could remove STARTTLS or present a fake certificate. DANE for SMTP (RFC 7672) closes that gap: you publish a TLSA record in DNS that says which certificate or key your mail server uses, and DNSSEC proves that record is genuine. Sending servers that support DANE then refuse to deliver without valid, matching TLS.

A TLSA record for a mail server is published at _25._tcp. followed by the MX host name:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 8f1c...e4a2

The three numbers mean: 3 = the server's own certificate (DANE-EE), 1 = match the public key only (not the whole certificate), 1 = SHA-256 hash. 3 1 1 is the usual choice for SMTP.

DANE and MTA-STS solve the same problem in different ways. MTA-STS uses HTTPS and works without DNSSEC; DANE needs DNSSEC. You can publish both, and use TLS-RPT (covered in the MTA-STS guide) to receive reports for both.

Why it happens

You may be setting up DANE because:

• a security audit, a government or sector rule, or an internet.nl-type test asks for it (common in the Netherlands and Germany);
• you want inbound mail protected from downgrade attacks;
• a DANE test reports that your TLSA record does not match after a certificate renewal, which makes DANE senders stop delivering to you.

How to check

1. DNSSEC: the zone of your MX host name must be signed. With dig, look for the ad flag from a validating resolver:

   dig +dnssec MX yourdomain.com @1.1.1.1
   ;; flags: qr rd ra ad;

   If the MX points to your provider's host (Google, Microsoft 365...), it is their zone that needs DNSSEC and TLSA, not yours.
2. TLSA record:

   dig +dnssec TLSA _25._tcp.mail.yourdomain.com

3. Compare with the live certificate:

   openssl s_client -connect mail.yourdomain.com:25 -starttls smtp \
     -servername mail.yourdomain.com </dev/null 2>/dev/null \
     | openssl x509 -noout -pubkey \
     | openssl pkey -pubin -outform DER | openssl dgst -sha256

   The hash must equal the last field of the TLSA record.
4. Postfix tool: posttls-finger -t30 -T180 -c -L verbose,summary yourdomain.com shows whether DANE validation succeeds.
5. Use the domain scanner to confirm your MX host names before you start.

How to fix it

1. Enable DNSSEC

Turn on DNSSEC at your DNS host, then add the DS record at your registrar (many do it automatically). Check with Whois which registrar manages the domain. Without a valid DNSSEC chain, TLSA records are ignored.

2. Get the hash of the server key

On the mail server, from the certificate file in use:

openssl x509 -in /etc/ssl/mail/fullchain.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

3. Publish the TLSA record

Host:  _25._tcp.mail      (for MX host mail.yourdomain.com)
Type:  TLSA
Usage: 3   Selector: 1   Matching type: 1
Value: <the SHA-256 hex hash>

Publish one record per MX host name. The certificate should still be a normal valid certificate whose name matches the host, so non-DANE senders and MTA-STS keep working.

4. Plan certificate renewals

This is where most DANE setups break. With 3 1 1 the hash follows the key, not the certificate, so:

• Renew certificates while keeping the same private key (for example Certbot's --reuse-key option), or
• Use a "current + next" scheme: generate the next key in advance, publish a second TLSA record for it, wait at least two TTLs, then switch the server to the new key, and remove the old record later.

5. Validate DANE when you send (optional)

If you run Postfix and a DNSSEC-validating local resolver, enable DANE for outbound mail in main.cf:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

For TLS basics on your own server, see emails sent without TLS.

Check that it is fixed

Wait for DNS caches to expire, then rerun dig +dnssec TLSA (it should come back with the ad flag), compare the hash with the live certificate, and run posttls-finger again. Send an email from an external mailbox to your domain and check the mail log for a TLS connection. Run a Delivmail test from your server too, to confirm sending still works. Recheck after each certificate renewal.