How to Run a DNS Health Check on Your Domain

A DNS health check is the diagnostic pass you run on a domain to make sure every record that controls how the world reaches it is configured the way you expect. Nameservers point where they should, A and AAAA records resolve to the right hosts, mail flows through the right MX servers, and your SPF / DKIM / DMARC records line up so legitimate email isn't silently quarantined. The goal is to catch misconfigurations on your terms, not when a customer messages you saying the site is down or their welcome email never arrived.

This is the guide I wish I'd had the first time I launched a domain and watched email mysteriously bounce for three days because a single SPF record had two include: directives that pushed the lookup count over the RFC 7208 limit of 10. The checks themselves are mechanical. The hard part is knowing what to look for and what "healthy" actually means.

Why a DNS health check matters

DNS failures are quiet. Unlike a 500 from your application, a misconfigured DNS record doesn't show up in any error tracker you control. The problem usually lives somewhere in this list:

• Silent resolution failures. Your registrar still lists nameservers that don't match the ones your DNS provider expects. Lookups partially work (the registrar cached them once), then start failing as caches expire. Customers in some regions can't reach you; others can.
• Email deliverability damage. SPF or DMARC alignment is off, and inbox providers start sending your transactional mail to spam or rejecting it outright. By the time you notice (a customer complains), you've already lost a few hundred sends to the junk folder.
• Subdomain takeover exposure. A CNAME points to a SaaS host you stopped paying for. Someone else now controls a subdomain on your root, indexed by Google, trusted by your users.
• Slow first-byte for new visitors. Authoritative nameservers in only one geographic region, no anycast. Users on other continents pay the latency tax on every cold lookup.
• Certificate issuance surprises. No CAA record, so any CA on earth can mint a certificate for your domain. Or a CAA record exists but points to a CA you stopped using, and Let's Encrypt renewals start failing.

A health check catches every one of these before the customer-visible failure. It takes about thirty seconds.

What a DNS health check covers

A complete check runs through every record type that matters, plus a few sanity checks on the records that should and should not exist. Here is the working list:

The manual way: dig command by command

dig is the canonical tool for running these checks one at a time. Here is every line you would need to type to cover the checklist above for a single domain, plus what to look for in each output.

Authoritative nameservers (NS)

dig +short NS :domain

Returns the NS records. Cross-check against the nameserver list shown at your registrar. They must match exactly. Anything less than two records is a single-point-of-failure setup.

Parent delegation (whose NS does the TLD point at?)

dig +trace :domain | grep -E "NS|;;"

Walks from the root down to your zone. The NS records returned by the TLD (the parent) should match what your zone advertises. Mismatches mean stale glue at the registrar.

A and AAAA records (IPv4 and IPv6)

dig +short A :domain
dig +short AAAA :domain

Verify the IPs match your current web host. Missing AAAA on a dual-stack network is a missed-opportunity signal, not a hard failure.

Mail exchangers (MX)

dig +short MX :domain

Output format is priority host.. Lower priority is preferred. Verify the MX target itself is not a CNAME (RFC 5321 explicitly forbids this and many mail servers reject the host).

SPF (TXT record at the apex)

dig +short TXT :domain | grep "v=spf1"

Expect exactly one record beginning with v=spf1. More than one and SPF evaluation fails outright. Then count DNS lookups manually: every include:, a, mx, exists, and redirect mechanism counts toward the RFC 7208 limit of 10. Exceed 10 and receivers must return permerror, which most treat as a hard fail.

DKIM (per selector)

dig +short TXT :selector._domainkey.:domain

You have to know the selector name. Every mail provider uses a different one — Google Workspace uses google, Mailchimp uses k1, SendGrid uses s1 and s2. Type your selector into the DKIM selector box above and the command updates. A selector that does not resolve means messages signed with that selector are silently failing DKIM validation at the receiver.

DMARC

dig +short TXT _dmarc.:domain

