DNS Propagation Explained: How Long It Really Takes and How to Check

Short answer: "DNS propagation" is just caches expiring. Your DNS host publishes a change almost instantly, but resolvers around the world keep serving the old answer until its TTL (time to live) runs out. A record with a 300-second TTL is fully updated in about 5 minutes; with a 3,600-second TTL, within an hour. A nameserver change on a .com domain can take up to 48 hours, because the registry's delegation records carry a 172,800-second TTL.

What actually happens when you change a record

Nothing is pushed anywhere. Your authoritative nameservers start answering with the new value right away. Recursive resolvers (your ISP, your router, Google Public DNS, Cloudflare 1.1.1.1) that looked the name up earlier stored the old answer together with its TTL, as defined in RFC 1035. They only ask again when that timer reaches zero. Different resolvers cached the record at different moments, so for a while some users see the new answer and others the old one. That patchy window is what people call propagation.

How long each kind of change takes

• Changing an existing record (A, AAAA, CNAME, MX, TXT): up to the old record's TTL. Check the TTL before you change anything; it is the number in seconds shown by dig.
• Adding a brand-new record: usually immediate, unless someone looked the name up while it did not exist. Then the "doesn't exist" answer is cached for the negative-caching time from the zone's SOA record (RFC 2308), often 5 minutes to an hour.
• Changing nameservers: the registry updates within minutes, but resolvers may keep the old delegation for its full TTL: 48 hours for .com and .net, and varying values for other TLDs.
• Turning DNSSEC on or off: governed by the DS record TTL at the registry, often 1 to 2 days.

Browsers and operating systems add their own short-lived caches on top, which is why the same laptop can disagree with your phone for a few minutes.

How to make changes take effect faster

1. Lower the TTL in advance. A day before a planned move, set the record's TTL to 300 seconds and wait at least the old TTL so every cache picks up the short one. After the change, raise it again (3,600 or more is normal).
2. Change, don't delete and re-add. Editing a record avoids the negative-caching delay that comes from a moment where the name doesn't exist.
3. Keep the old target running (old server, old nameservers) until the longest TTL involved has passed.
4. Clear the public caches you can. Google Public DNS has a Flush Cache page and Cloudflare 1.1.1.1 has a Purge Cache tool. Neither affects other resolvers.

How to check propagation properly

First confirm the source is right by asking your authoritative nameserver directly. If it shows the old value, the problem is your DNS host, not propagation:

dig NS example.com +short                 # find your nameservers
dig @ns1.your-dns-host.example example.com A    # ask one directly

Then compare large public resolvers and watch the remaining TTL count down:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @9.9.9.9 example.com A

Our DNS Lookup and Nameserver Lookup tools run the same checks from the web. For nameserver moves, the step-by-step check at the registry is in How to Change Nameservers.

Flush the caches on your own devices

• Windows: ipconfig /flushdns in an administrator Command Prompt.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux with systemd-resolved: resolvectl flush-caches
• Chrome: open chrome://net-internals/#dns and click "Clear host cache."

Restarting your router clears its cache too, but it can't make your ISP's resolver forget an answer early.

The bottom line

Propagation is predictable: it is the TTL. Read the TTL before you change anything, lower it ahead of planned moves, verify at the authoritative server first, and keep the old setup running until the longest TTL has passed.