What is DNSSEC, and what does it do for your email?

Every email check starts with a DNS lookup. A sending server looks up your MX records to deliver to you; a receiving server looks up your SPF, DKIM and DMARC records to judge mail that claims to be from you. DNSSEC lets those lookups prove the answers are genuine. This guide explains what it protects, what it doesn't, how it relates to DANE, and how to turn it on without breaking mail. For DANE itself, read What is DANE for SMTP?.

What is DNSSEC?

DNSSEC is the set of DNS Security Extensions defined in RFC 4033, RFC 4034 and RFC 4035, published in 2005. RFC 4033 sums it up: the extensions "provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution."

In plain terms, your DNS host signs every set of records in your zone. A validating resolver checks the signature before it trusts the answer. ICANN describes the two benefits as data origin authentication, which lets a resolver confirm where the data came from, and data integrity protection, which lets it know "the data hasn't been modified in transit." ICANN also notes that "the DNS root zone has been signed since 2010."

What does DNSSEC protect for email?

Without DNSSEC, a resolver accepts whatever answer arrives first if it looks right. An attacker who can forge or poison that answer could:

• Point your MX at their server, so a sender delivers your inbound mail to them.
• Replace your SPF record with one that authorizes their servers.
• Return a fake DKIM public key, or hide your DMARC record.

With DNSSEC, a validating resolver rejects these forged answers, because the attacker can't produce valid signatures. That protects every record your email depends on, as long as the resolver doing the lookup validates.

How does the chain of trust work?

DNSSEC adds a few record types. These are the ones you'll see:

A resolver starts from the root key it already trusts and works down. RFC 4033 describes it: the DS record "resides at a delegation point in a parent zone and indicates the public key(s)" used to sign the child's DNSKEY set, and "the typical authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset."

For example.com, that means:

1. The root's key signs the DS record for .com.
2. The .com key signs the DS record for example.com.
3. That DS matches example.com's DNSKEY.
4. example.com's key signs its MX, TXT and other records.

Break any link and validation fails. RFC 4035 defines the results:

That last row is the operational risk. RFC 4035 says that when signatures don't validate on a recursive query, "the name server MUST return RCODE 2" (server failure). Validating resolvers fail closed.

What doesn't DNSSEC protect?

DNSSEC is narrower than many people expect.

• It doesn't encrypt. RFC 4033 is direct: "These extensions do not provide confidentiality." DNS queries and answers stay visible, and your email isn't encrypted by DNSSEC. That's the job of STARTTLS, MTA-STS and DANE.
• It doesn't stop denial of service. RFC 4033: "DNSSEC provides no protection against denial of service attacks."
• It doesn't protect your DNS account. If someone logs in to your registrar or DNS host and changes your MX, the DNS host signs the attacker's records too. See domain registrar security and registry lock.
• It doesn't stop spoofing on its own. A signed zone still needs SPF, DKIM and DMARC at enforcement to tell receivers what to do with forged mail. See SPF vs DKIM vs DMARC.
• It only helps when the resolver validates. A sender whose resolver doesn't validate DNSSEC gets no protection from it.

Why does DANE need DNSSEC?

DANE lets you publish TLSA records that tell sending servers which certificate your mail servers use. Those records are only trustworthy if they're signed. RFC 7672 says DANE "can authenticate message delivery to the intended next-hop domain only when the MX records are obtained securely via a DNSSEC-validated lookup."

So DANE needs two signed zones: yours, for the MX records, and the zone of your MX hosts, for the TLSA records. If your MX points to Microsoft 365, Google Workspace or a filtering service, the provider controls the second part. Microsoft supports inbound DANE for Exchange Online as an opt-in that includes enabling DNSSEC for your domain (Microsoft Learn). Our DANE guide covers those steps.

How do you enable DNSSEC?

DNSSEC is a two-party job: your DNS host signs the zone, and your registrar publishes the DS record in the parent zone. If they're the same company, it may be one switch.

General procedure

