Article Summary: This article explains what a DNS health check is, how the DNS Report tool works, what each of its five check categories tests, and how to interpret Pass, Warning, and Error results. It also covers the most common DNS misconfigurations found in real-world domains and answers the most frequently asked questions about DNS auditing.
What Is a DNS Report?
A DNS report — sometimes called a DNS health check or DNS audit — is a comprehensive, automated analysis of a domain's DNS configuration. It queries multiple layers of the DNS hierarchy: the root zone, the parent (TLD) nameservers, and the domain's own authoritative nameservers. By comparing what each layer reports, the tool identifies mismatches, misconfigurations, and missing records that can silently break email delivery, website availability, or zone propagation.
DNS is a distributed system, meaning a domain's configuration is stored across multiple nameservers in multiple locations. A problem in any one layer can cause resolution failures that appear intermittent and are notoriously hard to diagnose without a structured audit. Tools like this one — and the now-defunct intodns.com — were created specifically to surface those hidden problems in seconds.
Unlike a simple DNS record lookup, a DNS report does not just return records — it evaluates them against RFC standards and operational best practices, then explains what is wrong and why it matters.
How It Works
The Five Check Categories
The DNS Report runs approximately 20 individual checks organized into five logical categories. Each check is assigned a status: Pass (green), Warning (amber), Error (red), or Info (blue). Errors indicate definite misconfigurations that require immediate attention. Warnings indicate sub-optimal settings that may cause problems under certain conditions. Info items are neutral observations with no action required.
DNS Delegation Chain
The report starts by tracing the DNS delegation chain from the root. For a domain like example.com, the tool first queries the root zone for the .com TLD nameservers, then asks those TLD nameservers for the NS records delegated to example.com. This mirrors exactly what a recursive resolver does when a user visits your domain for the first time. Any break in this chain prevents resolution from resolving correctly.
Parallel Nameserver Querying
After identifying all listed nameservers, the tool queries each one independently. This reveals split-brain DNS scenarios — where different nameservers return different answers — which are a leading cause of intermittent DNS failures that are invisible from a single-server query.
Common Use Cases
Post-Migration Verification
The most common reason to run a DNS audit is immediately after a domain migration. Whether you have moved to a new hosting provider, changed DNS providers, or transferred a domain between registrars, the DNS report confirms that delegation, glue records, and all record types are correctly set up before you cut over traffic.
Email Deliverability Troubleshooting
The MX record checks are invaluable for diagnosing email deliverability problems. A missing PTR record on an MX host, an MX record that points to a CNAME (which is invalid per RFC 2181), or an MX host with no A record are all conditions that will cause mail servers to reject or silently drop your outbound email. The DNS report surfaces all of these automatically.
Routine DNS Health Monitoring
DNS configurations can degrade over time — registrar auto-renewals sometimes reset glue records, TTL values get changed without notice, and secondary nameservers fall out of sync. Running a DNS health check periodically gives confidence that nothing has silently broken between deployments.
Competitive and Client DNS Auditing
Agencies and consultants use DNS reports to audit client domains before onboarding, identifying legacy misconfigurations, orphaned MX records, and dangling CNAME entries that represent both deliverability risks and potential security issues (subdomain takeover).
Technical Reference
| Category | Checks Performed | Why It Matters |
|---|---|---|
| Parent Zone Delegation | NS records in parent zone, glue records present, SOA visible from parent | Ensures the domain resolves correctly from any recursive resolver starting point |
| Nameserver Consistency | All NS servers respond, return identical NS sets, are authoritative for the zone | Inconsistent nameservers cause split-brain DNS and intermittent resolution failures |
| SOA Record | Serial format (YYYYMMDDNN), refresh/retry/expire/minimum TTL values, responsible email syntax | Misconfigured SOA breaks zone transfers, NOTIFY messages, and secondary sync |
| MX Records | MX hosts resolve to A records, have valid PTR records, correct priority order, no CNAME targets | Broken MX configuration directly causes inbound and outbound email delivery failure |
| WWW Resolution | A or CNAME record exists for www, HTTP connectivity responds | Ensures the website is reachable at the expected www subdomain |
Frequently Asked Questions
What is a DNS health check?
A DNS health check is an automated process that queries a domain's DNS configuration at multiple levels of the DNS hierarchy and evaluates the results against RFC standards and operational best practices. It identifies errors, warnings, and informational observations that affect domain resolution, email delivery, and zone management.
What do the Pass, Warning, and Error statuses mean?
Pass means the check completed successfully with no issues detected. Warning means the configuration is technically functional but deviates from best practices in a way that could cause problems — for example, a very low TTL or a non-standard SOA refresh interval. Error means a definite misconfiguration that is either causing a current problem or will cause one under predictable conditions — for example, a nameserver that does not respond or an MX record pointing to a non-existent host.
My SOA serial is wrong — what should it be?
The recommended SOA serial format is YYYYMMDDNN, where YYYY is the four-digit year, MM is the month, DD is the day, and NN is a two-digit revision counter (00–99) that increments each time you update the zone on the same day. For example, the third change on May 10, 2026 would be 2026051002. The serial must always increase monotonically — secondary nameservers use it to detect whether the zone has been updated and needs to be re-transferred.
Why does my domain fail the glue record check?
Glue records are A records for a domain's nameservers that are stored in the parent (TLD) zone rather than in the domain's own zone. They are required when a nameserver's hostname is within the same domain it is authoritative for — for example, if example.com uses ns1.example.com as a nameserver. Without glue records, resolvers have no way to reach the nameserver to ask where example.com is — a classic chicken-and-egg problem. Glue records are set at your domain registrar, not in your DNS zone file.
How often should I run a DNS report?
At minimum, run a DNS report after every DNS change — nameserver updates, record additions, TTL changes, or registrar transfers. For business-critical domains, running a weekly automated audit is a reasonable practice. DNS configurations can be modified by registrar systems, expire silently, or drift when managed by multiple team members.
Conclusion and Takeaways
A thorough DNS health check is one of the highest-value, lowest-effort diagnostic steps available to any domain owner, system administrator, or web professional. The five-category structure of this report — delegation, nameserver consistency, SOA validity, MX reachability, and WWW resolution — covers every layer of the DNS stack that can affect your domain's ability to serve traffic and deliver email reliably. Errors in DNS are often invisible until they cause a complete outage; a proactive audit catches them first. Use the DNS Report above to identify misconfigurations before your users or mail servers do.
Ready to Check?
Use the DNS Report above — no login required, instant results.