Defaults.Exposed › Fixes › DANE (DNS-based Authentication of Named Entities)

How to fix DANE (DNS-based Authentication of Named Entities)

DANE is a way for your domain to publish the fingerprint of your own encryption certificate in DNS, so the other side can check the cert is really yours before trusting it. In practice this is mostly used between mail servers: it stops an attacker (or a rogue certificate authority) from silently intercepting inbound email with a fake-but-valid-looking certificate. DANE only works if DNSSEC is already switched on — without DNSSEC it protects nothing at all.

Bottom line for your business: Without DANE, inbound email to your domain can — in principle — be intercepted by a well-resourced attacker who obtains a mis-issued certificate for your mail server (state actors and a small number of past CA breaches have both done exactly this) and quietly reads or alters messages in transit. Almost no small business has been individually targeted this way, but the reason DANE keeps coming up in tenders and security questionnaires is that larger buyers, regulated sectors and several national governments now expect it as a baseline — its absence is a visible tick in the wrong column on their vendor scorecard. The other real cost is the reverse: DANE done badly (letting the fingerprint drift out of sync with the actual certificate at renewal time) breaks inbound mail from every server that checks it, and you find out from bounced customer emails.

What this can cost you

• A pre-contract security review by a German, Dutch or public-sector buyer flags 'no DANE for SMTP' as a gap; the deal survives, but you spend a week defending a decision you never actually made, and the buyer's scorecard now has a red mark next to your name for the next renewal.
• Your certificate on the mail server auto-renews; nobody remembered that the TLSA fingerprint in DNS also has to update; from that moment inbound mail from every DANE-checking sender (a growing list — German ISPs, DE-CIX operators, Comcast, Google, Microsoft/Outlook) hard-fails with 'certificate does not match TLSA record.' The problem is invisible in your inbox — you only see it when customers ring to ask why their reply bounced.
• You publish TLSA records without DNSSEC being live, thinking you've enabled DANE. Nothing protects anything: an attacker can forge the DNS answer for the TLSA record itself. You're carrying the operational risk of DANE with none of the security benefit, and any half-competent security review will flag it.
• Someone else publishes a DANE record at your registrar during a rushed migration, points it at the wrong port or the wrong host, and mail delivery starts failing selectively for the domains and providers that check DANE — a classic 'works for us, breaks for them' outage that's near-impossible to reproduce internally.
• A prospect's IT team asks a direct, informed question — 'do you support DANE for SMTP?' — and the honest answer is no. In some sectors that alone is enough to move you from the shortlist to the maybe-pile.

Why it matters. The public certificate authority system that underpins HTTPS and encrypted email works well most of the time, but it has one structural weakness: any CA anywhere in the world can, in principle, issue a valid certificate for your domain. That has happened — through hacked CAs, mis-issuance and state-level pressure. DANE lets you sidestep that weakness for the traffic you care about most: you publish, in DNS, the fingerprint of the exact certificate the other side should see. If the certificate presented doesn't match, the connection is refused. Because the DNS answer itself is signed with DNSSEC, an attacker can't just forge a different fingerprint. It's the strongest cryptographic guarantee available today that inbound mail is going to your servers and not a well-resourced impostor's — which is why it's increasingly named as an expected control by governments, large enterprises and regulated-sector buyers.

How to fix it, step by step

1. Confirm DNSSEC is live first. DANE is meaningless without DNSSEC. Verify DNSSEC is enabled and validating on your domain before you publish any TLSA record. If DNSSEC is not yet enabled, fix that first — DANE without DNSSEC gives you zero protection and adds operational risk.
2. Check your mail server and DNS host support DANE. Most modern mail platforms (Postfix, Exim, Halon, and hosted providers such as Migadu, Mailfence and Posteo) support DANE natively. Confirm your DNS host can publish TLSA records (Cloudflare, Route 53, deSEC and most registrar zones can).
3. Generate the TLSA record from your live mail certificate. Produce a TLSA record with usage 3, selector 1, matching type 1 (DANE-EE / SPKI / SHA-256) from the certificate your mail server actually presents on port 25. The standard tool is `posttls-finger -t30 -T180 -Lsummary,ssl mail.yourdomain.com` or the online generator at ssl-tools.net.
4. Publish the TLSA record at the right name. For SMTP, publish the record at `_25._tcp.<mx-hostname>` — for example `_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-public-key>`. Publish one TLSA record per MX host you list.
5. Adopt the '2 TLSA' rollover pattern for cert renewals. Before your certificate renews, publish a second TLSA record for the incoming key alongside the current one. Renew the cert. Only after the new cert is live and stable, remove the old TLSA record. Automate this in your renewal script — the single biggest cause of DANE outages is manual rollovers that skip a step.
6. Validate end-to-end. Verify with Internet.nl and the Sys4 DANE checker. Both should show a green DANE result, a valid DNSSEC chain, and a certificate fingerprint that matches the published TLSA record. Don't consider it done until every MX host on your domain validates cleanly.

