DANE (DNS-based Authentication of Named Entities, RFC 6698) lets a domain publish a DNSSEC-signed cryptographic fingerprint of its mail server's certificate, so senders can verify they are talking to the right server even in the presence of a determined network attacker. This article explains DANE, TLSA record format, how it complements MTA-STS, and how UK businesses deploy it.
3 1 1 patternDANE provides a way to pin a cryptographic fingerprint of an expected TLS certificate into DNS. When a sending mail server connects to your MX and negotiates TLS, it can compare the presented certificate against the TLSA record published in your DNSSEC-signed zone. If they match, TLS is trusted. If not, the connection is aborted.
DANE is DNSSEC-dependent. The integrity of the TLSA record itself is guaranteed by the DNSSEC chain. Without DNSSEC, an attacker could spoof the TLSA record and the whole scheme collapses.
MTA-STS and DANE solve similar problems — preventing TLS downgrade, validating the receiver's certificate — using different trust mechanisms:
| Aspect | MTA-STS | DANE |
|---|---|---|
| Discovery | DNS TXT + HTTPS policy file | DNS TLSA records |
| Trust root | HTTPS certificate chain | DNSSEC chain |
| Requires DNSSEC | No | Yes |
| Certificate validation | Against policy hostname list | Against cryptographic fingerprint |
| Adoption | Rapidly growing | Strong in Germany/NL, moderate UK |
Many UK organisations publish both. MTA-STS is easier to deploy (no DNSSEC required) but slightly weaker (depends on PKI). DANE is stronger but requires DNSSEC infrastructure. Running both gives redundancy.
A TLSA record is published at the name _port._protocol.hostname. For SMTP:
_25._tcp.mail.firm.co.uk. IN TLSA 3 1 1 <hash>Breaking down:
_25._tcp. — the port and protocol. SMTP on TCP port 25.mail.firm.co.uk — the MX hostname.TLSA — the record type.3 1 1 — the three-byte header: usage, selector, matching.<hash> — the hash value (hex-encoded).The first byte: what the record applies to.
| Value | Name | Meaning |
|---|---|---|
| 0 | PKIX-TA | A trust-anchor CA constraint — the cert chain must include this CA. |
| 1 | PKIX-EE | An end-entity cert constraint — the cert must be this specific cert. |
| 2 | DANE-TA | DNS-specified trust-anchor — the CA specified overrides the normal PKI. |
| 3 | DANE-EE | DNS-specified end-entity — the cert specified is valid regardless of PKI. |
For email, DANE-EE (3) is the overwhelming choice. It pins a specific end-entity certificate without any dependency on certificate authorities — perfect for self-signed or Let's Encrypt certificates that may not chain the way senders expect.
The second byte: what part of the certificate is hashed.
| Value | Name | Meaning |
|---|---|---|
| 0 | Cert | Hash the full certificate (DER-encoded). |
| 1 | SPKI | Hash only the SubjectPublicKeyInfo (the public key). |
For email, SPKI (1) is strongly preferred. Hashing just the public key means certificate renewal (reissued cert with same key) does not invalidate the TLSA record. Hashing the full certificate forces re-publishing TLSA on every renewal.
The third byte: the hash algorithm.
| Value | Algorithm |
|---|---|
| 0 | Full data (no hash) |
| 1 | SHA-256 |
| 2 | SHA-512 |
SHA-256 (1) is the universal choice. Full data (0) is impractical — DNS records would be huge. SHA-512 (2) is rarely used; SHA-256 is strong enough.
The fourth element: the hex-encoded hash of the selected certificate data under the specified algorithm. For SPKI SHA-256, this is 64 hex characters (32 bytes).
Example (fictitious):
_25._tcp.mail.firm.co.uk. IN TLSA 3 1 1 abcdef1234567890abcdef1234567890abcdef1234567890abcdef12345678903 1 1 patternThe combination DANE-EE, SPKI, SHA-256 is used by the overwhelming majority of deployed email DANE records. Including epost.plus:
_25._tcp.mail.epost.plus. IN TLSA 3 1 1 <SHA-256 of public key>Properties of this pattern:
Unless you have a specific reason to differ, use 3 1 1.
DANE is meaningful only when the TLSA records are signed by DNSSEC. Without DNSSEC, an attacker who can spoof DNS can publish fake TLSA records and the whole scheme fails.
DNSSEC deployment:
Most modern UK DNS platforms (Cloudflare, Route 53, Gandi, Nominet's own DNSSEC) support DNSSEC in a few clicks. See DNSSEC for Email.
dig +dnssec to confirm.hash-slinger automate this: tlsa --create --port 25 mail.firm.co.uk._25._tcp.mail.firm.co.uk, type TLSA, values 3 1 1 <hash>.During certificate rotation you typically publish two TLSA records — one for the old cert, one for the new. Sending servers validate if any published TLSA matches. After the rotation window, remove the old record.
The standard DANE rotation pattern:
For Let's Encrypt with SPKI-selector TLSA, renewals do not trigger TLSA updates — the certificate is reissued but the key stays the same. This is a major operational advantage and the reason SPKI is preferred.
3 1 1 TLSA records at _25._tcp.mail.epost.plus, backed by DNSSEC (Algorithm 13). Business Email, Private Email and Public Administration Email plans with a customer-owned domain can configure DANE similarly — the mail infrastructure supports it, and the customer publishes DNSSEC + TLSA at their domain's DNS.DANE adoption varies sharply by region and sector:
For a UK business, the practical question is: "do my mail flows include European receivers or UK public sector?" If yes, DANE gives meaningful additional protection. If purely domestic commercial, MTA-STS alone provides most of the value.
| Tool | Use |
|---|---|
hash-slinger | Python package with tlsa command to generate TLSA records |
openssl | Manual hash computation |
dig +dnssec | Verify TLSA records and DNSSEC chain |
| Hardenize | Full-stack audit including DANE |
| checktls.com | TLS and DANE validation |
| NCSC Mail Check | UK public sector audit including DANE |
| DANE SMTP Validator (sys4.de) | Targeted DANE testing |
The published hash does not match the actual certificate SPKI. Causes: wrong hash calculation, key rotated without updating TLSA, multiple certificates where one does not match. Recompute hash from live certificate.
The TLSA record exists but the DNSSEC chain is broken. Causes: expired RRSIG, missing DS at registrar, wrong Algorithm. Verify chain with dig +dnssec +trace.
Some senders (particularly older servers) do not validate DANE at all. They fall back to opportunistic TLS. TLS-RPT may report policy-match failures; you cannot force DANE validation at the sender side.
TLSA must be at _25._tcp.hostname for SMTP on port 25. Typos break validation.
Q: Do I need DNSSEC for DANE?
A: Yes — DANE without DNSSEC is insecure. If you cannot deploy DNSSEC, use MTA-STS instead.
Q: Which UK DNS providers support DNSSEC and TLSA records?
A: Cloudflare, AWS Route 53, Gandi LiveDNS, Nominet's own DNSSEC, Azure DNS, Google Cloud DNS all support both. Check your provider's documentation.
Q: Does DANE replace MTA-STS?
A: No — they are complementary. Deploy both for layered transport security.
Q: What UK receivers respect DANE on inbound mail?
A: Increasingly many. Gmail, some Microsoft 365 deployments, most European receivers (GMX, Web.de). UK-focused receivers vary. MTA-STS has wider enforcement; DANE is growing.
Q: How do I extract the SPKI hash from my certificate?
A: openssl x509 -in mail.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 produces the hex hash you publish in the TLSA record.
Q: What happens if DNSSEC validation fails on my zone?
A: Senders that validate DNSSEC treat the TLSA records as untrusted and do not enforce DANE. Non-validating senders ignore DNSSEC and fall back to opportunistic TLS. Either way, deliverability is preserved; DANE protection is lost.
Q: Can I publish TLSA without touching the mail server?
A: Yes — TLSA is entirely a DNS record. The mail server's existing STARTTLS setup is unchanged.
Q: Is DANE required for NCSC Mail Check compliance?
A: Not required — MTA-STS satisfies the NCSC baseline. DANE is an additional hardening layer scored positively but not mandatory.
Q: How often do certificate rotations cause DANE issues?
A: With SPKI selector: rarely, because the key stays the same across renewals. With Cert selector: every renewal, because the hash changes. Use SPKI.
Q: Can I mix DANE with self-signed certificates?
A: Yes — DANE-EE mode (usage 3) accepts any certificate whose SPKI or Cert hash matches, regardless of CA. Self-signed is fine as long as TLSA is correctly published.
Q: What is the practical risk of not deploying DANE if I already have MTA-STS?
A: Low to moderate. MTA-STS catches most realistic attacks. DANE's additional protection is against attackers who can subvert HTTPS (compromising certificate authorities). Marginal benefit for most UK business use cases; material benefit for high-sensitivity deployments.
Q: Can I use DANE with a certificate that rotates every 90 days (Let's Encrypt)?
A: Yes — with SPKI selector (TLSA 3 1 1), renewals that keep the same key do not invalidate the TLSA record. This is the standard UK deployment pattern: Let's Encrypt 90-day certs with DANE works seamlessly.
Q: Does DANE protect against a compromised DNSSEC zone?
A: Partially. If an attacker compromises your DNS provider's signing keys, they can publish forged TLSA records. This is why KSK rotation and secure key storage matter. The attack is significantly harder than simple DNS spoofing.
Q: How many UK domains publish DANE in 2026?
A: A minority — roughly 5-10% of commercial UK domains. Higher in public sector and financial services where regulatory guidance encourages it. The percentage is slowly growing as DNSSEC becomes more common.
Q: Can DANE be deployed on a subdomain for email?
A: Yes. Each MX host has its own TLSA record. If firm.co.uk MX points at mail.firm.co.uk, publish TLSA at _25._tcp.mail.firm.co.uk. If MX points at mail.provider.net, the provider publishes TLSA on their own hostname — not something you control.
Q: Is there a way to test DANE without affecting production mail?
A: Publish TLSA records before any receiver enforces them strictly. Most receivers validate passively (report-only) first. Once published, monitor TLS-RPT for a period, then rely on DANE validation going forward.
Q: What does DANE failure look like to the sender?
A: The TLS handshake succeeds (certificate presented, negotiated) but the post-handshake validation fails the DANE check. The sender terminates the connection and either retries or defers the message. TLS-RPT reports show "dane-failure".
Q: How does DANE relate to CT (Certificate Transparency)?
A: Orthogonal. CT is a public log of issued certificates; DANE pins expected certificates at DNS. A certificate can be CT-logged and DANE-pinned simultaneously; most are.
Q: What is the "TA" in PKIX-TA and DANE-TA?
A: Trust Anchor — a CA certificate that must appear in the chain. DANE-TA pins a CA in DNS; PKIX-TA constrains which public CAs can issue for your domain. Both are less common than DANE-EE.
Q: Does my DNS registrar need to support DNSSEC for DANE to work?
A: Yes — specifically, the registrar needs to support publishing the DS record at the TLD registry. Most modern UK registrars (Gandi, 123-Reg, Namecheap, Cloudflare Registrar) support DNSSEC DS publication. Confirm before committing to DANE.
Q: If I already have MTA-STS in enforce mode, does adding DANE break anything?
A: No. The two protocols operate independently at the sender side. A sender that honours both uses whichever applies. Deploying DANE on top of MTA-STS is additive protection without risk of conflict.
Q: What are TLSA records' TTLs typically set to?
A: 1-6 hours is typical. Shorter during active changes; longer at steady state. TLSA records rarely change, so longer TTLs (up to a day) are fine.
Q: Is DANE easier to deploy on self-hosted or managed mail?
A: Managed mail providers that support DANE (SmartXHosting, a subset of European hosted mail) make deployment trivial — the provider handles everything. Self-hosted requires you to run DNSSEC, generate TLSA, publish, and maintain through renewals. Managed is easier.
Q: Can I get alerting on DANE failures?
A: Yes — via TLS-RPT reports processed by a monitoring service. Any DANE failure shows up as a "dane-failure" entry, typically alertable in commercial DMARC/TLS-RPT dashboards.
Q: How do DANE and email encryption interact?
A: DANE validates the certificate used for STARTTLS (transport encryption). It does not affect end-to-end encryption (S/MIME, PGP). Layer them: DANE guarantees transport; S/MIME guarantees content.
Q: Does DANE work with mail forwarders in the middle?
A: Yes — each hop has its own TLSA validation. If a forwarder's TLSA is correct and validates, the hop is secure. A chain of DANE-protected hops is the gold standard for transport security.
Q: How does DANE relate to ARC?
A: ARC is about authentication preservation across forwarders; DANE is about transport security. They address different concerns. A message can be ARC-signed and travel over DANE-validated hops.
Q: Is there a UK-specific DANE directory or audit service?
A: NCSC Mail Check reports DANE status for accredited UK domains. For private sector, tools like Hardenize and Mail Hardener report DANE coverage. No UK-specific directory of DANE-enabled domains exists.
Q: What is the expected future of DANE?
A: Adoption will continue growing alongside DNSSEC deployment. In the UK, expansion mirrors DNSSEC uptake. Modern email infrastructure vendors (Axigen, Postfix, Exchange) all support DANE — it is the operational and DNS practices that need catching up.
Q: Can a UK sole trader realistically deploy DANE?
A: Only with a DNSSEC-enabled managed service. DIY DANE requires DNSSEC on your DNS host and TLSA publication — too much operational overhead for most sole traders. Use MTA-STS, or pick a mail provider that handles DANE for you.
Q: What is the interaction between DANE and SMTP content filtering?
A: DANE operates at TLS handshake. Content filtering operates after content is received. They do not conflict; a message passes DANE validation then flows through content inspection normally.
Q: Does DANE add latency to email delivery?
A: Minimal. The additional DNS lookups and validation steps add a few milliseconds per connection. For the volumes UK businesses process, unmeasurable in practice.
Q: What is the relationship between DANE and Certificate Transparency monitoring?
A: CT monitors certificate issuance publicly. DANE pins which certificates are authentic in DNS. CT catches fraudulent certificates being issued; DANE prevents them from being accepted by validating senders. They are complementary.
Q: Is DANE appropriate for a UK business with international mail recipients?
A: Particularly so. European receivers (German, Dutch, Scandinavian) enforce DANE more aggressively than UK domestic receivers. DANE benefits scale with the proportion of international mail you send and receive.
Q: Can I publish TLSA records that are deliberately broken, to test enforcement?
A: Not recommended in production — mail would fail to deliver. For testing purposes, use a staging subdomain with intentionally-broken TLSA to verify that validating senders respond correctly. Never do this on a live MX.