DANE (DNS-Based Authentication of Named Entities) lets you publish a fingerprint of your mail server's TLS certificate directly in DNS, so a sending server can verify the certificate before it hands over any mail. For SMTP you do this with a TLSA record at _25._tcp.<your-mx-hostname>, and the whole thing only works if that DNS zone is signed with DNSSEC. Get the order right and you stop attackers from stripping STARTTLS or substituting a rogue certificate on inbound mail.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
DANE is defined in RFC 6698, with the SMTP-specific rules in RFC 7672. The single most important thing to understand before you touch a record: DANE is only as trustworthy as DNSSEC. Without a valid signature chain, a TLSA record is just bytes an attacker can rewrite. That is why the build order below starts with DNSSEC and does not skip it.
Why DANE exists and when to use it
STARTTLS on port 25 is opportunistic by design. A sending server asks "do you support TLS?" and if the answer is stripped by a man-in-the-middle, delivery quietly falls back to plaintext. There is no certificate authority check either, so even when TLS is negotiated, a self-signed or forged certificate is usually accepted. That is the gap DANE closes.
DANE gives you two guarantees at once. First, it signals that TLS is mandatory for your MX host, so a downgrade to plaintext becomes a hard failure instead of a silent fallback. Second, it pins the exact certificate or key the sending server must see, so a substituted certificate is rejected. Because the pin lives in DNSSEC-signed DNS, it cannot be forged without breaking the signature chain.
DANE competes with, and complements, MTA-STS. MTA-STS uses the web PKI and an HTTPS-hosted policy file, so it works without DNSSEC but trusts certificate authorities. DANE needs DNSSEC but does not trust CAs at all. Many mature senders publish both. For a side-by-side decision, read MTA-STS vs DANE.
Step 1: confirm DNSSEC is signed end to end
This is the step that trips up almost every first attempt. It is not enough that your registrar shows a green DNSSEC toggle. The signature chain has to be complete from the root down to the exact hostname carrying the TLSA record, which is your MX target, not just your organizational domain.
Two zones must be validated:
- The domain that holds your MX record (for example
example.com). - The zone that holds the MX hostname itself (for example
mail.example.com, which may be a delegated subdomain or even a different domain entirely).
If your MX points to a hostname whose zone is not signed, DANE is dead on arrival no matter how perfect your TLSA record is. Check the chain with a validating resolver:
dig +dnssec mail.example.com A
Look for the ad (Authenticated Data) flag in the response header. No ad flag means the answer was not validated, so fix DNSSEC before going further. You can also confirm the DS record is present at the parent by querying dig DS example.com and checking your registrar published it. A signed zone with no DS record at the parent is unvalidated.
Step 2: generate the TLSA hash from your live STARTTLS certificate
Pull the certificate your server actually presents on port 25, not a copy from a control panel. Use OpenSSL against the running service:
openssl s_client -connect mail.example.com:25 -starttls smtp \
-servername mail.example.com < /dev/null 2>/dev/null \
| openssl x509 -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -binary \
| xxd -p -u | tr -d '\n'
That command extracts the certificate, isolates the SubjectPublicKeyInfo, and produces a SHA-256 hash of it. The uppercase hex string it prints is the data field for your TLSA record. Hashing the public key (selector 1) rather than the full certificate (selector 0) is the durable choice, because renewing a certificate with the same key pair does not change the record.
Step 3: choose usage, selector, and matching type
A TLSA record has four fields: usage selector matching-type data. For SMTP, RFC 7672 restricts you to two usages, and the rest of the choice follows.
Usage: 3 (DANE-EE) versus 2 (DANE-TA)
- Usage
3, DANE-EE, pins the end-entity certificate or key directly. The sending server matches your server's leaf certificate against the record and ignores the CA chain entirely. This is the recommended default for almost everyone because it is simple and does not care whether your certificate is publicly trusted. - Usage
2, DANE-TA, pins a trust anchor (an intermediate or private CA). The leaf must chain up to that anchor. Use this only if you run your own CA or rotate leaf certificates frequently under a stable intermediate.
Usages 0 and 1, which layer on top of the public PKI, are not used for SMTP DANE. Do not publish them.
Selector and matching type
- Selector
1selects the SubjectPublicKeyInfo (the public key). Selector0selects the full certificate. Prefer1so certificate renewals with the same key do not break DANE. - Matching type
1is SHA-256, which is what the OpenSSL command above produced. Matching type2is SHA-512, and0means the full data with no hash. Use1.
So the standard record almost everyone should publish is 3 1 1 followed by the hash.
Step 4: publish the TLSA record at _25._tcp
The record name is built from the port and protocol prefixed to the MX hostname. For port 25 over TCP on mail.example.com, the owner name is _25._tcp.mail.example.com. Publish it in the zone that actually controls that hostname:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <64-char-sha256-hex>
If you have more than one MX host, each one needs its own TLSA record at its own _25._tcp name. A common and recommended practice is to publish two TLSA records per host during a certificate rollover: one for the current key and one for the incoming key, so validation never has a gap. This mirrors the overlap approach in a DKIM key rotation schedule and is the safe way to change keys under DANE.
Step 5: validate before you trust it
Never assume a published record works. Query it and confirm both the data and the DNSSEC validation:
dig +dnssec _25._tcp.mail.example.com TLSA
Confirm the ad flag is set and the hash matches what you generated. For a full end-to-end test that actually opens an SMTP connection and checks the certificate against the record, use a DANE validator such as the Sys4 dane-check tool or an online DANE SMTP checker. A green result there means a sending MTA like Postfix with smtp_tls_security_level = dane will enforce your pin.
You can point SPFWise at your domain to confirm the surrounding posture (DNSSEC signed, MX reachable, TLS present) is healthy before and after you add DANE.
The gotcha that breaks most first attempts
The number one failure is a mismatch between the certificate the server presents and the hash in DNS. This happens most often when your certificate auto-renews (for example via Let's Encrypt) with a fresh key pair, and nothing updates the TLSA record. The moment the new certificate goes live, every DANE-enforcing sender rejects your mail because the pin no longer matches.
The fix is process, not a single record. Either renew with the same key each cycle, or automate a rollover that publishes the new 3 1 1 hash, waits for TTL expiry, swaps the certificate, then removes the old record. Treat the TLSA record as part of your certificate lifecycle, not a set-and-forget entry. The second most common failure is the DNSSEC one from Step 1: an unsigned MX-host zone that makes the whole record worthless.
Frequently asked questions
Do I need DNSSEC for DANE?
Yes, absolutely. DANE has no security value without DNSSEC because the TLSA record is only trustworthy if its DNS answer is cryptographically signed and validated. If the zone holding your MX hostname is unsigned, a sending server will not use the TLSA record at all, and an attacker could forge or strip it. Sign the zone and confirm the ad flag before publishing anything.
What is the difference between usage 3 and usage 2 in a TLSA record?
Usage 3 (DANE-EE) pins your server's own end-entity certificate or public key and ignores the CA chain entirely, which is the recommended default for SMTP. Usage 2 (DANE-TA) pins a trust anchor such as a private CA or intermediate, and the presented leaf must chain up to it. Most operators should use 3 1 1 unless they run their own CA.
Where exactly does the TLSA record go?
At _25._tcp.<mx-hostname>, in the DNS zone that controls that hostname. It is keyed to the MX target, not your main domain. If your MX record points to mail.example.com, the TLSA record lives at _25._tcp.mail.example.com. Every MX host you operate needs its own record.
Should I use DANE or MTA-STS?
Use both if you can. DANE gives stronger guarantees because it does not rely on certificate authorities, but it requires DNSSEC. MTA-STS works without DNSSEC but trusts the web PKI and an HTTPS policy file. Publishing both covers senders that support either mechanism. See MTA-STS vs DANE for the full comparison.