How this check works
DNSSEC adds signatures to DNS records so that a validating resolver can prove an answer hasn't been altered. The chain of trust runs from the DNS root through the top-level domain to your zone: the parent zone publishes a DS record that vouches for your zone's DNSKEY, and your DNSKEY signs your records.
The check looks up the domain's DS and DNSKEY records, then asks Cloudflare's validating resolver for the domain with DNSSEC checking on. If the resolver validates the answer, it sets the AD ("authenticated data") flag. If validation fails, it returns SERVFAIL; the check then repeats the query with checking disabled to confirm that the failure is caused by DNSSEC rather than a broken zone.
How to read the results
- Secure: DS at the parent, DNSKEY in the zone, and the resolver validated the answer. Everything is working.
- Unsigned: no DS and no DNSKEY. The zone doesn't use DNSSEC. That's still the most common state, and it's not an error.
- Signed but not delegated: DNSKEY records exist but the parent has no DS record, so resolvers treat the zone as unsigned. Add the DS record at your registrar to finish the setup.
- Bogus (broken): the resolver couldn't validate the chain, usually because the DS at the registrar doesn't match the current key, or signatures have expired. Validating resolvers return SERVFAIL, so the domain disappears for a large share of users. Fix this first.
Before you move DNS providers
Moving a signed zone to a new provider without planning breaks validation. Either remove the DS record and wait for it to expire before the move, or use a provider-supported key rollover. See changing nameservers without downtime.
Updated 26 October 2026