DANE, in plain words

When one mail server sends email to another, the sending side asks DNS “which server handles mail for this domain?” and then opens an encrypted connection. That connection is protected by a TLS certificate, exactly like an HTTPS website — and, exactly like an HTTPS website, the receiving server’s certificate is trusted because some certificate authority (CA) somewhere in the world signed it.

Here’s the uncomfortable part of that arrangement: there are hundreds of trusted CAs, and any of them can — in principle — issue a valid certificate for any domain. It has happened. CAs have been hacked. CAs have been coerced. CAs have simply made mistakes. When it happens, the fake certificate looks completely legitimate to the mail server checking it, and encrypted mail can be quietly intercepted by whoever holds the fake.

DANE closes that loophole. Instead of trusting “any certificate signed by any of hundreds of CAs,” DANE lets you publish, in DNS, the fingerprint of the exact certificate that your mail server is supposed to present. Any mail server that supports DANE will refuse to deliver mail if the certificate it sees doesn’t match the fingerprint you published. A rogue-CA certificate — even one that’s cryptographically perfect — fails the check and gets thrown away.

The mechanism is a special DNS record called TLSA. It carries the fingerprint of your certificate’s public key, published at a name that includes the port and protocol (for mail: _25._tcp.mail.yourdomain.com). The whole thing only works because the DNS answer itself is protected by DNSSEC — without DNSSEC an attacker could just forge a different TLSA record and the check would trust their forgery. This is why DNSSEC is a hard prerequisite for DANE. There is no partial answer here: no DNSSEC, no DANE.

Today DANE is used almost exclusively for server-to-server email over SMTP. It exists in the standards for websites too, but no major browser ever shipped support for it and none realistically will — so this page, and our check, is about DANE for mail.

What this can cost you

These are realistic, aggregate patterns — not any one named business.

• The silently-lost tender. A prospect’s security team runs a pre-contract check of your domain. DANE for SMTP shows up as absent on their scorecard next to other DNS/email hygiene items. In some sectors — German B2B, EU public sector, healthcare, defence supply chains, regulated finance — this is enough to push you from “yes” to “we’d like to see improvement” or, occasionally, straight off the shortlist. The deal doesn’t get lost visibly; it just doesn’t get won.
• The renewal-day outage. Your TLS certificate on the mail server renews on schedule. Whoever set up DANE didn’t wire the TLSA record into the renewal process. From the moment the new cert goes live, every mail server that validates DANE — a set that now includes Google, Microsoft/Outlook, Comcast, and every large German ISP — rejects incoming mail with a certificate-mismatch error. Your inbox looks fine because internal mail still flows; you find out when a customer rings to ask why their reply bounced. Recovery is straightforward but embarrassing, and the outage window is often measured in hours before anyone spots it.
• The false sense of security. Someone publishes TLSA records at your domain but DNSSEC was never enabled. On paper, DANE is “on.” In reality, it protects nothing at all — an attacker who can forge the mail-server IP can just as easily forge the TLSA record that goes with it. You now have the operational fragility of DANE (renewal-day risk) with none of the security benefit. Any competent audit spots this immediately.
• The half-migration outage. Mail is moved to a new provider. Someone forgets that the TLSA records still point at the old server’s certificate, or the records are copied over pointing at the wrong MX hostname. Mail delivery starts silently failing for the subset of senders that check DANE. It works fine internally, works fine for the majority of senders that don’t check, and is nearly impossible to reproduce from your own network — a classic “hard to see, painful to explain” incident.
• The signalling loss. Larger enterprise and public-sector procurement processes increasingly reward positive security signals, not just the absence of negative ones. DANE, MTA-STS, DNSSEC and DMARC-with-enforcement together read as “these people take email security seriously.” Missing DANE alone won’t sink a deal, but its absence in a group where the other three are also missing paints a picture that’s hard to talk your way out of.

What it actually is

DANE stands for DNS-based Authentication of Named Entities. In plain terms, it lets a domain publish — in its own DNS — the fingerprint of the TLS certificate that its servers are supposed to present.

The record that carries the fingerprint is called a TLSA record. Every TLSA record has four things in it:

• A usage number — most commonly 3, meaning “this fingerprint identifies the server’s actual end-entity certificate, ignore the CA hierarchy” (this mode is called DANE-EE).
• A selector number — most commonly 1, meaning “the fingerprint is of the certificate’s public key” (rather than the whole certificate; using the key means the record survives simple cert renewals with the same key).
• A matching type number — most commonly 1, meaning “SHA-256 hash.”
• The actual fingerprint — a long hexadecimal string.

