Skip to main content
All fixes

Email deliverability, DNS, SPF/DKIM/DMARC

Fix DNSSEC Not Enabled on Production Domain

Without DNSSEC, your DNS responses can be spoofed by on-path attackers. Enable DNSSEC at your DNS provider and publish DS at the registrar.

What's happening

DNSSEC (RFC 4033-4035) protects DNS responses from tampering by attaching cryptographic signatures that resolvers verify against a chain of trust rooted at the DNS root zone. Without DNSSEC, an attacker on the network path between a resolver and an authoritative nameserver can inject forged responses for your domain.

Practical attacks include redirecting your MX records to an attacker-controlled mail server (intercepting inbound mail), or pointing your A record at a phishing site. Cache-poisoning attacks at recursive resolvers similarly affect every user of that resolver, not just one path. DNSSEC validation by the resolver detects forged responses and returns SERVFAIL instead.

Most major TLDs require DNSSEC support, and major DNS providers (Cloudflare DNS, Route 53, Google Cloud DNS, NS1) make it a one-click feature. The remaining barrier is publishing the DS record at the registrar — which is the customer's responsibility and often forgotten.

Why it matters

Active attacks succeed. Public Wi-Fi networks, compromised ISP infrastructure, and BGP-hijack-then-DNS-spoof attacks all become viable against your domain. The attacker gains the ability to read inbound mail or impersonate your website to your users.

Compliance frameworks increasingly require DNSSEC. NIST SP 800-81 recommends it for federal-related systems;.gov and.mil require it. SOC 2 type-2 audits sometimes flag missing DNSSEC as a finding under network security controls.

Email-impersonation defense weakens. SPF, DKIM, and DMARC depend on the integrity of DNS responses. If DNS can be spoofed, an attacker can forge SPF or DKIM records that look valid to receivers and pass authentication for spoofed mail.

Common causes

  • DNSSEC was never enabled at the DNS provider.
  • DNSSEC enabled at the provider, but DS not published at the registrar.
  • Domain on a TLD that does not support DNSSEC (rare — most major TLDs support it).
  • Registrar lacks UI for DS record submission (some legacy registrars).
  • Operator concern about complexity or fear of breakage prevented adoption.

Detect this on your site

Run a quick scan with the DNS Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open DNS Checker

How to fix it

  1. 1

    Verify current DNSSEC state

    Run dig +dnssec example.com SOA. If the response includes the AD (Authenticated Data) flag in the flags line, DNSSEC is working. If no AD flag and no DNSKEY records appear in dig +short DNSKEY example.com, DNSSEC is not enabled. Also verify with dnsviz.net/d/example.com.

  2. 2

    Enable DNSSEC at your DNS provider

    Cloudflare DNS: dashboard > DNS > Settings > DNSSEC > Enable. Route 53: hosted zone > DNSSEC signing > Enable signing. Google Cloud DNS: DNS zone > DNSSEC > On. NS1, dnsimple, deSEC, Namecheap PremiumDNS: similar one-click toggle. The provider generates KSK and ZSK keys automatically.

  3. 3

    Retrieve the DS record from the provider

    After enabling, the provider displays the DS record(s) for you to publish at the registrar. Format is " ". Algorithm 13 (ECDSAP256SHA256) and digest type 2 (SHA-256) are modern defaults. Copy all four fields exactly.

  4. 4

    Publish DS at the registrar

    Cloudflare Registrar: domain > DNS > DNSSEC > add DS. Namecheap: domain list > Manage > Advanced DNS > DNSSEC > add. Google Domains: DNS > DNSSEC > Custom records. Each registrar has slightly different UI. Submit the DS record exactly as provided by the DNS provider.

  5. 5

    Wait for parent-zone propagation

    DS records appear in the parent zone (.com,.net,.io etc.) within minutes to a few hours. Run dig +short DS example.com periodically until the DS record appears. Validating resolvers begin validating responses on their next cache miss.

  6. 6

    Confirm the chain is intact

    Visit dnsviz.net/d/example.com. The visual chain should be all green. Run dig +dnssec example.com SOA against 1.1.1.1 and 8.8.8.8 and confirm the AD flag is set. Send a test message and check Authentication-Results — SPF and DKIM lookups now resolve through validated DNS.

Example

# Verify DNSSEC enabled (AD flag in flags line means validated)
dig +dnssec example.com SOA

# Pull DS record at registrar level
dig +short DS example.com
# expected output: "<keytag> 13 2 <hex-digest>"

# Confirm chain via Cloudflare resolver
dig @1.1.1.1 +dnssec example.com SOA

Verification commands for a freshly enabled DNSSEC chain.

Frequently asked

Only if the DS record at the registrar does not match the DNSKEY in your zone. Modern providers prevent this by automating both sides — Cloudflare Registrar with Cloudflare DNS Route 53 within AWS — but cross-provider setups (DNS at Provider A registrar at Provider B) require manual DS publication and are the most common failure mode.

Most managed providers rotate ZSK (Zone Signing Key) every 30-90 days automatically with no DS update needed. KSK (Key Signing Key) rotation requires DS update at the registrar and is typically annual or longer. Check your provider's documentation for the rotation schedule.

Optional. Production domains benefit most. Staging domains used internally with non-validating resolvers gain little. If staging is publicly accessible enable DNSSEC to keep parity with production and catch chain errors before they reach production.

Related fixes

Email deliverability, DNS, SPF/DKIM/DMARC

Fix Broken DNSSEC Chain on Email or Web Domain

Email deliverability, DNS, SPF/DKIM/DMARC

Fix Nameserver Mismatch Between Registrar and DNS Host

Email deliverability, DNS, SPF/DKIM/DMARC

Fix Slow DNS Propagation After a Record Change

Email deliverability, DNS, SPF/DKIM/DMARC

Fix SPF TempError on Outbound Mail Authentication

Email deliverability, DNS, SPF/DKIM/DMARC

Fix Missing MTA-STS Policy on Receiving Domain