Definition
DANE (DNS-based Authentication of Named Entities) for SMTP is a security protocol that uses TLSA (Transport Layer Security Authentication) DNS records to specify which TLS certificate or certificate authority a receiving mail server should present when an incoming SMTP connection is secured with STARTTLS. DANE enables sending mail servers to cryptographically verify that they are connecting to the authentic receiving server, not an attacker intercepting the connection. This prevents TLS downgrade attacks and man-in-the-middle (MITM) attacks against SMTP traffic.
The primary problem DANE solves is the vulnerability of STARTTLS to downgrade attacks. Without DANE, a sending server requests STARTTLS upgrade, and a MITM attacker can strip the STARTTLS announcement, forcing the connection to remain in plaintext. The sending server has no way to know this has happened because there is no out-of-band certificate validation mechanism. DANE solves this by publishing the expected certificate or issuing CA information in DNS, secured by DNSSEC. The sending server checks the TLSA record before establishing the connection and rejects connections that do not match.
DANE adoption for email remains relatively low but is growing, particularly in Europe and among security-conscious organisations. Approximately 5-8% of email domains have published TLSA records as of 2025. The primary barrier is the prerequisite of DNSSEC deployment, which requires DNS infrastructure configuration that many organisations have not implemented. For organisations that have deployed DNSSEC, adding DANE is a relatively simple additional step. DANE is recommended by the UK National Cyber Security Centre (NCSC) and the Dutch government as part of their email security guidelines.
Best Practices
Deploy DNSSEC before implementing DANE. DANE is only as secure as the DNS that delivers the TLSA records. Without DNSSEC, an attacker could forge TLSA records to point to their own certificate, making DANE worse than not using it. Implement DNSSEC signing for your domain, ensure your DNS provider supports DNSSEC, and verify the chain of trust is working correctly.
Start with DANE usage mode 2 or 3 for minimum risk. TLSA records have three usage modes: 0 (CA constraint), 1 (service certificate constraint), 2 (trust anchor assertion), and 3 (domain-issued certificate). Modes 2 and 3 are safest for initial deployment because they pin to specific certificates rather than trusting CAs. Mode 2 and 3 also avoid issues if a CA is compromised. Publish TLSA records for your MX hosts.
Monitor DANE validation success rates after deployment. Not all sending servers support DANE, and some may have connectivity issues with TLSA records. Use your mail server logs to track how many incoming connections include DANE validation and what the success/failure rates are. A high failure rate may indicate TLSA record misconfiguration or DNSSEC issues.
Plan for TLSA certificate rotation carefully. When your MX host's TLS certificate is about to expire, you must update the TLSA record before the certificate change. If the TLSA record still references the old certificate, DANE-validating senders will reject the connection. Maintain a certificate rotation schedule that includes TLSA record updates. Use TLSA records with both current and next certificates during rotation transitions.
Test DANE configuration with online validation tools. Several free tools can check your TLSA records and validate DANE configuration. These tools simulate what a DANE-validating sending server would check. Run these tests after initial deployment and after any certificate change. Fix any issues found before they cause delivery failures.
Related Glossary Terms
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Email Bandwidth
Email sending bandwidth and throughput refer to the rate at which emails can be delivered, typically 100-500 emails/second per IP. Bandwidth planning ensures campaigns complete within desired delivery windows.
Email BIMI VMC
BIMI Verified Mark Certificate (VMC) certifies brand logo ownership for display in supporting email clients. VMCs cost £1,500-2,000+ per year per logo and require DMARC reject or quarantine policy plus SVG logo format.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bulkhead
Email bulkhead pattern isolates transactional emails from marketing sends using separate IPs, subdomains, and servers. This protects critical deliverability and prevents marketing issues from affecting essential transactional messages.
Email DKIM Selector
DKIM selector management involves rotating signing keys across named selectors (default, s1, s2, 2024). Multi-selector strategies allow zero-downtime key rotation every 6-12 months for ongoing email authentication.
Frequently Asked Questions
DANE prevents TLS downgrade and man-in-the-middle attacks on SMTP connections. Without DANE, an attacker can intercept the STARTTLS negotiation and force the connection to proceed in plaintext. DANE provides a way for sending servers to verify the receiving server's certificate cryptographically using DNSSEC-protected DNS records.
Yes. DNSSEC is a strict prerequisite for DANE. Without DNSSEC, the TLSA records delivered via DNS could be forged by an attacker, making DANE not just useless but actively harmful (it would authenticate the attacker's certificate). DANE deployments must ensure DNSSEC signing and validation is functioning correctly.
TLSA records specify the certificate or CA that a receiving server should present for a specific port and protocol combination (typically port 25 for SMTP). The sending server looks up the TLSA record for the recipient domain's MX host, retrieves the certificate during the TLS handshake, and verifies it matches the TLSA record. If it does not match, the sending server should reject the connection.
DANE adoption is modest, with approximately 5-8% of email domains having published TLSA records as of 2025. Adoption is higher in the Netherlands, Germany, and Sweden, where government mandates have driven deployment. Adoption is lower in the US and Asia. DANE validation failure typically results in a delivery delay rather than permanent rejection.
Sending servers that do not support DANE will ignore TLSA records and use standard STARTTLS (with its inherent downgrade vulnerabilities). DANE validation is a best-effort enhancement, not a requirement. This means deploying DANE on your receiving side protects you against MITM attacks from DANE-capable senders but does not affect non-DANE senders.