Most people only test their DNS when something is already broken: the site is down, email stopped arriving, or a change did not take. By then you are guessing under pressure. A better habit is knowing what a complete DNS test actually covers, so you can check a domain end to end and read the results with confidence. The catch is that most tools only test one slice. A propagation checker tells you nothing about your mail records, and a mail tester ignores whether your delegation is even correct. This walks through the five things a full DNS test should check, the tools that run each one, and how to tell a real problem from noise.
The five things a complete DNS test checks
Think of your DNS as five layers. A problem in any one of them can break your site or mail, and each is tested differently.
- Delegation. Is your domain correctly handed off from the top-level domain to your nameservers? This is the foundation, and if it is wrong, nothing below it matters. See how DNS delegation works for the parent-and-child nameserver check and lame delegation.
- Records. Do your A, AAAA, CNAME, and MX records resolve to the right places? A missing or wrong record here is the most common cause of a site or mail failure.
- Propagation. Is the current answer consistent everywhere, or are some resolvers still serving an old cached value? This is a timing question, governed by your TTL. Our guide to DNS propagation troubleshooting covers why answers differ by location.
- Mail authentication. Do your SPF, DKIM, DMARC, and reverse DNS records line up so your mail is trusted? Mail has its own stack of DNS records, and inbox placement depends on them. See MX, SPF, DKIM, and DMARC setup.
- Security. Are DNSSEC, CAA, and your TLS certificate in order? These protect the domain from tampering and mis-issued certificates. See how to enable DNSSEC.
A test that only covers one or two of these leaves the rest unchecked, which is exactly how a domain passes a propagation checker and still has broken mail.
The tools that run these checks
No single free tool covers all five layers well, so people usually combine a few. Here is what each kind is good for.
Command-line tools (dig and nslookup). These are the ground truth. dig queries a specific record type from a specific resolver and shows you the raw answer, including the TTL and the authority section. It is the most precise way to confirm exactly what a record says right now, and it is what most other tools call under the hood. The downside is that you have to know which query to run and how to read the output.
Online DNS checkers. Web tools like LeafDNS and similar checkers run a batch of queries for you and flag common configuration issues, especially around delegation and nameserver consistency. They are convenient because you paste a domain and get a report without memorizing dig syntax. The tradeoff is that different checkers cover different layers, so two tools can both say "looks fine" while each ignored the problem the other would have caught.
Propagation checkers. These query many resolvers around the world at once and show you whether a record has updated globally. They answer one question well, "has my change spread yet," and nothing else. Use one right after a change, then stop relying on it once the answer is consistent.
Mail and blocklist testers. These focus on the email layer, checking SPF, DKIM, DMARC, reverse DNS, and whether your sending IP or domain is on a blocklist. They are essential when the problem is deliverability rather than the website.
A graded health report. Rather than run five tools and stitch the results together yourself, a single report can check all five layers and grade them. Our Domain Health Report does exactly this: paste one domain and get an A-to-F grade across DNS, mail, DNSSEC, and TLS, with a shareable link. The guide on how to read a domain health report explains which failing grade to fix first.
How to read the results
A green check or an A grade means the record exists and is well-formed, not that it is doing what you intended. Always confirm the value matches your plan. When you do hit a failure, sort it into one of three buckets before you touch anything.
- A hard failure is a missing or clearly wrong record: no A record, a nameserver that does not respond, an SPF record that does not exist. Fix these first, because they break things outright.
- A soft or warning result is a record that works but is not ideal: an SPF record close to the 10-lookup limit, a very high TTL slowing your changes, missing DNSSEC. These are worth fixing but rarely the cause of an outage.
- A propagation lag is not a real error at all. If a record is correct at your authoritative nameserver but a checker still shows an old value elsewhere, you are just waiting on TTL. Confirm the source of truth with dig against your nameserver, then let time do the rest.
The mistake to avoid is treating a propagation lag like a broken record and changing the record again, which only resets the clock.
A practical testing order
Work top down, because a failure high in the stack makes everything below it look broken too.
- Confirm delegation first. If the parent is not pointing at your nameservers, stop and fix that.
- Check that your core records (A, AAAA, MX) resolve to the right targets at your authoritative nameserver.
- Check propagation only if you just made a change.
- Test the mail layer if email is involved.
- Confirm the security layer (DNSSEC, TLS) last.
Running the checks in this order keeps you from chasing a phantom mail problem that is really a delegation issue two layers up.
When to re-test
Test after every change that touches DNS: a nameserver move, a new mail provider, a hosting migration, or a certificate renewal. Test again a day later to confirm the change fully propagated and nothing else drifted. And if you manage more than one domain, a periodic health check catches the slow problems, like an expiring certificate or an SPF record that quietly grew past its limit, before they turn into an outage.
The fastest way to cover all five layers at once is a single graded pass. Run your domain through the Domain Health Report, read the grades top to bottom, and fix the hard failures first. It turns a pile of separate tools into one answer you can act on.