One record, starting with v=DMARC1. Check the policy (p=none / quarantine / reject), the reporting URI (rua=mailto:...), and the alignment modes (aspf, adkim).

CAA

dig +short CAA :domain

Output format: flag tag "value". An empty result means any public CA on the Mozilla / Apple / Microsoft trust lists can issue a certificate for your domain.

DNSSEC chain of trust

dig +short DS :domain
dig +dnssec SOA :domain | grep RRSIG

DS record at the parent plus signed responses from your zone equals a working chain of trust. DS present but no RRSIG, or RRSIG present but no DS, equals a broken chain.

Reverse DNS (PTR) for sending IPs

dig +short -x :mail_ip

The PTR should resolve to a hostname that matches the EHLO on outbound SMTP. Generic ISP hostnames hurt deliverability scores at the major inbox providers.

That is at least nine commands, more if you have multiple DKIM selectors or subdomains worth checking. Each output requires interpretation: you have to know what "healthy" looks like for every record type, count SPF lookups by hand, verify NS-to-registrar alignment, and remember to run the trace separately because no single dig invocation surfaces parent delegation issues.

There is a faster path.

Running every check in one pass

The DNS Inspector is a free browser-based diagnostic that walks the DNS tree from the root, runs 25+ automated tests against the authoritative nameservers, and returns a single scored health report with plain-language fix recommendations. One URL, no CLI flags, no jq pipelines.

What the DNS Inspector actually checks in a single pass:

• Parent delegation: does the TLD correctly hand off to your NS, and do the glue records line up?
• NS configuration: consistent across all authoritative servers, sensible TTLs, at least two nameservers
• A and AAAA records: IPv4 and IPv6 resolution from every authoritative server
• MX records: including the CNAME-at-MX-target detection that dig MX does not surface
• SPF: record presence, syntax, and the 10-lookup limit counted automatically
• DKIM: selector resolution for the providers you have configured
• DMARC: policy presence, alignment mode, reporting URI
• CAA: certificate authority restriction with parent-zone inheritance
• DNSSEC: full chain of trust from parent DS through your zone's RRSIG signatures
• SOA: serial number freshness, refresh interval sanity
• PTR / reverse DNS: matches for IPs that look like outbound mail senders
• Performance: first-byte time measured from multiple regions

Output is a percentage score, a categorical breakdown (passed, warning, critical), and per-test recommendations written in English you can act on without grepping an RFC. Every result is shareable via a URL of the form dnschkr.com/dns-inspector/{your-domain}, useful when you need to hand the diagnosis to whoever owns the registrar or DNS provider config.

Manual dig vs. DNS Inspector at a glance

When I am debugging in anger, I still reach for dig to verify a single record. For the full sweep, the DNS health checker saves an order of magnitude in time and catches the cross-record issues (SPF lookup count, NS-registrar alignment, CNAME-at-MX-target) that dig will not flag on its own.

A real example: reading the output

Here's what a healthy domain looks like. I ran the check on techearl.com (this blog) and pulled the score panel from the live example.

A few things to read out of this kind of result:

