DNSSEC Checker

⚙ DNS & authentication

Confirm a domain is DNSSEC-signed, correctly delegated (DS at the parent), and validating.

No sign-up required Runs on our own infrastructure Also available via API
Try:

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

Plain DNS has a fundamental weakness: answers arrive with no proof they’re genuine. A resolver asks “what’s the IP for this domain?” and trusts whatever comes back — which is exactly the gap cache-poisoning and spoofing attacks exploit. DNSSEC closes that gap by signing DNS records cryptographically, so a resolver can verify an answer really came from the zone’s owner and wasn’t altered in flight. This checker tells you whether that protection is actually working for a domain, not just half-configured.

The chain of trust

DNSSEC works by signing records and then linking those signatures upward, zone by zone, all the way to the DNS root — a structure defined in RFC 4033 and its companions. Three record types do the work:

  • DNSKEY — the public keys published in your zone. Signatures are made with the matching private keys.
  • RRSIG — the actual signature attached to each record set, proving it hasn’t been tampered with and hasn’t expired.
  • DS (Delegation Signer) — a hash of your DNSKEY, published in the parent zone (the TLD, via your registrar). This is the link that connects your zone’s signatures to the chain above it.

The critical, easily-missed piece is the DS record. Your zone can be perfectly signed with valid DNSKEYs and RRSIGs, but if the parent has no matching DS, validating resolvers have no way to trust your keys — you’ve built an “island of security” that everyone ignores. Signing the zone and publishing the DS are two separate steps, often in two different control panels, and forgetting the second is the number-one DNSSEC mistake.

How this checker validates

Node’s built-in DNS resolver can’t fetch DNSKEY and DS records or expose validation state, so this tool queries over DNS-over-HTTPS against a validating resolver. It reads the AD (Authenticated Data) flag in the response — the resolver’s own statement that it cryptographically verified the answer. That’s a stronger test than merely finding the records exist: it confirms the whole chain actually validates end to end. If a zone is misconfigured, a validating resolver returns SERVFAIL instead, which we surface so you can act quickly.

Why DNSSEC matters for email

DNSSEC isn’t mandatory for mail to flow, but it’s foundational for the parts of email security that depend on trustworthy DNS. Every lookup your senders and receivers rely on — MX, SPF, DKIM, DMARC — is a DNS query, and DNSSEC is what stops those answers from being forged. More concretely, DANE depends on it entirely: DANE/TLSA (RFC 6698) publishes your mail server’s TLS certificate fingerprint in DNS, and that’s only meaningful if the DNS record itself is signed. No DNSSEC, no DANE.

Enabling it at your registrar

  1. Sign the zone. Most managed DNS hosts (Cloudflare, Route 53, etc.) do this with a single toggle that generates your DNSKEYs and RRSIGs automatically.
  2. Grab the DS record your DNS host produces (or generate it from the DNSKEY).
  3. Publish the DS at your registrar — the company where the domain is registered, which controls the parent delegation. This is the step that completes the chain.
  4. Verify here until you see an authenticated (AD) result, then re-check periodically, since expired RRSIGs can break a previously-working zone.

Frequently asked questions

Is DNSSEC required for email?
Not required, but it’s needed for DANE and hardens DNS against spoofing, protecting MX/SPF/DKIM/DMARC lookups. Optional but recommended.
My zone is signed but the checker says the chain is incomplete.
You have a DNSKEY but no DS at the parent — an “island of security.” Add the DS record at your registrar to complete the chain. Signing and DS publication are separate steps.
Can DNSSEC break my domain?
Yes — expired RRSIGs or a DS/DNSKEY mismatch cause SERVFAIL and make the domain unresolvable for validating resolvers. We flag SERVFAIL so you can act fast.
What is the AD flag and why does it matter?
AD (Authenticated Data) is set by a validating resolver when it has cryptographically verified an answer. Checking for it proves the chain validates, not merely that the records exist.