DNS Propagation Delay: Why Changes Take Time and How to Check It

Short answer: DNS propagation delay happens because recursive resolvers, internet service providers, and local devices cache old DNS responses according to the record's Time to Live (TTL) setting. To see if your change has propagated worldwide, test authoritative nameservers directly with dig or use a global checker like whatsmydns.net. To minimize downtime for future migrations, lower your TTL to 300 seconds a day in advance.

When you migrate to a new hosting provider, switch mail services, or launch a fresh site, you might wonder why colleagues in another city see the new site while you still see the old one. If your domain is not resolving or your new domain is not working, distinguishing between an actual DNS configuration mistake and simple propagation lag saves hours of troubleshooting.

Step 1: understand how DNS caching and TTL work

DNS is a globally distributed caching system designed to keep the internet fast. When a user requests your domain, their local device asks a recursive resolver (such as their ISP, Cloudflare's 1.1.1.1, or Google's 8.8.8.8).

That resolver looks at the record's TTL (Time to Live) value, measured in seconds:

TTL setting	Duration	Best use case
300 seconds	5 minutes	Active migrations, frequent changes, high flexibility
3600 seconds	1 hour	Standard websites, occasional updates
14400 seconds	4 hours	Stable mail settings like SPF and MX records
86400 seconds	24 hours	Static nameservers and infrastructure that rarely moves

If your old A record had a TTL of 86400 (24 hours), resolvers around the world are allowed to serve the cached old IP address for up to 24 hours after they first requested it. They will not ask your authoritative nameserver for an update until that timer expires.

Step 2: query your authoritative nameserver directly

To verify whether your DNS host actually saved your new record, skip all intermediate caching resolvers and query your authoritative nameserver directly.

First, look up which nameservers host your zone:

whois example.com | grep -i "Name Server"

Next, send a DNS query straight to one of those authoritative nameservers using dig:

dig @ns1.yourdnsprovider.com example.com A +noall +answer

If the answer shows your new server IP address, your DNS provider has already published the update. The delay you experience is strictly downstream caching. If the authoritative nameserver still returns the old IP, the change was not saved properly in your DNS dashboard.

Step 3: check global propagation across public resolvers

Once your authoritative nameserver has the record, check how widely public recursive resolvers have picked it up:

# Query Google Public DNS
dig @8.8.8.8 example.com A +short

# Query Cloudflare 1.1.1.1
dig @1.1.1.1 example.com A +short

# Query Quad9
dig @9.9.9.9 example.com A +short

If Google and Cloudflare return the new IP address, the vast majority of web traffic is already reaching your new server. If one resolver still returns the old address, check the TTL number in the answer block to see how many seconds remain before that resolver flushes its cache.

Step 4: clear your local operating system and browser cache

Your operating system and browser both maintain their own internal DNS caches to accelerate page loads. Even after public resolvers update, your computer might hold onto the old address.

To flush your DNS cache on Windows, open Command Prompt or PowerShell as administrator:

ipconfig /flushdns

On macOS, open Terminal and run:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux systems using systemd-resolved:

sudo resolvectl flush-caches

In Google Chrome and Chromium browsers, you can also clear the internal browser cache by visiting chrome://net-internals/#dns and clicking Clear host cache.

Step 5: how to plan future changes without propagation delays

You cannot force third-party resolvers across the world to dump their cache early. However, you can eliminate propagation delays before your next scheduled migration by following this timeline:

1. 48 hours before migration: lower the TTL on all records you plan to change (such as A, CNAME, and MX) to 300 seconds (5 minutes).
2. Wait out the old TTL: allow the previous longer TTL (for example, 24 hours) to expire completely so all global caches refresh with the new 300-second instruction.
3. Perform the switch: update the records to point to your new servers. Resolvers will now pick up the new IP addresses within 5 minutes.
4. 48 hours after migration: once you confirm everything is running smoothly, increase the TTL back to 3600 or 14400 seconds to reduce DNS query overhead.

Common mistakes

• Changing nameservers without lowering registry TTL: changing who hosts your DNS (NS records at your registrar) always takes longer (usually 24 to 48 hours) than changing an A record within an existing zone.
• Forgetting about router and ISP caching: home Wi-Fi routers often cache DNS responses and do not flush when you run ipconfig /flushdns on your computer. Restarting your router or testing on mobile data confirms the difference.
• Editing records at the wrong DNS provider: if your domain's registrar points nameservers to Cloudflare, but you edit records inside GoDaddy, your changes will never propagate because GoDaddy is no longer authoritative.
• Testing over active HTTP/3 or QUIC connections: modern browsers maintain persistent socket connections. A browser might continue talking to the old server over an open connection even after DNS has updated. Close and restart the browser completely.