08 october 2025, 11:07
362
DANE enables a cryptographic binding (with a dedicated TLSA DNS record) between your domain’s TLS certificate and the domain itself. SMTP peers can now verify certificates without relying on the certificate authority only. This adds a new layer of protection that complements TLS, MTA-STS and TLS-RPT.
So, What’s DANE?
Another day, another acronym, right? We’re already familiar with SPF, DKIM, DMARC, TLS, MTA-STS, and now some DANE joins the party. Well, at least it has a cute name...
Actually, DANE stands for DNS-based Authentication of Named Entities. To put it plainly, DANE lets you publish information about your mail server’s TLS certificates directly in the DNS. This information is cryptographically protected with DNSSEC (DNS Security Extensions) and thus can be trusted.
When another mail server tries to deliver mail to you, with DANE it doesn’t solely rely on the Certificate Authority (CA) system to check your TLS certificate. It will also look up your domain's special DNS record, called TLSA, confirm it with DNSSEC, and make sure it’s really the TLS certificate you intended.
Why should a marketer or a business owner care? Because it means one less chance for your messages to be intercepted, spoofed, or tampered with on their way across the network.
Why DANE Was Created
TLS is great, but not at all bulletproof. The whole trust system rests on Certificate Authorities, organizations that issue digital certificates. There are hundreds of CAs worldwide, and your server will happily accept a certificate issued by any of them. That’s a lot of trust to put in a lot of different entities.
History shows us that sometimes, that trust is misplaced. CAs may be hacked, tricked, or otherwise compromised. As a result, hackers can issue certificates that appear completely valid.
Now imagine this: your server sets up what looks like a secure TLS connection, because the certificate is technically valid. But behind the scenes, an attacker has managed to get a fake certificate for your domain through a rogue or compromised CA. They get on the wires, decrypt your traffic, and re-encrypt it before passing it on.
From your perspective, TLS is working perfectly. Little do you know that your emails are being quietly read, logged, or even altered on the fly. And that’s exactly the kind of nightmare that DANE was designed to prevent.
Why Certificates Alone Aren’t Enough
As you now see, the traditional CA-based model has some flaws. It’s like trusting every locksmith in the world to have a copy of your house key, and just hoping no one goes rogue.
With normal TLS, if a server presents a certificate signed by any CA your system trusts, the connection will be accepted. Whether that certificate was legitimately meant for you is a totally different story. DANE fixes this by giving your domain a way to identify, or pin, the exact certificate you expect to be used.
So even if a CA somehow issues another certificate for your domain, DANE will reject it because it doesn’t match your published TLSA record. It’s another layer of assurance on top of the CA system, one that attackers can’t bypass so easily.
In layman's terms, TLS is your bully bouncer at the club, checking IDs, while DANE is the guest list at the door. Until the two line up, nobody is able to get in.
DNSSEC, TLS, MTA-STS and Company: Orchestrating the Security Stack
One of the very confusing parts of email security is how many acronyms and standards are involved. DANE doesn’t replace the others – it works alongside them. Here’s how:
- DNSSEC (DNS Security Extensions) is the foundation. Without DNSSEC, DANE simply doesn’t work. DNSSEC signs your DNS data so nobody can tamper with it in transit. DANE relies on that security to publish TLS info you can trust.
- TLS is the protocol that encrypts the connection. DANE makes sure the certificate used for the encrypted session is really yours.
- TLS-RPT is the reporting framework that keeps you informed when TLS connections fail. If you’ve got DANE deployed, TLS-RPT can help you find out whether peers are validating it properly and spot problems before they ruin your day. Stay tuned for our next article on email security where we'll discuss it in detail.
- MTA-STS is a policy-based standard that we've already discussed in detail. It tells other mail servers: “you must use TLS with me, no excuses accepted”. Unlike DANE, however, it doesn’t require DNSSEC, relying on the CA system. Working together, MTA-STS and DANE cover different failure modes: one ensures TLS is mandatory, the other ensures the certificate is the right one.
How DANE Works, Step by Step
Let’s now walk through how DANE actually operates.
Step 0. DNSSEC in place: As a prerequisite, your domain operator must support DNSSEC. No DNSSEC – no DANE.
Step 1. Publishing TLSA records: For each of your mail servers, you need to publish a special DNS record called a TLSA (TLS Authentication) record. It contains a few fields that define what certificate is expected.
Example:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-cert>
This one essentially says: “For TCP connections on port 25 to mail.example.com, the server must present this exact certificate (verified by a given hash)”.
Step 2. A sending server looks it up: Whenever someone’s mail server wants to send you an email, it first looks up your domain’s MX record to see where to deliver. Then it looks for a TLSA record matching the MX host name.
Step 3. Validation via DNSSEC: If the TLSA record exists, the sending server makes sure it is signed with DNSSEC. That proves the record is authentic and hasn’t been tampered with.
Step 4. TLS handshake: The connection between two SMTP servers is established with STARTTLS. The receiving server presents its TLS certificate.
Step 5. Certificate check: The sending server checks whether the certificate matches what your TLSA record says by calculating its hash value. If it does – mail flows unhindered. If not – depending on policy, the message may be deferred or rejected.
In summary, the DNSSEC-anchored TLSA record acts like a cryptographic lock on the expected certificate. Thus, attackers cannot slip in with a fake cert.
Setting Up DANE
Now to the practical part: how do you actually enable DANE for your mail system?
Step 1: Check for DNSSEC
Your registrar or DNS host must support DNSSEC. Make sure it's enabled for your domain, publish DS records at the parent zone, and confirm your DNS responses are signed.
Step 2: Decide your TLSA strategy
There are different usage modes. The most basic one is “end-entity” (EE), where you pin the exact certificate hash. Another is “trust anchor” (TA), where you pin the CA or key you trust, which solves the potential problem with rotating certificates.
Step 3: Generate TLSA records
For each MX host, generate a TLSA record. You do not need to do this by hand, quite a few tools are available to make life easier, like TLSA Record Generator.
Conceptually you’re just publishing:
- Which port/protocol/hostname the record relates to (e. g. 25/tcp/mail.example.com)
- What to match (an exact certificate, CA, key, etc.)
- The hash value for that match
Step 4: Publish records in DNS
Add the TLSA records to your DNS zone, sign them with DNSSEC, and make sure they resolve correctly. Allow the records to propagate.
Step 5: Check your mail servers
Make sure your MX hosts present the certificate that matches the TLSA record. If you are using a provider that rotates certs often, you may need some automation to keep records updated.
Step 6: Stay alert
Keep an eye on TLS-RPT reports and your mail logs to spot issues quickly.
Troubleshooting DANE
In general, DANE is a robust technology that tends to "just work" once set up properly. However, like any security control, DANE has its own potential failure modes. Here are some of the common ones to watch out for:
DNSSEC misconfiguration: If your zone isn’t properly signed, or your DS record at the registrar is wrong, nobody can validate your TLSA records. If problems arise, re-check DNSSEC settings and re-sign your zone. Contact your domain operator for help if necessary.
Certificate mismatch: If you published the wrong hash in your TLSA record, your mail server’s cert just won’t match. Regenerate the TLSA record with the correct parameters.
Certificate rotation issues: If you rely on automated certificate issuance (like the one provided by Let’s Encrypt), you'll need automation to update TLSA records accordingly or use a TA strategy. Otherwise, certs will rotate out and DANE validation will break.
Shared infrastructure: If your MX is hosted on shared servers, make sure the certificate being presented always matches the one you’ve published. Providers that aren’t set up for DANE may change a cert without notice, so coordination may be required.
Conclusion
DANE might not be the most famous acronym in the email security alphabet soup, but it closes a real gap. By letting you pin certificates in DNSSEC-signed records, it remedies potential trust issues with CAs and prevents man-in-the-middle attacks that would otherwise slip past TLS.
It’s not a replacement for TLS, MTA-STS, or TLS-RPT – it’s a complement. Together, they all form a layered defense that makes your email exchange far more secure and less prone to hacker attacks.
If you run your own mail infrastructure and your DNS supports DNSSEC, DANE is definitely worth implementing. It does not take much effort, compared to potential benefits. Start small, test it on one domain, monitor the results. It’s another brick in the wall… I mean, another step up the ladder toward emails that are not just delivered, but delivered securely.
Related services
Deliver emails securely and reliably with UniOne and with no need to maintain your own mail servers. Connect your application, CRM, or website to highly performing infrastructure and send transactional or marketing messages at scale.
From password resets to purchase confirmations, transactional emails form the backbone of your communication with users. UniOne's capabilities allow you to be sure these messages are sent safely, following all the best email practices and security standards, and reach their recipients on time.
As an API-first email delivery platform, UniOne provides a simple yet powerful way to send, monitor, and manage emails via integrations. With RESTful endpoints, real-time analytics, and webhook support, integrating UniOne into your stack is a clear and quick process.
