CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is DANE? DNS-Based Authentication for Email TLS Security (2025)
Email Security
DANE Explained: DNSSEC-Pinned TLSA Records for Bulletproof SMTP Transport Security
DANE (DNS-Based Authentication of Named Entities, RFC 6698) uses DNSSEC-signed TLSA records to cryptographically pin TLS certificates for SMTP, eliminating rogue CA attacks and BGP hijacking on inbound mail. Required by BSI TR-03108 for German government compliance. Learn how TLSA records work, DANE vs MTA-STS, and how to deploy safely.
DANE (DNS-Based Authentication of Named Entities, RFC 6698) uses DNSSEC-signed TLSA records to cryptographically pi…
What is DANE?
DANE (DNS-Based Authentication of Named Entities) is a cryptographic protocol that uses DNSSEC-signed DNS records to pin TLS certificates for services like email. Instead of trusting any of the hundreds of public Certificate Authorities to vouch for a server's identity, DANE lets the domain owner publish exactly which certificate — or which public key — their server uses, cryptographically signed by DNSSEC. An attacker cannot forge or substitute a different certificate without breaking the DNSSEC signature chain.
For email specifically, DANE is implemented via RFC 7672 (DANE for SMTP) using TLSA records published at . When a sending MTA connects to your MX host, it compares the TLS certificate presented by the server against the DNSSEC-signed TLSA record. If they match, the connection is authenticated. If they diverge — because an attacker inserted a rogue server or substituted a fraudulent certificate — the sender refuses to deliver.
_25._tcp.mx1.example.com. 3600 IN TLSA [Usage] [Selector] [Matching Type] [Certificate Data]
| Field | Options | Meaning |
|-------|---------|---------|
| Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Which certificate is trusted and how |
| Selector | 0 (Full certificate), 1 (SPKI — public key only) | Which part of the certificate is hashed |
| Matching Type | 0 (exact), 1 (SHA-256), 2 (SHA-512) | How the certificate data is encoded |
| Certificate Data | Hex-encoded hash or full certificate bytes | The actual cryptographic value to match |
For SMTP (RFC 7672 recommendation): use 3 1 1 — DANE-EE, SPKI hash, SHA-256. This pins the MX server's public key hash and allows certificate renewal without changing DNS, as long as the same key pair is used.
Usage, Selector, Matching Type explained
Usage 3 (DANE-EE) — "Trust this specific end-entity certificate, regardless of CA." This completely removes public CAs from the trust decision. The DANE-aware sender only trusts the exact public key or certificate hash published in your TLSA record. This is the most secure mode for SMTP.
Usage 2 (DANE-TA) — "Trust certificates issued by this specific CA." You publish the hash of your internal or specific CA rather than the end-entity cert. Less common for SMTP.
Selector 1 (SPKI) — Only the Subject Public Key Info (the public key itself) is hashed. This allows renewing the TLS certificate with the same key without updating DNS. Always use Selector 1 over Selector 0 for operational sanity.
Matching Type 1 (SHA-256) — 32-byte SHA-256 hash of the selected certificate data, encoded as 64 hex characters. The industry standard for DANE TLSA records.
DANE for SMTP
SMTP is where DANE has the clearest operational value. RFC 7672 (DANE for SMTP) specifies how sending MTAs should use TLSA records to authenticate receiving MX hosts during STARTTLS negotiation:
The sending MTA looks up MX records for the recipient domain
For each MX host, it queries _25._tcp.mxhost.example.com for TLSA records
If TLSA records exist and are DNSSEC-signed, the sender connects and expects TLS
The sender compares the MX host's presented certificate against the TLSA hash
If they match, TLS connection proceeds; if not, the sender refuses delivery
This eliminates both STARTTLS stripping (the sender knows to require TLS from the TLSA record) and rogue certificate attacks (only the pinned key/cert is accepted).
DANE vs MTA-STS: detailed comparison
| Feature | DANE | MTA-STS |
|---------|------|---------|
| Trust mechanism | DNSSEC + TLSA cryptographic pinning | Web PKI + HTTPS policy file |
| DNSSEC required | Yes — mandatory | No |
| CA trust dependency | None (Usage 3) | Yes — valid CA-signed cert required |
| Certificate pinning | Yes — pins specific key or cert | No — any valid CA cert accepted |
| Sender adoption | Moderate (Microsoft, many EU providers) | High (Gmail, Microsoft, Yahoo, most MTAs) |
| Operational complexity | High — DNSSEC expertise required | Moderate — web hosting + DNS |
| Regulatory requirement | BSI TR-03108 (Germany) | CISA guidance (US federal) |
| Best for | High-security; DNSSEC-capable domains | Most organizations seeking broad coverage |
Recommendation: Deploy MTA-STS first for broad coverage. Add DANE additionally if your domain already runs DNSSEC reliably and you need the highest security assurance or BSI compliance.
Why DANE requires DNSSEC
Without DNSSEC, a TLSA record is just unsigned text in DNS — any attacker who can intercept DNS queries (via BGP hijacking, compromised resolvers, or on-path attacks) could substitute a different TLSA hash that matches their fraudulent certificate. The entire security model collapses.
DNSSEC provides cryptographic authenticity for DNS answers: each record in the signed zone is accompanied by an RRSIG (digital signature), and the chain of trust is anchored to the IANA root zone. A DANE-aware sender validates this entire chain before trusting any TLSA record. If the DNSSEC chain is broken (expired RRSIG, missing DS record, invalid DNSKEY), DANE-aware senders fall back to standard PKI validation — losing all DANE protection.
Deployment risks: what breaks DANE
DANE is powerful but unforgiving. Common production failures:
Certificate rotation without DNS update: The most frequent DANE outage. IT replaces an expiring TLS certificate on the MX server but forgets to update the TLSA record. The new certificate has a different hash — DANE-enforcing senders (Microsoft, Comcast) immediately refuse delivery. Prevention: always publish the new TLSA hash before binding the new certificate.
DNSSEC expiry: DNSSEC signatures (RRSIG) expire. If your DNS provider's signing process fails, all TLSA records become untrusted and DANE protection silently disappears. Monitor RRSIG expiry dates continuously.
Hashing the full certificate (Selector 0): If you hash the full certificate (Selector 0) instead of the public key (Selector 1), every certificate renewal — even with the same key — changes the hash and breaks DANE. Always use Selector 1.
How to implement DANE
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5─────────>
step 6
1. Step 1:DANE is only as strong as your DNSSEC chain. Before deploying DANE, verify that: your domain has a valid DS record at the TLD, your DNS zone has DNSKEY records, and TLSA records will be signed with RRSIG. Test DNSSEC validation on your domain using a DNSSEC validator tool. A broken DNSSEC chain (expired RRSIG, missing DS) causes DANE-aware senders to ignore your TLSA records.
2. Step 2:List all MX hosts in your DNS and connect to each one on port 25 to retrieve the TLS certificate. Note the certificate's public key (Subject Public Key Info). You will hash this key to create the TLSA record. If your MX host has multiple certificates (e.g., for certificate rotation), you can publish TLSA records for both current and upcoming keys simultaneously.
3. Step 3:For DANE-EE (Usage 3, Selector 1, Matching Type 1): extract the Subject Public Key Info (SPKI) from the certificate and compute its SHA-256 hash. This produces a 64-character hex string for the TLSA record data field. Tools like openssl and dedicated DANE generators can compute this from a certificate file. Always use Selector 1 (SPKI hash) rather than Selector 0 (full certificate hash) so that renewing the certificate with the same key does not break DANE.
4. Step 4:For each MX host (e.g., mx1.example.com), publish a TLSA record at _25._tcp.mx1.example.com. Example: _25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 09b82...[sha256-of-spki]... — Verify that DNSSEC is signing the new TLSA records (check for RRSIG records). Wait for DNS propagation before testing.
5. Step 5:Use a DANE checker tool to verify that your TLSA records are properly DNSSEC-signed, syntactically correct, and match your MX host's live certificate. Deploy TLS-RPT if you have not already — DANE failures will appear as DANE validation failure results in TLS-RPT reports. This is the only way to know if DANE-aware senders are encountering problems.
6. Step 6:DANE breaks during certificate rotation if you replace the certificate before updating the TLSA record. The safe pattern: generate new key pair → compute new SPKI hash → publish new TLSA record alongside old one → wait 48+ hours for propagation → bind new certificate to MX server → wait 48 hours → remove old TLSA record. Never delete the old TLSA record until the new one is universally propagated.
Technical Architecture
DANE is defined in RFC 6698 and uses the TLSA DNS record type. For SMTP (RFC 7672):
DNS Record / Config
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 09b82...[sha256_hash_of_public_key]...
Key architectural principle: The TLSA record's cryptographic value (the hash in the last field) must exactly match what the receiving MX server presents during TLS negotiation. DANE-aware senders verify this match after establishing the TLS connection — if the presented certificate's SPKI hash does not match the DNSSEC-signed TLSA record, the sender terminates the connection without delivering.
Implementation Examples
Usage 3 1 1 — DANE-EE with SHA-256 SPKI hash (recommended for SMTP):
DNS Record / Config
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 09b82...[sha256_of_public_key]...
Publish next key in advance of rotation:
DNS Record / Config
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 09b82...[current_key_hash]...
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 8f91c...[next_key_hash]...
Common Misconfigurations
Key rotation without DNS pre-publishing: New cert bound before TLSA updated → immediate DANE failure for all compliant senders
DNSSEC breakage: Expired RRSIG or missing DS record → TLSA records untrusted → DANE protection silently lost
Using Selector 0 (full certificate): Every cert renewal breaks DANE even if the key is the same → always use Selector 1
Security Risks DANE Addresses
Rogue CA certificate issuance: Any of hundreds of global CAs can issue a certificate for your domain. DANE eliminates this risk — only the specific key hash in TLSA is trusted, regardless of which CA signed the certificate
BGP hijacking: Attacker redirects MX traffic to rogue server. Without DANE, any CA-signed cert satisfies TLS. With DANE, the rogue server cannot forge the DNSSEC-signed TLSA record, and delivery is refused
STARTTLS stripping: DANE-aware senders know TLS is expected from the TLSA record — they will not downgrade to plaintext even if STARTTLS is stripped from the greeting
Compliance Impact
BSI TR-03108 (Germany): Explicitly mandates DANE for email transport security in German government and critical infrastructure communications
GDPR Article 32: State-of-the-art technical measures for data security — DANE provides cryptographic guarantees beyond what opportunistic or Web PKI-based TLS can offer
Best Practices for DANE in 2025/2026
Publish next-key TLSA before every rotation — 48+ hours in advance, never after
Use Selector 1 (SPKI) — allows certificate renewal without TLSA update if key is unchanged
Monitor DNSSEC chain continuously — RRSIG expiry breaks all DANE protection silently
Deploy TLS-RPT alongside DANE — the only way to detect DANE validation failures from the sender side
Deploy MTA-STS concurrently — provides coverage for senders that do not support DNSSEC
Tools to check your DANE
Use the CyberFurl security report to audit your DANE posture as part of a full email and DNS security assessment. For TLSA record lookup and validation, check that the DNSSEC signatures are valid and the hash matches your live MX certificate. After any certificate rotation or MX infrastructure change, re-validate the TLSA records to confirm DANE continues to protect delivery. Combine DANE validation with TLS-RPT monitoring for continuous enforcement visibility.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl security report includes DANE posture validation as part of the comprehensive email and DNS security assessment. The platform validates DNSSEC chain integrity, checks TLSA record syntax and correctness against live MX certificates, and integrates TLS-RPT data to surface DANE validation failures - including alerts when certificate rotation breaks the TLSA hash match.
Yes — DNSSEC is an absolute requirement for DANE. This is not optional. DANE places TLSA records in your DNS zone, and those records are only trustworthy if the DNS responses are cryptographically signed by DNSSEC. Without DNSSEC, a TLSA record is just unsigned text in DNS that any attacker on the network path could modify or spoof. DANE-aware senders verify the DNSSEC signature chain from the root down to your TLSA record before trusting it. If your domain does not have a valid DNSSEC chain (DS record at the TLD → DNSKEY in your zone → RRSIG on TLSA records), DANE-compliant senders will ignore or reject your TLSA records.
Can I use both DANE and MTA-STS?
Yes — and it is recommended. DANE and MTA-STS address the same threat (SMTP downgrade attacks) but through different trust mechanisms. DANE relies on DNSSEC and has strong cryptographic guarantees but limited sender support. MTA-STS relies on Web PKI and HTTPS and is supported by virtually all major senders (Gmail, Microsoft, Yahoo). Deploying both gives you: MTA-STS enforcement for the broad sender ecosystem, DANE enforcement for senders that support DNSSEC validation (including Microsoft and many European providers), and defense-in-depth. The two protocols coexist without conflict.
Which TLSA mode should I use for email?
For SMTP email security (DANE-SMTP per RFC 7672), use TLSA 3 1 1 — that is, Usage 3 (DANE-EE: Domain Issued Certificate), Selector 1 (Subject Public Key Info), Matching Type 1 (SHA-256). This is the standard recommended mode. Usage 3 + Selector 1 pins the MX server's public key hash rather than the full certificate or the CA chain. This means you can renew your TLS certificate using the same key pair without updating DANE, as long as the public key does not change. Usage 0 or 1 (CA Constraint and Service Certificate Constraint) are also valid but less flexible for SMTP deployment.
Does DANE work for HTTPS?
DANE was originally designed to work for any TLS-secured protocol, including HTTPS. RFC 6698 defines DANE for HTTPS, and it would allow websites to pin their TLS certificates in DNSSEC, bypassing the CA trust model. However, DANE for HTTPS has very limited browser support — no major browser implements DANE for HTTPS connections. Browser vendors opted for Certificate Transparency (CT) logs and CAA records as alternative mechanisms to reduce CA abuse risk. DANE for SMTP (RFC 7672) has much better adoption because email MTAs can implement it without the browser compatibility constraints.
What is DANE?
DANE (DNS-Based Authentication of Named Entities) is a protocol defined in RFC 6698 that uses DNSSEC to publish cryptographic certificates or public key hashes in DNS as TLSA records. For email (RFC 7672), DANE allows the receiving domain to publish the exact TLS certificate fingerprint or public key hash that its MX servers use, signed by DNSSEC. When a sending MTA connects via SMTP, it compares the TLS certificate presented by the receiving MX host against the DNSSEC-signed TLSA record. If they match, the connection proceeds securely. If they do not match — because an attacker replaced the certificate or inserted a rogue MX server — the sender refuses to deliver, regardless of what any public CA says.
Can I deploy DANE without generating a new TLS certificate?
Yes — if you use Selector 1 (SPKI hash) in your TLSA record, you hash only the public key, not the full certificate. This means you can renew your TLS certificate with the same key pair without changing the DANE TLSA record at all. The critical constraint: you must keep the same RSA key pair during renewal. If your certificate renewal process generates a new key pair (common with Certbot default settings), the TLSA hash will not match and DANE will break. To preserve the key across renewal: generate the private key separately with openssl, then use that key for CSR generation and renewal. Always pre-publish the new TLSA hash at least 48 hours before rotating to any new key.
How do I know if DANE enforcement is causing inbound delivery failures?
The only reliable external signal for DANE enforcement failures is TLS-RPT (SMTP TLS Reporting, RFC 8460). When a DANE-aware sender like Microsoft Exchange Online or Comcast encounters a TLSA mismatch, they report the failure in the daily TLS-RPT JSON report with a result-type of 'dane-required' or 'validation-failure'. This is the operational mechanism that makes DANE safe to deploy: publish TLS-RPT first, then DANE TLSA records, then monitor reports for failures. Without TLS-RPT configured, DANE delivery failures are completely invisible to the receiving domain — inbound mail is simply dropped with no bounce, no notification, and no error log.
