What is DNSSEC? (and what it protects for email)

The one-sentence version

DNSSEC (DNS Security Extensions) adds a cryptographic signature to your DNS records so a resolver can prove an answer genuinely came from you and was not altered on the way. It does not encrypt anything. It makes tampering detectable.

What DNSSEC actually does

Plain DNS has no way to tell a real answer from a forged one. DNSSEC fixes that with signatures, and it is precise about its job: it provides origin authentication, data integrity, and authenticated proof that a name does not exist. It deliberately does not provide confidentiality, so it is not a privacy feature. A few new record types carry it:

• DNSKEY publishes your zone's public signing keys.
• RRSIG is the signature over a set of records, proving they are intact.
• DS (Delegation Signer) lives in the parent zone and links your zone's key into the chain above you.
• NSEC / NSEC3 prove, with a signature, that a name really has no records, so a “does not exist” answer cannot be faked either.

The chain of trust

DNSSEC works by each level of DNS vouching for the one below it: the root signs the top-level domains, .com signs your domain, and so on. The link is the DS record, a hash of your key that lives in your parent zone. When you turn DNSSEC on, your registrar publishes that DS record to the registry, which is what splices your domain into the global chain. A validating resolver walks the chain from the root down and rejects anything that does not verify.

Under the hood, operators usually split their keys into a key-signing key and a zone-signing key (one signs the keys, the other signs the records) so they can rotate the working key without re-coordinating with the parent. That split is a common practice, not a rule.

What it protects for your email

This is where a DNS-security feature reaches your deliverability. Your SPF, DKIM, and DMARC policies are just public DNS records, and your MX record decides where your mail is delivered. Without DNSSEC, an attacker positioned on the network could forge a reply that says “this domain has no DMARC record” or points your MX at their own server. DNSSEC makes those answers tamper-evident: a validating resolver sees the signature fail and withholds the forged reply rather than trusting it.

Keep this in proportion. DNS forgery is a real attack but not an everyday one for a typical business, and the classic cache-poisoning technique was largely defanged years ago. DNSSEC raises the floor; it is not a response to an active emergency.

DNSSEC is not required for email authentication

A common misconception worth killing: you do not need DNSSEC to run SPF, DKIM, or DMARC. They work over ordinary DNS. The one email technology that hard-requires DNSSEC is DANE (which publishes your mail server's certificate in DNS). The industry's answer for everyone without DNSSEC is MTA-STS, which was designed specifically as the non-DNSSEC way to secure inbound mail in transit. So DNSSEC is a worthwhile hardening step, not a prerequisite for getting your email authentication right.

The warning: a botched rollover takes everything down

DNSSEC fails closed, and that is the catch. If your published DS record stops matching your live key, or a signature is allowed to expire, validating resolvers do not fall back to the unsigned answer. They return an error (SERVFAIL) for your entire domain, taking your website and your email down together. Two things make it nasty:

• It is all or nothing. One expired signature breaks every name in the zone, not just one record.
• It is easy to miss. Resolvers that do not validate still serve your domain fine, so it can look healthy from your desk while everyone behind a validating resolver (Google's 8.8.8.8 and Cloudflare's 1.1.1.1 both validate) is locked out. Expired DNSSEC signatures have knocked major domains, and even a national top-level domain, offline this way.

None of that is a flaw in DNSSEC. It is the cost of a system that refuses to serve data it cannot prove, and it is why the riskiest moment is a key rollover done by hand.

Should you turn it on?

For most domains, it is a reasonable yes, with one condition. When your registrar and your DNS host are the same provider (or cooperate through automated DS maintenance), enabling DNSSEC is close to one click and the rollovers are handled for you. The danger lives in the split setup, DNS at one provider and the DS record pasted by hand at another, where a mismatch becomes the all-or-nothing outage above. If you cannot automate it, weigh the modest protection against the operational risk honestly.

Common questions

Does DNSSEC encrypt my DNS?

No. DNSSEC signs your records so forgery is detectable, but the queries and answers are still sent in the clear. Encrypting DNS traffic is a separate thing (DNS over HTTPS or TLS).

Is DNSSEC required for DMARC or email?

No. SPF, DKIM, and DMARC run over ordinary DNS. DNSSEC protects those records from tampering but is not a prerequisite. Only DANE strictly requires it; MTA-STS exists as the non-DNSSEC alternative.

Can DNSSEC take my website and email offline?

Yes, if it is misconfigured. A DS record that no longer matches your key, or an expired signature, makes validating resolvers return errors for your whole domain. That is why automated key management (or a careful, tested rollover) matters.