How to check DNS propagation properly

The single most common mistake in checking DNS propagation is reloading your own website in your own browser. That checks the one cache in the entire chain that is guaranteed to be among the last to update — your own machine's, sitting behind your own network's, sitting behind your own ISP's. A proper check queries somewhere that has not already formed an opinion.

Step one: query DNS directly, not through a browser

On macOS or Linux:

dig +short yourdomain.com

On Windows:

nslookup yourdomain.com

This still goes through your own resolver's cache, but it removes the browser and operating system caches sitting on top of it, which is often enough on its own to see a change that a page reload still is not showing.

Step two: query a specific nameserver directly

To bypass your own resolver's cache entirely, query one of the domain's authoritative nameservers directly rather than the resolver you normally use:

dig +short yourdomain.com @ns1.example-host.com

This tells you definitively what the domain's own nameservers are currently answering with, independent of anyone's cache. If this shows the new value but your normal lookup in step one does not, the change has been made correctly and is simply still spreading through caches — not a configuration problem.

Step three: check from outside your own network entirely

An online global DNS checker queries resolvers in a number of different countries simultaneously and shows you a map of who has picked up the new answer and who has not. This is the most useful single check available, because it answers the actual question you are usually asking — "has this gone live generally" — rather than "has this gone live for me specifically", which is a narrower and less useful question.

Step four: rule out your own cache last, not first

If every check above confirms the change is live everywhere else, and only your own machine still shows the old result, clear your local caches:

• Windows — ipconfig /flushdns in Command Prompt.
• macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Chrome — visit chrome://net-internals/#dns and clear the host cache.

Do this last, not first. Flushing your cache before confirming the change has actually spread elsewhere just means you will immediately re-cache whatever answer is currently live at that moment, which may still be the old one if you check too early.

Reading a global checker's results correctly

A handful of locations still showing the old answer while most show the new one is normal, expected behaviour during the spreading window, not a fault. It only becomes worth investigating if the split does not narrow over the following hours, or if it is still clearly divided after the length of time your record's TTL should allow for — see what a DNS TTL is for how that number sets your expectations, and how long DNS propagation takes for realistic overall timing.

Checking more than one record type

Propagation checks are not limited to the main website address. If you changed an MX record, a CNAME, or a TXT record, check that specific type rather than only ever checking the bare domain's A record — a change to email routing, for instance, will not show up in a plain dig yourdomain.com at all:

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short CNAME www.yourdomain.com

It is easy to conclude a change "has not propagated yet" when actually you were checking the wrong record type the whole time, and the one you actually changed updated correctly hours ago.

When checking properly still shows a real problem

If a specific nameserver query in step two does not show what you expect, that is not a propagation issue at all — it means the record genuinely was not changed the way you intended, or was changed in the wrong place. See how to check which DNS a domain is actually using to confirm you are editing where the domain's nameservers actually point.

If you have worked through all four steps and something still does not add up, contact our support team with the domain name and what each check showed, and we can look at it from our side.