What is DANE?
DANE (DNS-Based Authentication of Named Entities) is a standard that lets a domain publish, in DNS, exactly which TLS certificate its servers should present — pinning that certificate so a client can reject any other. For email, DANE (RFC 7672) applies this to SMTP: it lets a receiving mail server prove it is talking to the right server over a properly encrypted connection, instead of settling for opportunistic encryption that can be silently downgraded.
DANE is published as TLSA records in DNS and depends entirely on DNSSEC — the records are only trustworthy because DNSSEC signs them.
The Problem DANE Solves
SMTP encryption is normally opportunistic. When one mail server delivers to another, it uses STARTTLS to negotiate TLS if the other side offers it — but if TLS isn't offered, or the certificate is invalid or self-signed, mail is usually delivered anyway in the clear. An on-path attacker can exploit this by stripping the STARTTLS offer (a downgrade attack) or by presenting their own certificate, and the sending server has no baseline for what a "correct" certificate should even look like.
DANE removes that ambiguity. By publishing a TLSA record, you tell sending servers: encryption is mandatory for my mail hosts, and here is the exact certificate (or public key) they must present. A downgrade or a substituted certificate then causes delivery to fail rather than silently succeed over an insecure channel.
How DANE Works
For SMTP, a TLSA record is published at a name derived from the mail host and port — for example _25._tcp.mx1.example.com for a mail server mx1.example.com listening on port 25. Each record carries three parameters:
- Usage — which certificate is being pinned (for SMTP/DANE, either a trust anchor or the end-entity certificate itself; usages 2 and 3 are the ones used in practice).
- Selector — whether the record matches the full certificate or just its public key.
- Matching type — whether the record stores the full value or a SHA-256/512 hash of it.
A common combination is 3 1 1: pin the end-entity certificate's public key as a SHA-256 hash. When a sending server delivers mail, it looks up the TLSA record over DNSSEC, connects with STARTTLS, and checks the presented certificate against the record. If it matches, mail flows over an authenticated, encrypted channel; if not, the sender treats delivery as failed. Because the whole scheme rests on the records being genuine, TLSA records that aren't DNSSEC-signed are ignored.
DANE vs MTA-STS
DANE and MTA-STS solve the same problem — enforcing authenticated TLS for inbound email — but with different roots of trust. DANE relies on DNSSEC to vouch for your TLSA records. MTA-STS relies on the web PKI and a policy file served over HTTPS, which means it works without DNSSEC but trusts certificate authorities instead. The two aren't mutually exclusive: many operators publish both, and pairing either with TLS-RPT gives you reporting on the TLS problems senders encounter.
DANE and DDMARC
DDMARC checks your domain's DANE posture in two ways. First, it verifies whether your MX hosts publish DNSSEC-signed TLSA records at all. Then it goes a step further with a live certificate match: a dedicated, off-cloud prober connects to your mail servers over SMTP and confirms that the certificate they actually present matches the TLSA record you've published. The result — including which certificate was matched — appears in your DNS health view alongside your DNSSEC status and the rest of your email authentication checks. Check your domain's email security posture to get started.
Frequently Asked Questions
Do I need DNSSEC to use DANE?
Yes. DANE's TLSA records are only trustworthy when they are DNSSEC-signed. Without DNSSEC, an attacker could forge or strip the records, so receiving servers ignore unsigned TLSA records entirely. DNSSEC is a hard prerequisite for DANE.
What is a TLSA record?
A TLSA record is a DNS record — published for SMTP at a name like _25._tcp.mx1.example.com — that pins the certificate or public key your mail server presents. It uses a usage, selector, and matching-type triplet (for example, 3 1 1), and sending servers compare the certificate offered during STARTTLS against it.
Should I use DANE or MTA-STS?
Both enforce authenticated TLS for inbound mail, with different roots of trust: DANE relies on DNSSEC, while MTA-STS relies on the web PKI and an HTTPS-hosted policy. If your zone is already DNSSEC-signed, DANE is a strong choice; if not, MTA-STS works without it. You can publish both, and many operators do.
Does DDMARC check DANE?
Yes. DDMARC checks whether your MX hosts publish DNSSEC-signed TLSA records and performs a live certificate match — connecting to your mail servers over SMTP to confirm the certificate they present matches your published TLSA — and reports the result in your DNS health view.