# DANE and DNSSEC for Email: SMTP Encryption Guaranteed by DNS
Table of Contents
In the article on STARTTLS stripping we saw that between mail servers encryption stays opportunistic and an attacker can make it disappear. MTA-STS answers with a file over HTTPS and public CA certificates. DANE (DNS-based Authentication of Named Entities) answers differently: DNS, signed with DNSSEC, declares which certificate the mail server must present, and by its very presence signals that encryption is mandatory.
For email DANE is defined in RFC 7672 (SMTP Security via Opportunistic DANE TLS). It does not rely on trust on first connection, but it requires DNSSEC.
Two ingredients: DNSSEC and TLSA
DNSSEC adds cryptographic signatures to DNS: whoever queries can verify that an answer is authentic. RFC 7672 is blunt on this point: without DNSSEC the MX lookup is vulnerable to man-in-the-middle and cache poisoning attacks, and without DNSSEC the server's certificate cannot be verified securely.
A TLSA record associates a certificate or public key with a service (host and port). For a receiving mail server the record name is built from the port and the MX host name:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <SHA-256 fingerprint of the public key>The three numbers are (RFC 7671):
- 3 (DANE-EE): the server's own certificate is matched directly against the record, without going through a CA.
- 1 (SPKI): the fingerprint covers only the public key (SubjectPublicKeyInfo), not the whole certificate.
- 1 (SHA-256): the fingerprint algorithm.
RFC 7672 recommends exactly the 3 1 1 combination for email, and discourages records with certificate usage 0 and 1 (PKIX-TA and PKIX-EE). RFC 7671 adds that the key-only fingerprint does not change when a certificate is renewed with the same key, and that with DANE-EE the certificate's expiry date is ignored: validity comes from the record's DNSSEC signatures.
The fingerprint is computed from the certificate in use (command tested on a test certificate):
openssl x509 -in cert.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 -binary | xxd -p -c 64The result, 64 hexadecimal characters, goes in the last field of the record.
A real example
The mx.ietf.org server publishes two signed TLSA records (checked on 31 October 2026 with dig +dnssec TLSA _25._tcp.mx.ietf.org):
_25._tcp.mx.ietf.org. 295 IN TLSA 3 1 1 E3008A5C0BC1E088..._25._tcp.mx.ietf.org. 295 IN TLSA 3 1 1 292481EEE04F9F5C..._25._tcp.mx.ietf.org. 295 IN RRSIG TLSA 13 5 300 ...The RRSIG record is the DNSSEC signature. Values are truncated here for readability.
How it protects against stripping
A sender that supports DANE, before delivering, looks up the MX host's TLSA while validating DNSSEC:
- If a correctly signed TLSA exists, RFC 7672 requires that the sender never delivers unless a TLS session was negotiated with STARTTLS. An attacker who deletes
STARTTLSfrom the server's capabilities gets a refusal, not a plaintext delivery: the same signed record proves the server supports TLS. - If the DNS result is "insecure" (the zone is not signed), DANE does not apply and things stay at the previous opportunistic encryption.
- If DNSSEC validation fails, the RFC says delivery must be delayed.
That last point is also the main risk, as we see below.
How to publish DANE for inbound mail
- Sign with DNSSEC the zone that contains the MX host name.
- Publish the TLSA
3 1 1for each MX host. - Check that the record is signed:
dig +dnssec TLSA _25._tcp.mail.example.comIf the zone is signed, the answer also contains the RRSIG record for the TLSA. To see what happens from a sender's side, Postfix includes posttls-finger: its documentation lists -l dane to use the DANE level, -c to show only TLS information and -L summary for a one-line summary:
posttls-finger -c -l dane -Lsummary mail.example.comIf your mail is hosted by a provider, the records are those of the provider's MX host name. Exchange Online, for example, supports DANE for inbound mail with DNSSEC: according to Microsoft's documentation, the domain needs DNSSEC enabled and a new MX record pointing to a host ending in mx.microsoft, while the TLSA record is provisioned by Exchange Online.
The golden rule: key rotation
The TLSA contains the fingerprint of the key. If the certificate is renewed with a new key and the record is not updated, your server no longer matches what is published and DANE senders do not deliver. Certbot's documentation is clear: by default Certbot generates a new private key at every renewal.
There are two correct ways:
- Reuse the same key at every renewal. Certbot has the
--reuse-keyoption ("When renewing, use the same private key as the existing certificate"). The3 1 1fingerprint stays valid. - Publish the new key's record before using it. RFC 7672 requires publishing two TLSA records (the current key's and the new one's) before using the new key; RFC 7671 specifies doing so at least two TTLs before deploying it. Once the new key is in use, remove the old record.
With certificates expiring ever sooner, down to 47 days, this step must be automated.
Operational risks
- Invalid DNSSEC. If for any reason DNSSEC validation fails, RFC 7672 requires senders to delay delivery. You need monitoring on signature validity.
- TLSA published for a host that does not offer STARTTLS. The RFC forbids delivery without a negotiated TLS session: the mail does not arrive.
- MX host name in an unsigned zone (for example a provider's): DANE does not apply.
- TTLs that are too high on TLSA records. RFC 7671 recommends TTLs short enough to limit unplanned disruption, because resolvers holding stale records can make deliveries fail after an unplanned key change.
DANE or MTA-STS?
| MTA-STS | DANE | |
|---|---|---|
| Requires DNSSEC | No | Yes |
| How the server is verified | certificate signed by a trusted CA, matching name | fingerprint published in signed DNS (with 3 1 1, no CA) |
| First connection | not protected (the policy must be obtained first) | protected, because DNSSEC can prove a record does not exist |
| What to publish | two DNS records and a file over HTTPS | signed zone and TLSA records |
They are not mutually exclusive: Exchange Online, for example, documents support for both DANE and MTA-STS. Further reading: MTA-STS.
In short
DANE uses DNSSEC to make DNS declare which key the mail server must present; the presence of the signed record makes encryption mandatory for senders that support it, without going through public CAs and without the first-connection limit. The price is managing DNSSEC and keys: a badly done rotation or invalid signatures make mail delivery be delayed.
