Four ways to ask "is my DNS actually okay"
These tools all answer some version of "is this domain healthy," but at different scopes: propagation checks a single change across the world, the health check audits everything at once, DNSSEC checks a specific security layer, and blacklist checks look outward at reputation rather than configuration.
📖 For a deeper walkthrough on propagation specifically, see the guide: DNS Propagation Doesn't Exist
DNS Propagation — has my change reached everyone yet
DNS Propagation queries the same record from multiple resolvers in different regions simultaneously, showing whether a recent change has reached all of them yet.
When to use it: right after changing nameservers, an A record, or MX records; when some visitors see the new site and others still see the old one; or setting expectations with a client about how long a change will take.
Reading results: differences between resolvers are normal for a short window after a change — that's TTL expiry working as designed, not a bug. If results are still split after several multiples of the old TTL, something upstream is genuinely wrong, not just slow.
NODA Check — the full audit
NODA Check runs 30+ checks across a domain's NS delegation, SOA record, MX setup, mail authentication (SPF, DKIM, DMARC), DNSSEC, and known blacklists — all in one pass.
When to use it: before launching a new domain or migrating providers, when email is landing in spam and you suspect a misconfigured mail-auth record, or as a periodic audit to catch lame nameservers or expired DNSSEC keys before they cause an outage.
Reading results: each section gets a pass/warn/fail badge. A fail in SOA or NS delegation is worth fixing immediately since those affect every other record downstream. Mail-auth warnings are common on brand-new domains and usually just mean a record hasn't propagated yet — re-check after the TTL window passes.
DNSSEC Check — is the chain of trust intact
DNSSEC Check walks the DNSSEC chain of trust from the root down to your domain, verifying that DS records, DNSKEY records, and signatures all match up correctly.
When to use it: after enabling DNSSEC with your registrar or provider, debugging why a domain suddenly stopped resolving for some users (a broken DNSSEC chain is a frequent, non-obvious cause), or before a planned key rollover to confirm the current chain is healthy first.
Reading results: a broken chain shows exactly where it breaks — usually a DS record at the registrar that no longer matches the DNSKEY at the DNS provider. That specific mismatch is the single most common DNSSEC failure, and it's worth checking first before looking anywhere else.
Blacklist Check — how the internet sees your IP
Blacklist Check queries an IP against dozens of DNS-based blacklists (RBLs) used by mail servers worldwide to filter spam and abuse.
When to use it: outbound mail is bouncing or landing in spam, you're putting a new server into production and want a clean-slate check, or you're investigating whether a shared hosting IP got blacklisted by a noisy neighbor before you arrived.
Reading results: a listing on a major RBL (Spamhaus, SORBS, Barracuda) is significant and worth acting on immediately; a listing on an obscure or unmaintained list often isn't. Every blacklist has its own delisting process — follow the specific link the listing gives you rather than assuming a universal procedure exists.
How these fit together
Run the full NODA Check first — it surfaces DNSSEC and blacklist problems as part of the same pass, so you rarely need to run all four separately. Reach for DNS Propagation specifically after making a change, and re-run DNSSEC Check on its own before and after a planned key rollover, since that's a narrow window where a mistake is easy to make and easy to miss.