How does DANE improve email security?

Here's the core problem DANE solves: when you send email, the receiving server trusts whoever issues the TLS certificate. But what if a certificate authority gets hacked or coerced into issuing a fake certificate? You'd never know the connection was compromised. DANE fixes that by removing the middleman.

Instead of trusting a certificate authority, DANE lets you publish your actual certificate fingerprint in DNS. When another server connects, it checks that fingerprint against what DNS says it should be. If it matches, the connection is legitimate. If someone tries to use a different certificate (even one issued by a trusted CA), the connection fails. That's called certificate pinning, and it's way stronger than trusting CAs alone.

But DNS itself can be attacked, right. That's where DNSSEC comes in. It cryptographically signs your DNS records so attackers can't forge fake TLSA records. They'd need your private DNS key to pull that off, which is locked down on your authoritative DNS servers. The chain is: your DNS key. The TLSA record. The TLS certificate. Attack any part of that chain and the connection fails safely instead of silently falling back to an insecure connection.

This is especially powerful against rogue certificate authorities or nation-state actors who might pressure a CA into issuing certificates they shouldn't. With DANE, you're in control. The certificate has to match what you published in DNS, period.

That said, DANE only protects the connection between mail servers, not your local authentication. You still need SPF, DKIM, and DMARC to prevent spoofing. And most major mailbox providers don't support DANE for inbound yet, so it's primarily useful if you control both sides of the connection. Ready to explore. Learn more about whether DANE is worth implementing in your region.