A full delegation & DNS report card
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 ASNsA DNS health check inspects how a domain is delegated and configured end to end, not just one record type. It asks the parent (TLD) servers what they publish for your domain, then asks your own nameservers directly, and compares the two. Mismatches between the parent and your servers — missing glue, disagreeing NS lists, out-of-sync SOA serials, lame or open-recursion nameservers — are exactly the problems that cause slow, intermittent or silently broken DNS. IPeek runs every check and tells you, in plain English, why each one matters and how to fix it.
Every lookup for your domain starts at the parent zone — the TLD registry (for example .es or .com) — which holds the NS records that point resolvers to your nameservers. If those nameservers live inside your own domain, the parent must also publish their IP addresses as "glue", otherwise resolvers face a chicken-and-egg loop. A healthy delegation has the parent and your own servers agreeing on the same NS set, with glue present where needed. When they disagree, some resolvers follow stale information and your changes appear to work for some users but not others.
RFC 2182 recommends multiple nameservers on different networks so a single outage never takes your domain offline. Each one must answer authoritatively for your zone — a "lame" server that does not is a silent reliability hole. Your authoritative servers should also refuse recursion for strangers: an open recursive nameserver can be abused for cache poisoning and DDoS amplification. IPeek queries each of your nameservers directly to confirm they respond, answer authoritatively, agree with each other, support TCP, and keep recursion closed.
The SOA record carries your zone's serial number and timing values; every nameserver must report the same serial, or your zone is out of sync and changes propagate unevenly. The serial should follow the YYYYMMDDnn convention, and the refresh/retry/expire/minimum timers should sit in the RFC-recommended ranges. On the mail side, MX records must be hostnames (never bare IPs or CNAMEs) that resolve to public addresses. Finally, the apex (your bare domain) should publish an address but not a CNAME, which RFC 1912 forbids alongside other records.
A DNS lookup shows you the records as seen through a recursive resolver. A health check goes further: it queries the parent TLD servers and each of your own nameservers directly, then compares them. That lets it catch delegation problems a plain lookup hides — missing glue, parent/child NS mismatches, lame or disagreeing nameservers, and out-of-sync SOA serials.
Glue is the IP address of a nameserver, published by the parent zone alongside the NS record. It is required when your nameservers are inside the same domain they serve (for example ns1.example.com serving example.com), because resolvers would otherwise need to resolve the nameserver before they can resolve anything. Missing glue in that case breaks resolution; if your nameservers are on a different domain, glue is optional and only saves one extra lookup.
Authoritative nameservers should answer only for the zones they host. A nameserver that performs recursion for anyone (an "open resolver") can be abused for DNS amplification DDoS attacks and is more exposed to cache poisoning. If the health check flags open recursion, disable recursion on the authoritative server or separate your authoritative and recursive roles onto different hosts.
The SOA serial is a version number for your zone. When your nameservers report different serials, at least one is serving stale data — usually a secondary that failed to transfer the latest zone from the primary. The result is inconsistent answers depending on which server a resolver happens to hit. Check zone transfers (AXFR/IXFR), the primary's notify settings, and the SOA refresh timer.
Neither is an error, but both are single points of failure. With one MX, mail can be lost if that server is down long enough; a backup MX adds resilience. Two nameservers is acceptable per RFC 2182, but three or more on different networks is safer. The health check flags these as warnings, not failures — they are worth improving, not emergencies.