DANE for email explained: TLSA records and DNSSEC

DANE (DNS-based Authentication of Named Entities) lets a domain publish, in DNS, exactly which TLS certificates its mail servers use. A sending server that supports DANE looks up TLSA records for the destination MX, and if they exist, delivery must use TLS with a certificate matching the pinned data, no fallback, no downgrade. The trust chain runs through DNSSEC rather than certificate authorities, which makes DANE the cryptographically stronger sibling of MTA-STS, and the one with the steeper entry requirement.

How it works

A TLSA record decodedRFC 1035

TXT / SPFMX / PTRA / AAAACNAME / NS / other

_25._tcp.mx1.example.com. INTLSA3 1 1 2abf...9c04

_25._tcp port and protocol the pin applies to

3 usage: DANE-EE, pin the end-entity certificate itself

1 selector: match the public key, not the whole certificate

1 matching type: compare SHA-256 hashes

2abf...9c04 the hash senders must find in the TLS handshake

"3 1 1" is the recommended combination for SMTP: it survives

CA changes and renewals that keep the same key pair.

The sender's procedure: resolve the MX, query TLSA for _25._tcp on each MX hostname, and require DNSSEC-valid answers. If usable TLSA records exist, the TLS handshake must produce a certificate matching the pin, and failure means the mail queues rather than delivering insecurely. Because the records are DNSSEC-signed, an attacker cannot strip or forge them without breaking validation, which removes the trust-on-first-use window and the CA system from the threat model in one move.

DANE vs MTA-STS, honestly

The two transport-security policies

Feature	DANE	MTA-STS
Trust anchor	DNSSEC chain	HTTPS certificate (web PKI)
Prerequisite	Signed zone, DNSSEC operations	A web server and a TXT record
First-contact protection	Immediate, no cache needed	After first successful policy fetch
Notable enforcing senders	Microsoft (outbound), European providers, government mail	Gmail, Microsoft (outbound)
Failure mode risk	Stale TLSA after certificate change, DNSSEC expiry	Lapsed policy-host certificate, stale mx list

They are complements, not rivals: publish both where DNSSEC is available, and DANE-aware senders prefer the stronger mechanism while everyone else uses MTA-STS. Both report through the same TLS-RPT channel, whose policy-type field attributes failures to the right mechanism, so the monitoring investment covers the pair. Microsoft's outbound enforcement of DANE and the mandates in Dutch and German public-sector standards are why the mechanism, long a niche, keeps gaining ground in Europe.

Deploying without incidents

DANE rollout

1
Get DNSSEC solid first
Signed zone, automated re-signing, registrar DS records verified, and monitoring on signature expiry. Run it stable for a while before adding pins.
2
Publish 3 1 1 TLSA records per MX
Pin the public key hash of each MX host's certificate at _25._tcp.<mx-hostname>, and prefer key pins that survive certificate renewals.
3
Coordinate pins with certificate rotation
The operational discipline: publish the new key's TLSA alongside the old before any certificate change, wait out TTLs, switch, then remove the old pin. A renewal that changes keys without this dance breaks DANE-enforcing senders.
4
Verify and watch
Test with a DANE validator (posttls-finger, online checkers), then let TLS-RPT confirm real senders succeed. Failures attributed to policy-type tlsa are your alarm.

Frequently asked questions

Should I deploy DANE or MTA-STS first?

MTA-STS first for nearly everyone: it needs no DNSSEC and Gmail honors it. Add DANE when your DNS operations are ready for DNSSEC, or when your receivers (European public sector, Microsoft-heavy B2B) reward it.

Does DANE do anything for the mail I send?

Publishing TLSA records protects inbound mail. On the outbound side, your MTA can validate other domains' DANE (Postfix supports it natively with a validating resolver), which protects what you transmit to DANE-enabled destinations.

What happens if my TLSA record goes stale after a certificate change?

DANE-enforcing senders fail to validate and queue or bounce their mail while everyone else delivers normally, a partial outage that is confusing to diagnose. Pinning public keys (3 1 1) and rotating pins alongside keys prevents it.

Is DANE relevant on hosted mail like Google Workspace or Microsoft 365?

Your MX targets are their hostnames, and TLSA records for their infrastructure are theirs to manage, not yours to pin. Hosted-mail domains generally get their transport security via the host plus MTA-STS instead.

Key takeaways

DANE pins MX certificates in DNSSEC-signed TLSA records, removing downgrade attacks and the CA system from the threat model
The 3 1 1 record form (end-entity, public key, SHA-256) is the SMTP standard and survives same-key renewals
DNSSEC is the real adoption barrier, and casually run DNSSEC is its own outage risk
Publish alongside MTA-STS where possible; both report through TLS-RPT, and capable senders prefer DANE
Certificate rotations must carry the TLSA pins along, or DANE-enforcing senders lose delivery to you