Does your TLSA actually protect anything, or is DNSSEC silently ignoring it? One scan walks every MX, decodes each TLSA triplet in plain English, and flags the cert-rotation cases that quietly break DANE in production.
Verifies the DNSSEC prerequisite, scans every MX in one pass, and flags cert-rotation risks.
DANE is silently ignored when the zone isn't signed — we surface this above the fold.
Walks every MX in one pass — no re-entering hostnames one at a time.
Flags selector-0 TLSAs that break on every cert renewal — the #1 production DANE failure mode.
What we don't check (v1): live STARTTLS handshake, or full certificate validation against the TLSA hash. We parse DNS only — for full cryptographic chain walks, a specialised DNSSEC visualiser is the right next step.
DANE works when three things line up:
_25._tcp.<mx-host> for every MX target.“Not configured” is the global default — adoption is around 14% in the Netherlands per SIDN's Sep 2025 data, 3–5% in the US. A clean “no TLSA” result is the norm, not a failure.
DANE hides its failures. A broken TLSA returns nothing to the sender — mail just starts bouncing, silently, days after a cert renewal. The checker reports each gate in the order a DANE-aware receiver evaluates them. Five things to look for:
If your zone isn't signed, the TLSA card folds into “your records exist but are being silently ignored.” DNSSEC is DANE's load-bearing beam — no signed zone, no DANE. We put this first so you don't spend an hour debugging TLSA when the problem is one layer up.
If your TLSA pins the full certificate (selector 0), every renewal needs the new TLSA published at least two TTLs ahead. With short cert lifetimes (Let's Encrypt: 60–90 days), this is one of the more common ways DANE quietly breaks in production — we flag it before it bounces mail.
3 1 1 becomes “DANE-EE / SPKI / SHA-256 — the recommended SMTP combo.” You see what each number means and which combos are current best-practice, without digging through RFC 7672.
One domain in, every MX record out — per-host TLSA status for each. No re-entering mx1.example.com, mx2.example.com one at a time.
No live STARTTLS probe, no cert-vs-TLSA comparison against the wire. Those need specialised tooling and we'd rather name our ceiling than overpromise. When you hit the edge of what we cover, you know where to look next.
DANE (DNS-Based Authentication of Named Entities, RFC 7672) lets your domain pin the exact TLS certificate its SMTP servers must present by publishing a TLSA record at _25._tcp.{mx-host}. The important part to know up front: DANE only takes effect when the zone is signed with DNSSEC. Without DNSSEC signatures, an attacker could forge both the certificate and the TLSA record — so compliant receivers ignore TLSA entirely when DNSSEC is missing or broken. DNSSEC isn't an optional hardening step here, it's the foundation. Publishing TLSA on an unsigned zone gives you the appearance of security without the substance.
The TLSA record itself encodes three small numbers and one big hash. The numbers are certificate usage (whether you're pinning the end-entity certificate or a CA), selector (the full certificate or just the public-key info), and matching type (full data, SHA-256, or SHA-512). The recommended SMTP tuple per RFC 7672 §3.1 is 3 1 1 — DANE-EE / SPKI / SHA-256. We decode all the others too, in the “3 1 1 means…” format.
The hard prerequisite. Compliant SMTP receivers ignore TLSA records when the zone isn't signed — so they may as well not exist. We surface this above the fold.
Published at _25._tcp.<mx-host>. Each MX target gets its own — receivers query the per-MX label, not the apex domain.
Publish the new TLSA at least 2 TTLs before swapping the cert. Selector 0 (full cert) rotates on every renewal; selector 1 (SPKI) only on key change.
DANE and MTA-STS solve the same threat (TLS downgrade between MTAs) with different trust anchors. DANE roots in DNSSEC; MTA-STS roots in the Web PKI plus a policy file at a well-known HTTPS URL. They're complementary — most EU hosting providers run both — but most US senders should start with MTA-STS.
| Aspect | DANE | MTA-STS |
|---|---|---|
| Trust anchor | DNSSEC | Public Web PKI + HTTPS policy |
| Prereq | Signed zone (≥1 hour to deploy) | HTTPS endpoint (any TLS cert works) |
| Cert rotation | Mandatory choreography (2+ TTLs ahead) | No coupling — rotate freely |
| Failure mode if misconfigured | 24–72h mail bounce | Soft fail; report-only mode available |
| Receiver-side support | Microsoft 365 (GA Q4 2024), most EU providers | Gmail, Yahoo, Microsoft 365 — global |
| Adoption | ~14% NL, ~3–5% US (2026) | ~6% NL, climbing globally |
Want to deploy MTA-STS? Check your MTA-STS configuration.
The most common way DANE breaks in production isn't a misconfiguration — it's a forgotten cert renewal. Here's the safe choreography. The two-TTL rule applies on both sides of the swap.
Generate the TLSA hash for the next certificate (or its SPKI). Publish it alongside the existing one — TLSA records are a multi-record set, receivers will accept whichever matches.
Deploy the new certificate. Receivers querying TLSA now see both the old and new hashes. The handshake succeeds because the new cert matches the new TLSA.
Once you're past two TTL windows, no resolver will still hold the old hash in cache. Drop the old TLSA record. Done.
DANE adoption is concentrated in Europe — approximately 14% of .nl domains and ~20% of .nl mail domains (SIDN, Sep 2025), mandated for Dutch government email under Forum Standaardisatie and for German email service providers under BSI TR-03108. US adoption sits at ~3–5%, though Microsoft Exchange Online's general availability of inbound SMTP DANE (Q4 2024) is starting to change that. If your domain returns “no TLSA records,” that is the global norm, not a failure — DANE is a deliberate architectural choice you make when you already run DNSSEC and want TLS enforcement that doesn't depend on certificate authorities.
The honest caveat for US senders: without an EU compliance driver, DMARC at enforcement plus MTA-STS covers the same opportunistic-TLS-downgrade threat with substantially less operational risk and no DNSSEC dependency. That trade-off is why most US senders should start with MTA-STS and treat DANE as an upgrade path, not a default.
A published TLSA record can fail to take effect for a small number of well-defined reasons. The vast majority of the time it's the DNSSEC chain — either the zone isn't signed at all, or the chain is broken because the parent registrar holds a stale DS record after a key rollover, an RRSIG signature has expired, or a NS change wasn't followed by a DS update at the registrar. The receiver's resolver doesn't see an Authenticated Data flag on the response and treats the TLSA record as untrustworthy.
The remaining cases are usually TLSA records that don't match the certificate currently on the wire — typically because a cert was renewed without pre-publishing the new TLSA. For selector-0 TLSAs (full certificate hash), this happens on every renewal; for selector-1 TLSAs (SPKI hash), only when the key changes. The fix in either case is the two-TTL choreography described above.
Diagnosing which case you're in is what this tool does. The DNSSEC card up top tells you whether the chain is intact; the per-MX cards below tell you what TLSA is actually published. If both look healthy and mail still bounces, you're likely mid-cert-rotation — give it a TTL window for caches to clear.
DANE is silently ignored when DNSSEC is missing or broken. Enable DNSSEC at your registrar (Cloudflare, Route 53, Namecheap, GoDaddy all offer one-click) and verify the AD flag is set on a DNSSEC-aware resolver before going further.
The recommended tuple per RFC 7672 is 3 1 1 (DANE-EE / SPKI / SHA-256). Most modern Postfix and Exim builds include a TLSA generator. For one-offs: openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256.
Add a TLSA record at _25._tcp.<your-mx-host> (one record per MX target). Set the TTL deliberately — a low TTL like 1 hour gives you faster rotation but more lookup load; a higher TTL like 24h is the inverse.
Enabling DANE for outbound SMTP means your MTA will refuse to send mail to receivers whose TLSA records don't match. Postfix: smtp_dns_support_level = dnssec; smtp_tls_security_level = dane. Exim and Exchange Online have equivalent toggles.
When you renew the cert, publish the new TLSA at least 2 TTLs in advance. Keep the old TLSA published for at least 2 TTLs after the cert switch. Skip this step and you'll see 24–72h of bounced mail. Most organizations automate this with the same tooling that drives certificate renewal.
Don't publish TLSA on an unsigned zone. Compliant receivers silently ignore TLSA when DNSSEC is missing or broken — you get the appearance of security without the substance. Enable DNSSEC first, then TLSA.
Don't use selector 0 with short-lived certs. Selector-0 TLSA pins the whole cert — so every Let's Encrypt renewal (60–90 days) becomes a rotation event. Selector 1 (SPKI) survives renewals as long as the key stays the same.
Don't rotate certs without the 2-TTL choreography. Publish the new TLSA 2+ TTLs before swapping the cert, keep the old TLSA 2+ TTLs after. Skip it and you're looking at a 24–72h inbound mail outage.
Don't run DANE without automated rotation plumbing. Manual pre-publish-then-swap is a human-forgets-once-and-mail-bounces pattern. Wire TLSA generation into the same automation that renews the cert.
DANE sits on top of DNSSEC and alongside MTA-STS. Here's the rest of the cohort.
Hard prerequisite. DANE without DNSSEC is silently ignored. Check the chain before anything else.
The no-DNSSEC alternative. Same TLS-downgrade threat model, different trust anchor. Most US senders start here.
If DANE isn't for you, DMARC at enforcement is the highest-leverage email security control.
Display your brand logo in Gmail and Apple Mail — once DMARC is at enforcement.
Everything about DANE, TLSA records, the DNSSEC prerequisite, cert-rotation safety, and EU compliance mandates.
Still have questions about DANE deployment?