What is DANE and how TLSA records secure email in transit

DANE publishes your mail servers' certificate fingerprints in DNS, anchored by DNSSEC, so a sending server can verify it's talking to the real server before handing over a message.

Opportunistic TLS for email has a weakness: a sending server has no trusted way to know which certificate your mail server should present, so an attacker can downgrade or impersonate the connection. DANE fixes that by pinning the expected certificate in DNS and protecting it with DNSSEC. This guide explains what DANE is, how TLSA records work, where it breaks, and how SecRift checks yours.

What is DANE?

DANE stands for DNS-Based Authentication of Named Entities. For email, it lets your domain publish a fingerprint of the TLS certificate or public key that each mail server should present - directly in DNS, in a record type called TLSA.

When a sending server connects to one of your MX hosts, it looks up the TLSA record and checks that the certificate offered during the TLS handshake matches the published fingerprint. If it matches, delivery proceeds securely. If it doesn't, the sender refuses to deliver rather than risk an impersonated or downgraded connection.

The critical ingredient is DNSSEC. DANE only works on a signed zone, because the security of the fingerprint depends on the DNS answer being authentic. Without DNSSEC, an attacker could simply forge the TLSA record too.

How DANE works

DANE for SMTP, defined in RFC 7672, builds on records you publish per mail server:

• A TLSA record is published at a name derived from the MX host and port - for example _25._tcp.mx.example.com. It encodes a fingerprint of the certificate or public key the server will present.
• The record has three parameters: a usage (how the certificate is anchored), a selector (whether the fingerprint covers the full certificate or just its public key), and a matching type (the hash used).
• DNSSEC signs the zone so the TLSA record can't be forged in transit.

On delivery, the sending server resolves your MX hosts, validates the DNSSEC chain, fetches the TLSA records, and compares the fingerprint against the certificate presented in the handshake. A match means the server is provably the right one. The presence of a DNSSEC-signed TLSA record also implies that TLS is mandatory - so a downgrade to plaintext fails.

Why DANE matters

Like MTA-STS, DANE defends mail in transit against downgrade and interception attacks. The difference is where trust is anchored: DANE roots it in DNSSEC rather than in the web certificate authority system and an HTTPS-hosted policy file. For domains that already run DNSSEC, that means no policy web server to maintain and no dependence on a sender correctly fetching an HTTPS file.

The two approaches are complementary. Many domains publish both - DANE for senders that validate DNSSEC, and MTA-STS for those that don't - so inbound mail is protected regardless of which mechanism the sender supports.

Common DANE mistakes

• No DNSSEC. TLSA records on an unsigned zone provide no real protection and are ignored by validating senders.
• Incomplete MX coverage. A TLSA record for some MX hosts but not others leaves the uncovered hosts unprotected.
• Stale fingerprints after renewal. Rotating a certificate without updating the TLSA record breaks delivery, because the fingerprint no longer matches.
• Weak parameters. Outdated matching types or selectors reduce the strength of the binding.
• Mismatched records. A TLSA fingerprint that doesn't match the certificate actually served causes secure senders to refuse delivery.

How SecRift checks DANE

SecRift inspects DANE across all of your mail servers and breaks the result into four findings:

• MX discovery - resolves your domain's MX hosts, the servers DANE needs to protect.
• DNSSEC coverage - confirms the zone is DNSSEC-signed, without which TLSA records carry no trust.
• TLSA coverage - checks that every MX host publishes TLSA records, so no server is left unprotected.
• TLSA parameters - evaluates the usage, selector, and matching type of each record for quality per RFC 7672.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix. SecRift only reads public DNS, so it sees exactly what a DANE-validating sender would.

DANE rests entirely on a signed zone, so a healthy DNSSEC setup comes first - and pairing it with MTA-STS covers senders that don't validate DNSSEC.

Run a free scan on any domain at secrift.com and see your DANE posture in seconds.