Put together, a typical TLSA record for a mail server looks like this:

_25._tcp.mail.example.com.  IN TLSA  3 1 1  4a5c9d...e2b7

The name on the left has three parts that all matter: _25 is the TCP port (25 is SMTP), _tcp is the protocol, and mail.example.com is the MX host — the actual mail server you told the world about in your MX records. A TLSA record has to exist for every MX host you publish, and it has to sit at the correct port/protocol name in front of that host.

For the whole thing to actually protect you, three separate pieces have to line up at the same time:

• DNSSEC is enabled and validating on your domain. Without this, none of what follows matters — the TLSA record itself could be forged by whoever forged the mail-server address. DANE with broken or missing DNSSEC is not “weaker DANE,” it’s no DANE at all, plus operational risk.
• The TLSA record is published at the correct _25._tcp.<mx-host> name.
• The fingerprint in the TLSA record matches the public key of the certificate your mail server actually presents right now.

If any of those three drift out of sync — DNSSEC lapses, a TLSA record points at the wrong host, a cert renews but the fingerprint isn’t updated — every DANE-checking sender on the internet will refuse to deliver mail to you. That’s a feature, not a bug: it’s what makes DANE a real cryptographic guarantee. It’s also what makes rolling certificates the single most important operational discipline for anyone running DANE.

The senders that will actually check the record and refuse mail on a mismatch are a small but heavy list: every major German ISP, DE-CIX-adjacent operators, the German federal government (which mandates DANE for .gov.de and related zones), Comcast in the US, Google for inbound Gmail, and Microsoft/Outlook (which rolled out inbound DANE validation in 2024). If you exchange B2B mail internationally, you almost certainly send to and receive from that list already.

What “good” looks like, in one line: DNSSEC live and valid, a TLSA 3 1 1 record published at _25._tcp.<mx-host> for every MX host on your domain, and every fingerprint matches the public key of the certificate the corresponding mail server presents right now.

How to fix it (assumes DNSSEC is already live)

Hand this section to whoever manages your mail server and your DNS zone. DANE is genuinely powerful and genuinely unforgiving of sloppiness. If nobody in the loop has done it before, the honest answer is to start with MTA-STS (easier, no DNSSEC dependency, catches most of the same attackers) and come back to DANE once the automation is in place. The single most important rule below is the rollover pattern in step 5 — skipping it is how DANE outages happen.

Step 0 — DNSSEC first. Do not publish a single TLSA record until DNSSEC on your domain is enabled and validating end-to-end. See the DNSSEC fix page for the checklist. If DNSSEC isn’t live, DANE gives you nothing except future breakage.

Step 1 — Confirm your mail platform supports DANE.

• Self-hosted Postfix / Exim / Halon: all support DANE natively and are the reference implementations. Turn on outbound DANE with smtp_dns_support_level = dnssec and smtp_tls_security_level = dane in Postfix. Inbound just needs the TLSA record published; there is nothing to enable on the server itself.
• Hosted providers that support DANE: Migadu, Mailfence, Posteo, mailbox.org, and several European business-mail providers. Ask their support to confirm and to hand you the TLSA record for their MX hosts.
• Microsoft 365 / Google Workspace / most large US-based SaaS mail providers: at the time of writing, they do not let customers publish DANE records for their inbound MX hosts, because you don’t control DNS at outlook.com / google.com. You cannot enable inbound DANE on your own domain if your MX points at their servers. You can, however, and should, enable MTA-STS instead. Their outbound DANE validation (checking DANE on their outgoing mail to your domain) is separate — that’s the “Google / Microsoft check DANE” behaviour referenced elsewhere on this page.

Step 2 — Generate the TLSA record from your live certificate.

• The safest way is to point a tool at the live mail server so it produces the record from what’s actually being served. On a Linux box with Postfix installed: posttls-finger -t30 -T180 -Lsummary,ssl mail.yourdomain.com prints the ready-to-publish TLSA line at the bottom.
• Online: the Sys4 DANE-SMTP validator and ssl-tools.net both offer TLSA generators — paste in your MX hostname and they’ll fetch the certificate and emit the record.
• Prefer usage 3, selector 1, matching type 1 (DANE-EE / SPKI / SHA-256). This is the modern default, and by hashing the public key (not the whole certificate) it lets you renew the certificate with the same key without touching DNS.

Step 3 — Publish the TLSA record at the correct name.

