DANE: pin your mail server's certificate in DNS
DANE publishes a DNSSEC-signed fingerprint of your mail server's certificate, so a sending server can prove it's really talking to you over genuine encryption before it delivers.
A cert fingerprint published in your DNS
Required, or senders ignore the record
Encryption that can't be stripped in transit
Mail encryption can be quietly stripped away
When one mail server sends a message to another, it normally upgrades the connection to TLS so the contents are encrypted in transit. The catch is that this upgrade is optional and unauthenticated by default: an attacker sitting between the two servers can strip the encryption away, or present a fake certificate, and the sending server has no way to know it’s been fooled. The message still gets delivered, but it travelled in the clear or through the attacker.
DANE (DNS-Based Authentication of Named Entities) closes that gap. You publish a small record, called a TLSA record, that is a fingerprint of your mail server’s certificate. Because that record is signed with DNSSEC, a sending server can trust it, look up your certificate’s expected fingerprint before it connects, and refuse to deliver if the certificate it’s offered doesn’t match. Encryption stops being optional, and it can’t be faked.
Why this matters, whoever you are
- DANE protects mail coming in to you against interception and tampering in transit.
- Running your own domains? Senders that enforce DANE can prove they’re talking to your real server over genuine encryption.
- Managing clients? It’s a transport-security control you can verify, score and watch across every domain you protect.
How it works: a fingerprint in DNS
DANE publishes a fingerprint of your mail server’s certificate at a special DNS name tied to your MX host, protected by DNSSEC. A sending server looks it up, connects, and checks that the certificate it’s presented matches. If it doesn’t, delivery stops rather than risk sending your mail through an impostor.
The TLSA record, and why DNSSEC is essential
A TLSA record lives at _25._tcp.<your-mx-host> and encodes a hash of your certificate (or its public key). A sending server that supports DANE fetches it, then compares it to the certificate your mail server presents on port 25.
A TLSA record looks roughly like this:
_25._tcp.mail.example.com. TLSA 3 1 1 0c72ac70b745ac19998811b13...
DNSSEC is not optional here. A TLSA record that isn’t DNSSEC-signed can be forged by the very attacker DANE is meant to stop, so sending servers ignore it entirely. DANE only counts when the whole lookup is authenticated end to end.
What a sending server checks
- That a TLSA record exists for your MX host
- That the lookup is DNSSEC-authenticated
- That your live certificate matches the fingerprint
- If it matches, deliver over verified encryption
- If it doesn’t, refuse to deliver
DANE and MTA-STS: two answers to the same problem
DANE and MTA-STS both exist to make inbound mail encryption enforceable rather than optional. They take different routes. MTA-STS uses a policy file served over HTTPS and doesn’t require DNSSEC, which makes it easy to adopt on any mail platform. DANE binds directly to your certificate through DNSSEC, which is stronger but demands DNSSEC and a mail provider that supports it.
They aren’t mutually exclusive. Many well-run domains publish both, and whether DANE is available to you often comes down to who runs your mail: some providers publish TLSA for you, and some don’t offer it at all. Either way, it’s part of your security posture, so it’s worth knowing where you stand.
The silent failure to watch for
- Your certificate is renewed, as certificates always are
- The TLSA record still points at the old certificate
- The fingerprint no longer matches
- Senders that enforce DANE now refuse your mail
- Nothing warns you: mail simply stops arriving
How DMARCER helps
DMARCER checks whether your domain publishes a TLSA record, confirms the lookup is genuinely DNSSEC-authenticated, and then goes a step further: it connects to your mail server the way a real sender would and verifies that your live certificate still matches what the TLSA record promises. That last check catches the failure almost nobody spots, where a certificate is renewed but the TLSA record is left behind, so mail from DANE-enforcing senders silently starts bouncing. DMARCER scores DANE as part of your posture, tells you plainly whether your mail provider publishes it for you or you need to, and if you self-host it hands you the exact record to add. For a business that means catching a silent mail outage before your customers do; for an MSP it’s the same check, score and alert applied consistently across every client.
Related
MTA-STS →
The other way to enforce mail encryption.
DANE checker →
Check your TLSA record free, in seconds.
DNSSEC →
The foundation DANE is built on.
See where your domain stands on DANE
Run a free check to see your posture, and let DMARCER watch your TLSA record against your live certificate so a renewal never quietly stops your mail.
Check your domain