Is the domain signed and validated?
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsDNSSEC (DNS Security Extensions) cryptographically signs DNS records so resolvers can verify they have not been tampered with, defending against cache poisoning and spoofing. It adds a chain of trust on top of ordinary DNS without changing what records mean. IPeek queries a validating DNS-over-HTTPS resolver and reports whether the domain is signed and authenticated.
DNSSEC works by signing each zone with a private key and publishing the matching public key in the DNS. Records are signed (RRSIG), keys are published (DNSKEY), and a fingerprint of the zone's key (the DS record) is placed in the parent zone. This links your zone to its parent, which links to its parent, all the way up to the root — a continuous chain of trust. A validating resolver follows that chain from the root down, checking each signature, and only trusts answers whose signatures verify.
IPeek reports whether the domain is DNSSEC-signed and whether a validating resolver authenticates it. An authenticated result (often shown as the AD, or Authenticated Data, flag) means the chain of trust is intact and the records are verified. If the domain is unsigned, DNSSEC is simply not enabled — common and not an error, but it means the records are not protected. A signed domain that fails validation is more serious: it points to a broken chain, usually a missing or mismatched DS record at the registrar.
The most common failure is a broken chain of trust, where the zone is signed but the DS record in the parent is missing, stale or does not match the current key. This makes validating resolvers return SERVFAIL and can take the domain completely offline for users behind validating resolvers. It usually happens during key rollovers or when enabling DNSSEC without uploading the DS record to the registrar. Fix it by ensuring the DS record at the registrar matches your zone's active key, and never remove old keys before the DS update has propagated.
A DNSSEC-signed domain has cryptographic signatures on its DNS records, letting validating resolvers confirm the answers are genuine and unmodified. Signing alone is not enough, though: the parent zone must also hold a matching DS record so the chain of trust reaches the domain. A signed and properly delegated domain is protected against spoofing and cache poisoning.
No, an unsigned domain is not an error — many domains do not use DNSSEC. It simply means the records carry no cryptographic protection and could in theory be spoofed or poisoned in transit. Enabling DNSSEC adds that protection, but it is optional and requires correct setup at both your DNS provider and registrar.
A DS (Delegation Signer) record is a fingerprint of your zone's signing key, published in the parent zone at the registrar. It links your signed zone to the chain of trust above it. If the DS record is missing or does not match your current key, validating resolvers cannot verify the domain and may fail it entirely, so keeping the DS in sync is critical.
AD stands for Authenticated Data. When a validating resolver sets the AD flag, it confirms that the answer's DNSSEC signatures were checked and the chain of trust verified successfully. Its absence on a signed domain can indicate a validation failure or that the resolver did not validate. IPeek uses a validating resolver so the flag reflects genuine authentication.
The usual cause is a broken chain of trust: the DS record at the registrar is missing, outdated or does not match the zone's active key, often after a key rollover. Validating resolvers then return SERVFAIL, which can make the domain unreachable for affected users. Aligning the registrar's DS record with the current signing key fixes it.