• Name: _25._tcp.<your-MX-hostname>. For example if your MX record points to mail.example.com, the TLSA record’s name is _25._tcp.mail.example.com.
• Type: TLSA. Value: 3 1 1 <sha256-hex>.
• Publish one TLSA record per MX host on your domain. If your MX record lists two mail servers, you need two TLSA records — one for each — with fingerprints from each server’s own certificate.

Step 4 — Wait 24–48 hours and validate.

• Run the check at internet.nl (paste your domain in) — the mail-test result will show DANE as pass/fail with a per-MX breakdown.
• Also run dane.sys4.de — it explicitly shows the TLSA record it found, the certificate it found, and whether they match.
• Both should be green for every MX host. If one MX passes and another fails, the failing MX is the one still exposed.

Step 5 — Set up the rollover pattern for cert renewals (the important one).

• The rule: the new TLSA record must be published in DNS before the certificate that matches it goes live on the mail server, and the old TLSA record must stay in place until every cache in the world has picked up the new one.
• The standard pattern is “2 TLSA rollover”:
  1. A few days before renewal, publish a second TLSA record for the incoming cert’s public key alongside the current one. Both records live at the same name; there’s now a pair.
  2. When the new certificate is issued and deployed on the mail server, DANE-checking senders see a certificate that matches one of the two published TLSA records — either the old or the new — and mail keeps flowing.
  3. After a safe interval (at least the DNS TTL, ideally 24–72 hours), remove the old TLSA record.
• Any competent DANE-aware renewal automation — for example the DNS-01 flow in acme.sh or certbot combined with a hook that updates the TLSA record — handles this without human intervention. If you’re doing it by hand: write the runbook, follow it every time, don’t shortcut.

Step 6 — Turn on continuous monitoring.

• DANE breakage is asymmetric: it’s silent from the inside (your outbound mail works fine, your inbox looks normal) and catastrophic from the outside (a slice of senders can’t deliver to you). At the very least, subscribe to a free monitoring service (Internet.nl and dane.sys4.de both offer periodic checks; several commercial monitors exist). At minimum, put a monthly reminder on someone’s calendar to re-run the check.

Common mistakes

• Publishing TLSA records before DNSSEC is fully live. The single most damaging conceptual mistake. It looks like DANE is on. It gives you zero protection. Any competent security audit spots it immediately, and any operational fragility of DANE (renewal breakage) applies fully. Do not skip step 0.
• Forgetting the TLSA record when the certificate renews. The single most damaging operational mistake. The cert renews, the fingerprint moves, the TLSA record still points at the old key, DANE-checking senders reject every incoming message. This is why the ‘2 TLSA rollover’ pattern (step 5) exists — use it, automate it, don’t rely on memory.
• Publishing TLSA records for the wrong host or wrong port. The record has to sit at _25._tcp.<MX-host>, not at your apex domain, not at _443._tcp, not in front of your webmail hostname. And it has to name the MX target — the value in your MX records — not your domain. Getting this wrong means the record isn’t seen at all (best case) or is seen and rejected (worse case).
• Only publishing TLSA for one of several MX hosts. If your MX record lists two or three mail servers for redundancy, every one of them needs its own TLSA record with its own fingerprint. A missing TLSA on the backup MX means a DANE-checking sender that fails over to it will refuse delivery.
• Assuming DANE covers your website. It doesn’t, in any browser anyone uses. Publishing TLSA records for _443._tcp.www.yourdomain.com is harmless but pointless — no visitor’s browser looks at them. DANE today means SMTP.
• Using TLSA usage 0 or 1 without knowing why. Usages 0 and 1 chain to the public CA hierarchy and add complexity most operators don’t need. Unless you have a specific reason, use 3 1 1 (DANE-EE, SPKI, SHA-256) — the modern default, and what the tools generate by default.
• Turning DANE on without monitoring. DANE breaks silently. You can go months with a broken setup and not notice until a big customer’s IT team asks why their mail bounces. If it’s worth turning on, it’s worth checking monthly.

Where this sits in your grade

DANE sits in the TLS section of your grade as an advanced control — one that meaningfully raises your security floor and your credibility with regulated and enterprise buyers, but only when the prerequisite (DNSSEC) is in place and the certificate-rollover discipline is real. Our check is deliberately careful about this: a domain with no DNSSEC and no DANE is scored as “hasn’t started the stack yet,” a domain with DNSSEC but no DANE as “solid foundation, DANE would be the next step,” and a domain with TLSA records but missing or invalid DNSSEC gets flagged specifically — because that combination is the one that looks secure and isn’t. See also the DNSSEC fix page (hard prerequisite) and, if you’re on Microsoft 365 or Google Workspace and can’t publish DANE for your inbound MX, the MTA-STS fix page (the pragmatic alternative that catches most of the same attackers and requires no DNSSEC).

FAQ