1. Check support. Confirm your DNS host can sign zones and your registrar accepts DS records for your TLD.
2. Turn on signing at the DNS host. It generates keys and signs your zone, then shows you the DS values: key tag, algorithm, digest type and digest.
3. Add the DS record at the registrar, copying each field exactly. Some registrars ask for the DNSKEY instead.
4. Wait and verify. Check that the parent publishes your DS and that validating resolvers return authenticated answers (see below).

Example: Cloudflare

At the time of writing (October 2026), Cloudflare's documentation gives these steps:

1. In the Cloudflare dashboard, go to the DNS Settings page.
2. For DNSSEC, click Enable DNSSEC.
3. Copy the values from the dialog. You can reopen them later by clicking DS record on the DNSSEC card.
4. Add the DS record at your registrar. Cloudflare uses "Algorithm 13", which a registrar may list as "ECDSA Curve P-256 with SHA-256".

Cloudflare says it "automatically adds DS records for domains using Cloudflare Registrar or those using .ch and .cz top-level domains," and that for Cloudflare Registrar this automatic DS submission "can take one to two days." For the rest of your email DNS at Cloudflare, see adding SPF, DKIM and DMARC records in Cloudflare.

Other DNS hosts and registrars use different menus, so search their help for "DNSSEC" or "DS record". Our GoDaddy and Namecheap DNS walkthroughs show where records live at those two providers.

What can go wrong with DNSSEC?

DNSSEC failures take your whole domain offline for validating resolvers, including mail delivery to you.

Moving DNS hosts with the old DS record in place

This is the most common outage. Your registrar still publishes a DS for the old provider's keys, while the new provider signs with different keys or not at all. Cloudflare warns that if you change nameservers "before the old DS TTL has fully expired, validating resolvers will return SERVFAIL because the cached DS records will not match." Its documented order for a move without multi-signer support:

1. Remove the DS record at your registrar.
2. Wait for the DS TTL to expire at the parent. Cloudflare says to verify with dig DS example.com and that this is "commonly 24–48 hours for most TLDs."
3. Change nameservers.
4. Wait for the old NS TTL to expire.
5. Enable DNSSEC at the new provider and add the new DS record.

Turning DNSSEC off follows the same logic: remove the DS first, and keep signing until the DS TTL has expired.

Expired signatures

RRSIGs have an inception and expiration time. RFC 4034 says an RRSIG "MUST NOT be used for authentication after the expiration date." Managed DNS hosts re-sign automatically. If you sign your own zone, make sure re-signing is automated and monitored, or the zone goes bogus on a fixed date.

Key rollovers done out of order

Changing the key-signing key means publishing a new DS at the parent. Removing the old key before the new DS is live and cached breaks the chain. Follow your provider's rollover process rather than doing it by hand.

What it looks like for email

When a validating sender can't resolve your MX because of a bogus answer, the message isn't delivered. Senders usually retry and then bounce with a DNS or temporary failure. For background, see what happens to email when your server is down.

How do you check DNSSEC for your domain?

Our free tools don't validate DNSSEC yet, so use dig or your registrar:

1. Is there a DS at the parent? dig DS example.com +short. No output means DNSSEC isn't enabled at the registrar.
2. Is the zone signed? dig DNSKEY example.com +short should return keys, and dig +dnssec MX example.com should include RRSIG records.
3. Does it validate? Query a validating resolver, for example dig +dnssec MX example.com @1.1.1.1, and look for the ad (authenticated data) flag in the header.
4. Does a failure show up? If you get SERVFAIL, repeat with +cd (checking disabled). If that works, DNSSEC validation is the problem.
5. Check the records it protects. Use the MX Lookup and Email Health Check to confirm the MX, SPF and DMARC records are the ones you intend.

Should you turn on DNSSEC?

Next steps

• Check whether your domain already has a DS record with dig DS yourdomain.com.
• Before any DNS host move, write down where the DS record is managed and remove it first.
• If you want DANE, enable DNSSEC, then follow our DANE guide.
• Protect the accounts that control your DNS, because DNSSEC can't. iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC records change.

Read more email security basics.