DNSSEC and DANE

Every check covered so far – SPF, DKIM, DMARC, MTA-STS – is read from DNS. None of it means anything if the DNS response itself can be forged in transit. That's the specific problem DNSSEC solves.

DNSSEC: signing the DNS itself

DNSSEC cryptographically signs DNS responses so a validating resolver can confirm a record actually came from the real zone and wasn't tampered with along the way (cache poisoning, on-path interception). Without it, a sufficiently positioned attacker could forge a fake SPF or DMARC record and have it accepted as real. DNSSEC doesn't add a new email-security check on its own – it's what makes every other check in this course trustworthy at the DNS layer.

DANE: pinning the certificate itself, using DNSSEC

DANE (DNS-Based Authentication of Named Entities) publishes a TLSA record that pins the exact TLS certificate a mail server should present – an alternative to trusting the public certificate authority system alone:

_25._tcp.mail.example.com   TLSA   3 1 1 <certificate hash>

The detail almost every DANE explanation skips

A TLSA record is only a real guarantee if it's DNSSEC-validated. An unsigned TLSA record can be forged by exactly the same attacker who could forge any other unsigned DNS record – so "a TLSA record exists" and "a TLSA record is cryptographically trustworthy" are two different claims. A correct DANE check has to look at the resolver's own AD (Authenticated Data) flag on the TLSA lookup, not just whether a record is present, to tell "present but unvalidated" apart from "fully validated." ActiScan's DANE checker makes exactly that distinction, rather than treating any TLSA record as a pass.