DANE for Email: What It Is and Why It Matters

May 5, 20266 min

DANE (DNS-Based Authentication of Named Entities) takes email encryption a step further than MTA-STS. Where MTA-STS relies on a policy file fetched over HTTPS, DANE pins your mail server's TLS certificate directly in DNS, secured by DNSSEC.

This means a sending server can verify your mail server's identity through DNS alone, without trusting any certificate authority. It's the strongest form of email transport security available today.

How DANE works for email

DANE for email (specifically DANE-TA and DANE-EE, defined in RFC 7672) works by publishing TLSA records in DNS for your mail server. A TLSA record contains a hash of your mail server's TLS certificate or its public key.

When a sending server wants to deliver email to your domain, it:

Looks up your MX records to find your mail server
Checks for TLSA records at _25._tcp.mail.yourdomain.com (port 25 for SMTP)
Connects to your mail server over TLS and compares the certificate against the TLSA record
If the certificate matches, the connection is authenticated. If not, delivery fails (protecting against man-in-the-middle attacks)

DANE requires DNSSEC on your domain. Without DNSSEC, TLSA records can be spoofed, defeating the entire purpose. This is the main barrier to adoption.

DANE vs MTA-STS

Both DANE and MTA-STS aim to prevent TLS downgrade attacks on email, but they take different approaches:

MTA-STS relies on HTTPS and certificate authorities. It's easier to deploy but depends on the CA system.
DANE relies on DNSSEC and publishes certificate data directly in DNS. It's stronger but requires DNSSEC infrastructure.
MTA-STS has broader support among email providers today. DANE support is growing but not yet universal.
They can coexist. If both are deployed, sending servers that support DANE will use it; others fall back to MTA-STS.

Prerequisites for DANE

Before you can deploy DANE for email, you need:

DNSSEC enabled on your domain with a valid chain of trust from the root zone
DS records published at your domain registrar
A mail server with a valid TLS certificate (Let's Encrypt works fine)
TLSA records published for each MX hostname

The DNSSEC requirement is the main reason DANE adoption is lower than MTA-STS. Setting up DNSSEC requires coordination between your DNS provider and your domain registrar, and not all providers support it well. But if your infrastructure already uses DNSSEC, adding DANE is straightforward.

Publishing TLSA records

A TLSA record specifies how to verify your mail server's certificate. The most common configuration for email is:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 <SHA-256 hash of your certificate's public key>

The parameters (3 1 1) mean: match the end-entity certificate, use the public key only, and hash it with SHA-256. This is the recommended configuration because it survives certificate renewals as long as you keep the same key pair.

Monitoring DANE

DANE requires ongoing monitoring because several things can break it:

Certificate renewals that change the public key without updating TLSA records
DNSSEC signature expiration if zone re-signing fails
DS record mismatches after key rollovers at the registrar
Changes to MX records that point to servers without matching TLSA records

How MailShield monitors DANE

MailShield validates your entire DNSSEC chain of trust, checks DS records at the registry level, verifies TLSA records against your mail server's actual certificate, and monitors for signature expiration. If anything in the chain breaks, we alert you immediately.

Add your domain to see your current DNSSEC and DANE status. We'll show you exactly what's configured, what's missing, and what to fix. Free for up to 2 domains.