• The headline score. 97% on a domain with email and HTTPS configured is the realistic target. 100% is rare in practice because there are always optional hardening steps a small site won't do (CAA with multiple CA fallbacks, DNSSEC in environments where the registrar charges extra for it).
• Critical issues vs. recommendations. Critical issues are things that will break or are actively wrong. Recommendations are upgrades you can ignore without consequence (until you can't). In the screenshot above, the only flag is a DMARC TXT record fine-tuning, nothing critical.
• Per-test breakdown below the score. This is where the actual answers live. Each test (NS Delegation, A Records, MX Records, SPF, DKIM, DMARC, CAA, DNSSEC, and so on) expands to show what was returned, what the tool checked, and whether it passed.

The thing that took me longest to internalize: a Passed next to "SPF Record" doesn't mean your email will arrive in someone's inbox. It means the record exists and is syntactically valid. Deliverability is a function of SPF + DKIM + DMARC alignment plus sender reputation, and only the DNS-side of that lives in records you can validate.

Common issues and how to fix them

After running a DNS health checker across a few dozen domains, the same handful of problems show up:

Mismatched NS records at the registrar

You moved DNS providers but forgot to update the nameserver list at the registrar. The new provider has the correct zone, but the registrar still tells the parent TLD to send queries to the old NS. Symptom: random resolution failures depending on which resolver cached what. Fix: update NS at the registrar, wait for the TLD's TTL (usually 24-48 hours).

SPF over the 10-lookup limit

Every include: and a and mx mechanism in SPF counts toward a hard limit of 10 DNS lookups per RFC 7208. Exceed it and receivers MUST treat the result as permerror, which most treat as a hard fail. The biggest offenders are SaaS sender stacks that themselves have include: chains. Fix: flatten your SPF, or use a service that resolves the includes into static IPs nightly.

CNAME at the apex

DNS doesn't permit a CNAME at the zone apex (example.com), only on subdomains (www.example.com). Some providers expose "ALIAS" or "CNAME flattening" features that look like apex CNAMEs but actually resolve to A records under the hood. If you're seeing intermittent resolution failures on the bare domain, you may have a real CNAME at the apex that some resolvers tolerate and others reject.

Stale wildcard records

A wildcard * A record that pointed to a defunct host five years ago. Every subdomain that doesn't have its own record resolves to that dead IP. Fix: delete the wildcard, or repoint it. Audit anything that uses wildcard subdomains before you assume nothing is hitting them.

Missing DMARC

Without a DMARC record, your domain can be spoofed at scale and you never find out. The minimum-viable DMARC is v=DMARC1; p=none; rua=mailto:you@example.com, which forwards aggregated reports to you so you can see who's sending mail as you before tightening to p=quarantine or p=reject.

When to re-run the check

The triggers I run a DNS health check on, in roughly decreasing order of importance:

1. Right after registering a new domain. Before you put anything live on it. Catches typos in nameserver setup.
2. After any DNS record change. Yours or your provider's. Don't trust the change happened the way you think it did. The tool tells you what the resolvers actually see.
3. After migrating email providers. SPF, DKIM, and MX all move at once and any one of them being off kills deliverability.
4. After transferring a domain between registrars. Glue records, DNSSEC DS records, and parent NS delegation can all break during transfer.
5. Before a launch or marketing send. Five seconds of check before pressing send on a campaign saves you from sending five thousand emails into spam folders.
6. On a quarterly cadence for anything you care about. Records drift. Providers change defaults. Records you set up two years ago may no longer match the current best practice (DKIM key lengths have moved on, for example).

I keep a one-line shell alias that opens the DNS record checker in my default browser for a given domain. Total friction: zero.

A pre-launch DNS checklist

If you're configuring a new domain from scratch, the order I do it in:

• Buy the domain. Confirm the registrar shows it active.
• Point NS records at your DNS provider. Wait for the parent TLD to pick this up (check WHOIS or use the DNS Inspector at dnschkr.com to confirm delegation).
• Add the A / AAAA records for your web host. Verify resolution from multiple geographic locations.
• Set up MX records for your email provider (Google Workspace, Fastmail, ProtonMail, your own server).
• Publish SPF as a TXT record at the apex. Include every sender that needs to mail as the domain.
• Generate a DKIM keypair through your mail provider. Publish the public key at the right selector subdomain.
• Add DMARC with p=none initially. Set rua= to an inbox you'll actually monitor.
• Add CAA records pointing to the CA(s) you intend to use (letsencrypt.org, or your commercial CA's recommended issuer string).
• Enable DNSSEC at the DNS provider and the registrar. Verify the chain of trust completes.
• Run a final DNS health check. Confirm every test passes (or you've consciously decided not to fix it).

Then and only then put the domain in any production-facing place. Adding a record is one minute. Debugging a misconfigured record after it's caused a customer-visible problem is hours.