How does DANE authenticate SMTP connections?

Here's how DANE verification actually works when one mail server connects to another. It's a series of steps, each one building trust without relying on a certificate authority.

Your sending server wants to deliver a message to mail.example.com. First, it looks up the MX record to find the mail server's address. Then it does something different: it queries DNS for the TLSA record at `_25._tcp.mail.example.com` (that underscore-prefixed format is DANE-specific). But it doesn't just accept whatever DNS hands back. It validates the DNSSEC signature on that TLSA record using the domain's public key. If the signature verifies, the record is authentic and hasn't been tampered with.

Next, your sending server initiates a TLS connection to the receiving server and gets its certificate. Now comes the comparison: it checks whether that certificate matches what the TLSA record says. The record specifies exactly which certificate (or which CA certificate) should be presented. If there's a match, great. The connection is trusted, and the message can be delivered.

But if the certificate doesn't match what's in the TLSA record, something's wrong. Maybe the certificate was hacked. Maybe someone's trying to intercept the connection. So the sending server rejects the connection entirely. No message gets through. That's the enforcement part of DANE.

The whole system depends on DNSSEC being enabled at every step. If DNSSEC isn't validating on the sending server's end, the protection falls apart. That's why understanding DNSSEC is critical before deploying DANE. Ready to see if your domain supports DNSSEC? Check your email authentication setup.