How to Check if DNSSEC Is Enabled (and Working) for a Domain

To check whether DNSSEC is enabled for a domain, look for a DS record at the registry and DNSKEY records at the domain's DNS host, then see whether a validating resolver accepts the chain. The DNSSEC checker does all three for one domain or a list and returns Signed and valid, Broken, Keys but no DS, Signed but not validated, or Not signed. Paste up to 100 domains with no account, or 500 after a free Google sign-in.

Most domains are not signed, and that is fine. The status that needs action is Broken, because it is the one that can take a domain offline for part of the internet.

How DNSSEC works, briefly

DNSSEC adds signatures to DNS answers so a resolver can tell they weren't forged (RFC 4033). Three pieces matter:

1. The domain's DNS host signs the zone and publishes its public keys as DNSKEY records.
2. The registry publishes a DS record, a fingerprint of the key-signing key, in the parent zone (.com, .org and so on).
3. A validating resolver follows the chain from the root's key down through each DS to the domain's keys (RFC 4035).

If the DS at the registry and the keys at the DNS host don't match, the chain is broken, and resolvers that validate refuse to answer for the domain at all.

Step 1: enter the domains

Paste one domain, or a list one per line. Addresses and URLs work; subdomains are reduced to the registered name.

Step 2: run the check

Press Check DNSSEC. Each domain's DS and DNSKEY records are requested from Google Public DNS over HTTPS, with Cloudflare as the fallback, asking for the authenticated-data (AD) flag as RFC 6840 describes. If the resolver sets AD, the chain validated. If it answers SERVFAIL but answers when checking is disabled, the chain exists but fails, which is Broken.

Step 3: read the status

Status	Meaning	What to do
Signed and valid	DS at the registry, DNSKEY in the zone, and the resolver validated it	Nothing
Broken	A DS is published, but the zone's keys or signatures don't match it	Fix now: validating resolvers refuse the domain
Keys but no DS	The DNS host signs the zone, but the DS was never added at the registrar	Add the DS at the registrar, or turn signing off
Signed, not validated	Both are published, but the resolver didn't validate, often an unsupported algorithm	Check the algorithm
Not signed	Neither record exists	Still the case for most domains; no action needed

The usual cause of Broken is moving a domain to a new DNS host without removing the old DS record at the registrar. The new host's zone isn't signed, or is signed with different keys, and the old fingerprint now points at nothing.

Step 4: fix a broken domain

1. Decide whether you want DNSSEC on this domain at all.
2. If not, remove the DS record in the registrar's DNSSEC settings. Once caches expire, validating resolvers stop failing.
3. If so, make sure the DNS host signs the zone, then copy the DS record it gives you into the registrar so the two match.

Caches can show the old state for up to the record's TTL after a change, so run the check again after that time. The DNS propagation checker helps to see what different resolvers return.

Which algorithm?

RFC 8624 lists what signers and validators should use. ECDSAP256SHA256 (algorithm 13) and RSASHA256 (algorithm 8) are the two every signer must support. RSAMD5, DSA and ECC-GOST must not be used for signing, and RSASHA1 (algorithms 5 and 7) is not recommended. For DS digests, SHA-256 (digest type 2) is required and SHA-1 must not be used for new delegations. The checker names each algorithm from IANA's DNSSEC algorithm registry and flags the weak ones.

Why this matters for email

Not being signed has no effect on deliverability. Broken DNSSEC does. A mail server that validates DNSSEC can't look up the domain's MX, SPF or DKIM records, so mail to and from the domain can fail with no obvious reason in the message. If you send cold email from several domains, a broken DS on one of them can look like a mystery deliverability drop.

So when you audit sending domains, check DNSSEC alongside the rest: SPF, DKIM and DMARC, MX records and the cold email domain checker. See also setting up a domain for cold email.

Audit every domain you own

Run the full list: up to 500 a run when signed in, with a CSV after each. This is worth doing before a DNS host migration, to find domains with a DS record that will break when the nameservers change, and again afterwards. Domain investors can spot signed names so they remove the DS before moving them. See audit every domain your company owns.

What the checker can't see

• It asks one validating public resolver. It doesn't walk the chain itself or check each of the domain's name servers separately.
• It checks the registered domain, not delegated subdomains with their own DS records.
• It doesn't check signature expiry dates or NSEC/NSEC3 denial records.
• A resolver's cache can show the old state after a change.

Check your own domain

Enter it in the DNSSEC checker. If the domains are ones you email from or to, check the addresses on the verify page: the first 100 email checks are free with a Google sign-in, no card, and each address comes back valid, risky or invalid with a reason. See bulk email verification and pricing for bigger lists.