How to Debug DNS Problems Step by Step

DNS problems are frustrating precisely because they masquerade as many different things -- a 404, an SSL error, bounced email, or a site that loads for some users but not others. The underlying cause is almost always a misconfigured or stale DNS record. Once you know what to look for, the pattern becomes recognizable quickly. This guide walks through a repeatable diagnostic process you can apply any time something feels DNS-shaped.

Photo by Suki Lee on Pexels

Step 1: Identify the Symptom Precisely

Before changing any records, describe the problem as specifically as you can:

• Is it a browser connectivity issue, an email delivery failure, or a certificate error?
• Does it affect all users or just some?
• Is it happening consistently, or intermittently depending on location?
• Did it start after a recent change -- a server migration, a new DNS host, updated records?

The answers narrow which record types to inspect first. Email problems point to MX, SPF, DKIM, and DMARC records in TXT. Browser connectivity issues point to A, AAAA, and CNAME chains. Certificate errors often implicate CAA records or an A record that resolves to the wrong server. By naming the symptom precisely, you skip a lot of aimless exploration.

Step 2: Query All Record Types at Once

Running queries one type at a time wastes time and misses interactions between record types. The failure you are seeing often has multiple contributing factors: a missing DMARC record is fine in isolation, but combined with a forwarding setup that breaks SPF alignment, it is why email is landing in spam. You need to see the full picture at once.

Use a tool that pulls A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA in a single pass. The DNS Lookup tool from EvvyTools does this with annotations on each record type, which saves the step of parsing raw dig output while you are trying to think through a problem.

If you prefer the terminal, this command gives all record types at once:

dig example.com ANY +noall +answer

Some resolvers no longer serve ANY responses for privacy reasons. If you get no answer or a truncated one, query each type explicitly:

for TYPE in A AAAA CNAME MX TXT NS SOA CAA; do
  echo "--- $TYPE ---"
  dig example.com $TYPE +short
done

Step 3: Check TTLs Before Assuming a Record Is Wrong

Every DNS response line includes a TTL column -- the number of seconds until that cached answer expires at a resolver. If you recently changed a record and something still looks wrong, check two things before assuming the new record is incorrect:

1. What was the TTL on the record before you made the change?
2. Has that much time actually passed since you made it?

A common mistake: you change an A record, then test from your own machine five minutes later and still see the old IP. If the old TTL was 86400 (24 hours), resolvers have been caching that old answer all day. Flushing your local cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) helps for local testing, but remote resolvers won't update until their cache entries expire at the full TTL.

This is why pre-reducing TTLs before planned migrations matters so much. The Cloudflare DNS Learning Center has a clear explanation of how resolver caching works at a protocol level if you want the full model.

Step 4: Compare NS Records at Two Levels

When a site moves to a new DNS host, NS record mismatches between the registrar and the zone are a common trap that makes everything else look broken even when the records are correctly configured.

Check:

1. What NS records does your registrar have configured for your domain?
2. What NS records does a dig example.com NS query return?

They should match. If the registrar still points to the old DNS host while your new records are configured at the new provider, no internet resolver can reach your zone. The A records you carefully configured at the new DNS host are invisible. This is the root cause of "all my records look right but nothing works" situations, and it is the first thing to rule out after any DNS provider migration.

Step 5: Trace the Full CNAME Chain

CNAMEs can chain -- app.example.com might point to app-staging.service.com which points to a final IP. A broken link anywhere in the chain makes the hostname unreachable, and the error will look identical to a missing A record.

Trace the full chain manually:

# Start with the domain
dig app.example.com CNAME +short
# If it returns another hostname, trace that too
dig app-staging.service.com CNAME +short
# Then confirm the final hostname has a valid A record
dig app-staging.service.com A +short

A common failure after migrating a hosted service (Heroku, Vercel, Netlify, Render) is leaving an old CNAME pointing to a deleted or renamed deployment. The CNAME resolves but the target endpoint no longer exists. The error shows up as a connection refused or a provider's default "app not found" page rather than a DNS failure -- which makes it harder to recognize as a DNS problem.

Step 6: Email-Specific Checks

Email delivery problems are the most opaque DNS failures because the messages either bounce with a cryptic SMTP code, land in spam with no explanation, or disappear entirely. Run these checks in sequence:

Confirm MX records exist and their hostnames have A records:

dig example.com MX +short
# Verify each listed mail server resolves
dig aspmx.l.google.com A +short

Check SPF:

dig example.com TXT +short | grep spf

An SPF record starting with v=spf1 should be present. Count the include: directives -- SPF allows a maximum of ten DNS lookups in the evaluation chain, and many providers nest their own includes. Exceeding ten lookups causes a permerror, which some mail servers treat as an outright failure. The SPF specification is in RFC 7208.

Check DMARC:

dig _dmarc.example.com TXT +short

A record starting with v=DMARC1; confirms a policy exists. No record means spoofed emails pass through regardless of SPF and DKIM results. DMARC is defined in RFC 7489.

Check DKIM at the correct subdomain:

# Replace "mail" with the selector your provider specified
dig mail._domainkey.example.com TXT +short

DKIM keys live at <selector>._domainkey.example.com. The selector is specific to each sending service. An empty p= field means the key was revoked. DKIM is specified in RFC 6376.

Photo by kerttu on Pixabay

Step 7: Cross-Check From an External Perspective

Your local ISP's resolver may be caching an old answer. What you see from your own machine is not necessarily what users in other regions see. Test from public resolvers that have no cached history of your domain:

# Cloudflare
dig @1.1.1.1 example.com A +short

# Google
dig @8.8.8.8 example.com A +short

If results differ between resolvers, one is still serving a cached old record. If both match but are wrong, the problem is in your zone configuration, not propagation.

Step 8: Check CAA Records for Certificate Issues

If the problem is an SSL certificate renewal failure, CAA records are often the culprit. CAA records restrict which certificate authorities are allowed to issue for your domain.

dig example.com CAA +short

If a CAA record exists and it does not include your certificate provider's domain, renewals will fail. If there is no CAA record, any CA can issue -- less of a restriction, but also less protection. Check that the CA your certificate service uses is listed, or that no CAA record exists if you do not want to restrict issuance.

A Repeatable Diagnostic Checklist

For any DNS incident, work through this in order:

• [ ] What is the exact symptom? Connectivity, email, or certificate?
• [ ] Did it start after a recent change to DNS, hosting, or infrastructure?
• [ ] Pull all record types at once -- look for anything missing or unexpected.
• [ ] Check TTLs -- could this be a stale cache from before a recent change?
• [ ] Verify NS records match between the registrar and a live query.
• [ ] For CNAME chains: trace to the final resolved IP.
• [ ] For email: SPF present and under ten hops? DKIM key at the right subdomain? DMARC policy at _dmarc.example.com?
• [ ] Test from a public resolver (1.1.1.1, 8.8.8.8) to see what the wider internet sees.
• [ ] For certificate issues: check CAA records include the correct CA.

Methodical checking beats guessing at individual records. Most DNS problems reveal themselves within the first three steps; the remaining steps cover the less obvious cases.

For background on what each DNS record type does and how to read the raw values, the EvvyTools blog has a complete reference: DNS Records Explained: A Practical Guide to Reading and Debugging Your Domain's DNS.