How to verify if your domain has DNSSEC
Why verify DNSSEC
Enabling DNSSEC is the first step. The second — equally important — is verifying that the entire chain of trust actually works. DNSSEC can break silently: a signature expires, the registrar removes the DS record during a domain transfer, or keys fall out of sync after a DNS update.
Broken DNSSEC is worse than no DNSSEC at all. Validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, and others) refuse to answer queries with invalid signatures — your domain becomes unreachable for all users of those resolvers. Emails stop being delivered, your website goes down.
Regular DNSSEC verification helps you catch problems before your customers do.
Quick check with an online tool
The fastest way to verify your domain's DNSSEC is the domain analyzer — the results include DNSSEC status alongside SPF, DKIM, and DMARC checks.
The analyzer verifies:
- DS record existence in the parent zone (at the registrar)
- DNSKEY record existence on the domain's authoritative server
- Signature validity (RRSIG) on key records
- Chain of trust consistency from the root zone to your domain
For a deeper look at specific DNS records, use our DNS lookup.
Verification in the terminal with dig
For more detailed diagnostics, use the dig command. The following steps show how to manually walk through the entire chain of trust.
Checking the DS record
The DS (Delegation Signer) record links your domain to the parent zone. Without it, the chain of trust is broken even if your zone is signed.
dig example.com DS +short
Expected output (example):
2371 13 2 a5f2c8e7b3d9f1a0...
The numbers represent: key tag, algorithm, digest type, and the digest itself. If the command returns nothing, the DS record is missing at the registrar — DNSSEC is not active at the parent zone level.
Checking the DNSKEY record
DNSKEY is the public key for your zone, used by resolvers to verify signatures.
dig example.com DNSKEY +short
The output contains one or more keys. The number at the beginning (256 or 257) identifies the key type:
- 257 = KSK (Key Signing Key) — signs the DNSKEY RRset, its hash appears in the DS record
- 256 = ZSK (Zone Signing Key) — signs all other records in the zone
An empty response means the zone is not signed.
Verifying signatures (RRSIG)
The +dnssec flag in dig returns RRSIG signatures along with the answer:
dig example.com A +dnssec
Look for two things in the output:
- The
adflag (Authentic Data) in the response header — the resolver confirmed signature validity - An RRSIG section below the answer — contains the signature, algorithm, validity period, and key tag
If the flags include ad, your resolver validated DNSSEC and the response is authentic.
Full validation with delv
The delv utility performs full cryptographic validation of the chain of trust:
delv example.com A
Unlike dig, delv doesn't just report flags — it actually verifies signatures against keys. The output clearly states fully validated or unsigned answer.
Interpreting the results
| Result | Meaning | Action |
|---|---|---|
DS and DNSKEY both exist, delv reports fully validated |
DNSSEC is working correctly | None — monitor regularly |
| DS exists but DNSKEY is missing | Parent zone references a non-existent key | Sign the zone or remove the DS record at the registrar |
| DNSKEY exists but DS is missing | Zone is signed but the chain of trust is broken | Add the DS record at the registrar |
delv reports a validation error |
Signatures don't match, keys are inconsistent | Check algorithms and signature expiration |
| Neither exists | DNSSEC is not active | Enable it with your DNS provider and registrar |
When DNSSEC breaks
DNSSEC typically fails in three scenarios:
Domain transfer to a different registrar
When transferring a domain between registrars, the DS record may be lost. The behavior depends on the registry — some preserve DS records during transfers, others don't. If the gaining registrar doesn't carry over the DS record, DNSSEC stops working.
Solution: After the transfer completes, verify the DS record and re-add it manually if needed.
DNS server migration
When you change authoritative DNS servers (e.g., migrating to Cloudflare), the new servers must re-sign the zone and generate a new DS record. The old DS references a key that doesn't exist on the new servers.
Solution: Before migration, deactivate DNSSEC at the old provider, complete the migration, then re-enable DNSSEC at the new provider.
Signature expiration (RRSIG)
RRSIG signatures have a limited validity period (typically 1–5 weeks; BIND defaults to 30 days). DNS software must re-sign them periodically. If automatic re-signing stops (script failure, full disk, server restart), signatures expire and the domain becomes unreachable.
Solution: Monitor signature expiration. If you run your own DNS server, check logs and re-signing automation.
Impact of broken DNSSEC on email
Broken DNSSEC doesn't just affect your website. Validating resolvers will also refuse MX records, SPF and DKIM records for your domain. The consequences:
- Emails won't be delivered — sending servers can't resolve your domain's MX records
- Authentication fails — recipients can't retrieve SPF/DKIM records and treat it as a failure
- DMARC reports are lost — reporting servers can't resolve the target address
This is a complete email communication outage, not just reduced deliverability.
Automated monitoring
Manual dig checks are useful for diagnostics but insufficient for ongoing oversight. DNSSEC can break at any time — after a DNS update, a domain transfer, or simply because a signature expired.
SPF Monitor checks your domain's DNSSEC status automatically and alerts you as soon as a problem appears in the chain of trust — before your users notice.
