DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify that answers are authentic and untampered. It builds a chain of trust from the root zone down to your domain using DS, DNSKEY and RRSIG records.

How do I use this DNSSEC checker?

Enter a domain name and run the check; the tool queries authoritative servers and the parent zone server-side, then reports whether a valid DS/DNSKEY/RRSIG chain of trust exists. Nothing you enter is stored.

Why does DNSSEC matter?

Without DNSSEC an attacker can spoof or poison DNS answers to redirect visitors to a fake server, and the resolver has no way to detect it. Valid DNSSEC lets validating resolvers reject forged records, protecting email delivery, TLS and web traffic.

How do I read the result, and what if it fails?

A valid result means the DS record at your registrar matches your zone's DNSKEY and the signatures verify all the way to the root. If it fails, check that your DNS provider has DNSSEC enabled and that the DS record was published at your registrar for the parent zone.

What's a common DNSSEC gotcha?

The most frequent break is a DS/DNSKEY mismatch after a key rollover or after moving DNS providers, which leaves the domain unresolvable for validating resolvers. Also note that a domain with no DNSSEC at all is simply unsigned, which is not the same as a broken chain.

DNSSEC Status Look Up

Related tools

Domain name

What do you want to look up?

Blacklist Look Up

Looks up whether this domain's IP address (or the IP address you entered) appears on common email blacklists (DNSBL) — being listed can cause outgoing mail to be rejected or sent to spam.

Also look up blacklist status when I run this search

What this is

DNSSEC adds cryptographic signatures to DNS so resolvers can verify answers were not forged. A healthy deployment needs three things at once: the zone signed (DNSKEY + RRSIG), the parent anchoring it (DS at the registrar), and validation actually succeeding.

How to read your result

The status check reports each layer. "Not enabled" is safe but unprotected. "Signed but no DS" means wasted effort. "Signed + anchored + validated" is the goal. Any mismatch state is effectively an outage on validating resolvers and needs urgent action.

Common problems and how to fix them

Domain SERVFAILs for many users after a DNS change

How it shows up: Works on some networks, dead on others (especially those using 8.8.8.8, 1.1.1.1, or ISP validators). Started right after changing DNS providers, nameservers, or keys.

How to fix it: Almost always a DS/DNSKEY mismatch. Compare the DS at the registrar with the live KSK; fix whichever side is stale. If you need the site up immediately and cannot fix keys, removing the DS record un-signs the domain (losing protection but restoring resolution) once caches expire.

Want DNSSEC but provider or registrar lacks support

How it shows up: No DNSSEC/DS options anywhere in the control panels.

How to fix it: Both sides must cooperate: the DNS provider signs the zone, the registrar publishes the DS. If either cannot, the practical fix is moving that function to a provider that supports it.

Signatures expire recurrently

How it shows up: The domain breaks on validating resolvers every few weeks, then "fixes itself" after intervention.

How to fix it: The re-signing automation is unreliable. If you run your own DNS servers, schedule and monitor automatic re-signing (e.g. with a signing daemon rather than cron-driven manual signing); on managed DNS, escalate to the provider.

Frequently asked questions

What is DNSSEC?: DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify that answers are authentic and untampered. It builds a chain of trust from the root zone down to your domain using DS, DNSKEY and RRSIG records.
How do I use this DNSSEC checker?: Enter a domain name and run the check; the tool queries authoritative servers and the parent zone server-side, then reports whether a valid DS/DNSKEY/RRSIG chain of trust exists. Nothing you enter is stored.
Why does DNSSEC matter?: Without DNSSEC an attacker can spoof or poison DNS answers to redirect visitors to a fake server, and the resolver has no way to detect it. Valid DNSSEC lets validating resolvers reject forged records, protecting email delivery, TLS and web traffic.
How do I read the result, and what if it fails?: A valid result means the DS record at your registrar matches your zone's DNSKEY and the signatures verify all the way to the root. If it fails, check that your DNS provider has DNSSEC enabled and that the DS record was published at your registrar for the parent zone.
What's a common DNSSEC gotcha?: The most frequent break is a DS/DNSKEY mismatch after a key rollover or after moving DNS providers, which leaves the domain unresolvable for validating resolvers. Also note that a domain with no DNSSEC at all is simply unsigned, which is not the same as a broken chain.

Why it matters

DNSSEC failures are uniquely punishing: a broken chain of trust doesn't degrade gracefully — validating resolvers (used by a large share of the internet, including 8.8.8.8 and 1.1.1.1) return SERVFAIL and the domain simply stops resolving for those users. This check distinguishes the three common states: not signed at all (fine, just unprotected), signed but not anchored (wasted effort), and signed but failing validation (an outage in progress).

Examples

Signed + anchored + validating: the healthy end state — DNS answers are cryptographically verified end to end.
DNSKEY present but no DS record: the signatures exist but nothing links them to the chain of trust — publish the DS through your registrar.
DS present but keys mismatched or signatures expired: validating resolvers reject the domain — this is the state that causes mysterious "site works for some people but not others" reports.