You just updated a DNS record — maybe you pointed your domain to a new host, changed an A record, or swapped out your nameservers entirely. Now you're staring at a browser that still loads the old site, wondering whether your change worked at all or whether the internet is just being slow. DNS propagation is the process by which your changes spread across resolvers worldwide, and it can take anywhere from a few minutes to 48 hours depending on several factors. Knowing how to check that propagation in real time, from multiple vantage points, is the difference between waiting blindly and knowing exactly where you stand.
What DNS Propagation Actually Means
When you change a DNS record, that change is written immediately to your authoritative nameserver — the server your domain registrar or DNS host controls. The problem is that the rest of the internet does not query your authoritative nameserver directly for every request. Instead, billions of devices rely on recursive resolvers — run by ISPs, Google (8.8.8.8), Cloudflare (1.1.1.1), and others — that cache DNS answers to reduce load and latency.
Those cached answers have a lifespan defined by the TTL (Time to Live) value on each record. If your A record had a TTL of 86400 seconds (24 hours) before you changed it, every resolver that cached it will keep serving the old answer for up to 24 hours, regardless of what your authoritative nameserver now says. That staggered expiry across thousands of resolvers around the world is what people call propagation. It is not a single wave — it is a rolling refresh that happens at different times in different locations.
Why Propagation Feels Inconsistent
Two people in the same building can get different DNS answers after a change. One person's device might be using a resolver that already expired its cache and fetched the new record. The other might be hitting a resolver that cached the old value an hour ago and still has 23 hours left on the TTL. Corporate networks often run their own internal DNS caches, which adds another layer. Mobile devices frequently switch between carrier resolvers and Wi-Fi resolvers, sometimes mid-session.
This inconsistency is normal and expected. It does not mean your change is broken. It means the internet's distributed caching system is doing exactly what it was designed to do.
Step 1: Verify the Change on Your Authoritative Nameserver First
Before checking propagation globally, confirm that your authoritative nameserver is actually serving the new record. If this check fails, propagation is irrelevant — the source of truth is wrong.
Find your authoritative nameserver with this command:
This returns something like ns1.dnsprovider.com and ns2.dnsprovider.com. Now query that nameserver directly for the record you changed:
Replace A with the record type you changed — MX, CNAME, TXT, etc. If the authoritative nameserver returns the new value, your change is correct and propagation is underway. If it still returns the old value, go back to your DNS control panel — the change may not have saved properly.
On Windows, use nslookup instead:
Step 2: Check Propagation Across Global Resolvers
Once you know the authoritative nameserver is correct, the real question is how far the new answer has spread. This is where a dedicated propagation checker becomes essential.
The tool queries real resolvers distributed across North America, Europe, Asia-Pacific, and other regions. A result showing green (new value) in most locations with a few red (old value) stragglers is perfectly normal within the first few hours of a change. Full green across the board means propagation is complete.
Step 3: Check From Your Own Machine
Knowing the global state is useful, but you also need to know what you are seeing locally, because your experience is what matters for testing your own site. Run these commands depending on your OS.
On macOS or Linux:
On Windows (Command Prompt or PowerShell):
Compare the IP address in the output against the new IP you configured. If it still shows the old IP, your local resolver has a cached copy. You have a few options to force a refresh.
Flush Your Local DNS Cache
On Windows:
On macOS Ventura / Sonoma:
On Linux (systemd-resolved):
After flushing, run the dig or nslookup command again. If you now get the new IP, your machine was simply caching the old answer. If it still returns the old IP, the resolver your machine is pointed to (your ISP's resolver or a public one) still has the old cache — flushing your local cache won't help until that upstream resolver expires its entry.
Test Against a Specific Public Resolver
You can bypass your ISP resolver entirely by querying a public one:
If Google's resolver (8.8.8.8) and Cloudflare's resolver (1.1.1.1) both return the new IP but your machine's default resolver still returns the old one, switch your device's DNS temporarily to 1.1.1.1 or 8.8.8.8 in your network settings. You will immediately start seeing the new record while your ISP's resolver catches up.
Step 4: Check Specific Record Types
Not all DNS changes are A record changes. Here is how to check propagation for common record types using the DNS Lookup tool or the command line.
MX records (for email routing):
CNAME records (for subdomain aliases like www):
TXT records (for SPF, DKIM, domain verification):
NS records (when you move to a new DNS provider):
Nameserver changes take the longest to propagate because the old NS records are cached at the TLD level (.com, .net, etc.) and those TTLs are often set to 172800 seconds (48 hours) by the registry. This is why moving DNS providers can take up to two days to fully propagate, even when everything is configured correctly.
How to Read the TTL in a DNS Response
The TTL value in a DNS response tells you exactly how long a resolver will cache that record before checking again. Run this command to see the TTL:
Look for a line in the ANSWER SECTION like:
The number 3600 is the TTL in seconds — one hour. A resolver that just cached this record won't query your authoritative server again for 3600 seconds. If you are checking propagation and a resolver returns a TTL of 2400 for what should be a 3600-second record, that resolver cached it 1200 seconds ago and will refresh in another 2400 seconds. This is called the remaining TTL and it gives you a concrete time estimate for when that resolver will pick up your change.
How to Speed Up Propagation Before Making a Change
If you know a DNS change is coming — a site migration, a hosting move, an email provider switch — you can dramatically reduce propagation time by lowering your TTL in advance. Log into your DNS control panel and drop the TTL on the affected records to 300 seconds (5 minutes) or even 60 seconds 24 to 48 hours before you make the actual change. Once all resolvers have refreshed with the low TTL value, any future change will propagate in minutes rather than hours.
After the change is confirmed complete and stable, raise the TTL back to 3600 or higher to reduce DNS query load and improve resolution performance for your visitors.
Verifying Propagation Is Complete
Propagation is complete when every resolver you care about returns the new record value. In practice, you should check:
- Your local machine after flushing its cache
- Google's resolver (8.8.8.8)
- Cloudflare's resolver (1.1.1.1)
- The propagation checker tool above, which shows a global spread
- Any staging or testing environment you use
For most record changes with reasonable TTLs, propagation is 80 to 90 percent complete within an hour and fully complete within 24 hours. If you are still seeing widespread old values after 48 hours, something is wrong — either the change was not saved correctly on the authoritative nameserver, or there is a secondary DNS provider involved that you forgot to update.
Common Propagation Problems and What They Mean
The propagation checker shows the new value everywhere but you still see the old site. This usually means your browser has cached the old page or the old HTTPS certificate. Clear your browser cache and try an incognito window. Also check if your web server or CDN (Cloudflare, Fastly, etc.) has its own cache layer that needs purging.
Some regions show the new value but others are stuck for more than 24 hours. Certain ISPs in specific countries run poorly maintained resolvers that ignore TTLs or cache aggressively. There is little you can do except wait or advise affected users to switch their device DNS to 1.1.1.1 or 8.8.8.8.
NS record changes are not propagating after 48 hours. Check your domain registrar's control panel and confirm the nameserver update is saved correctly there — not just in your DNS host's interface. The registrar controls what the TLD zone publishes, and if the update was not submitted to the registry, propagation will never happen.
You are getting NXDOMAIN (domain not found) from some resolvers. This can happen if your new DNS provider started serving the zone before the nameserver delegation was complete, or if there is a typo in the zone configuration. Run dig yourdomain.com SOA against each nameserver to confirm the zone is actually loaded and returning a valid SOA record.
Summary
Checking DNS propagation is a three-step process: confirm your authoritative nameserver has the new record, use a global propagation checker to see which resolvers have picked it up, and test your own machine to understand your local experience. Use the TTL values in query responses to calculate exactly when lagging resolvers will refresh. Lower your TTL before planned changes to minimize the wait. And when in doubt, query multiple public resolvers directly to separate local caching issues from genuine propagation delays.