Standard encryption alone isn't enough anymore. Most systems have adopted Transport Layer Security (TLS) to encrypt connections, but the way those connections get trusted in the first place is still weak. That's where DANE (DNS-based Authentication of Named Entities) comes in, closing the gap between mere encryption and verified identity.
For mail server administrators and security professionals, pairing DANE with DNSSEC is a real defense against man-in-the-middle (MitM) attacks and a cornerstone of modern email hygiene.
The problem with opportunistic TLS
To see why DANE is necessary, look at how email security traditionally works. Simple Mail Transfer Protocol (SMTP) uses a method called STARTTLS (opportunistic TLS). When a sending server connects to a receiving server, it asks: do you support encryption?
If an attacker sits between the two servers, they can strip out that command. The sending server, assuming the receiver doesn't support encryption, downgrades the connection to plain text, and the email goes out in the clear, fully readable by the attacker.
And even when the connection is encrypted, how does the sender know the receiver is who they claim to be? We traditionally rely on Certificate Authorities (CAs), but the CA system depends on hundreds of organizations, any one of which could in theory issue a fake certificate for your domain.
What is DANE?
DANE, defined in RFC 6698, solves this trust problem by binding X.509 digital certificates directly to a domain name using DNS.
It uses a DNS resource record called TLSA, which lets a domain administrator declare exactly which TLS certificate (or Certificate Authority) clients should accept for their domain.
How TLSA records work
A TLSA record acts as a digital fingerprint stored in your DNS zone. It tells the world: when you connect to my mail server on port 25, verify the connection against this specific fingerprint.
If the certificate the server presents doesn't match the fingerprint in the TLSA record, the sending server knows something is wrong, possibly an interception attempt, and refuses to deliver the email.
Why DNSSEC matters here
DANE can't function securely without DNSSEC (Domain Name System Security Extensions).
If you publish a TLSA record in a standard, unsecured DNS zone, an attacker who can intercept your email traffic can likely also intercept and spoof your DNS responses, simply replacing your legitimate TLSA record with a fake one that matches their malicious certificate.
DNSSEC prevents this by adding a cryptographic signature to your DNS records, building a chain of trust from the root zone down to your specific domain. That ensures the TLSA record the sender receives is authentic and hasn't been altered in transit.
In short: DNSSEC authenticates the data, and DANE authenticates the destination.
Why mail servers need DANE right now
Web browsers have been slow to adopt DANE, but the email ecosystem has embraced it. Here's why it matters for your mail infrastructure.
Defeating downgrade attacks
DANE effectively forces the use of TLS. If a TLSA record exists, the sending server knows the receiver must support encryption. If an attacker strips the STARTTLS handshake, delivery fails instead of falling back to insecure plain text.
Independence from the CA system
With DANE, you can essentially become your own Certificate Authority, using "Trust Anchor Assertion" (checking against a specific root CA) or "Domain Issued Certificate" mode. That lets you pin your specific certificate to your domain, so rogue certificates issued by compromised CAs can't be used to impersonate your server.
Future-proofing deliverability
Major email providers and national security centers are increasingly recommending or mandating DANE. As adoption grows, domains without it may eventually be viewed as less trustworthy, which can affect deliverability.
Verify your security posture
Implementing DANE and DNSSEC takes precision. A misconfigured TLSA record can bounce legitimate email, so it's worth validating your configuration to make sure your chain of trust is unbroken.
You can check if your domain is correctly protected by DANE and DNSSEC with our tool: