First: "propagation" is a misleading word
Nobody is pushing your change out across the world. There's no queue, no delivery, no server slowly handing off to the next one.
What's actually happening: servers around the world already hold an old answer, stored locally. They keep using it until it expires. You're not waiting for something to arrive — you're waiting for something old to be thrown away.
That's why one person sees the new site immediately and their colleague at the next desk sees it six hours later. They're simply asking different servers holding differently-aged answers.
How a question becomes an answer
When you type company.com into a browser:
- Your computer checks its own cache. If it has an answer, it stops there and asks nobody.
- If not, it asks your internet provider's DNS server.
- That server checks its cache. If it has an answer, it returns it. This is where the delay lives.
- If not, it walks up the chain: root servers → the
.comservers → the servers holding your zone. - The answer comes back, and everyone along the path stores it for a set time.
Step 3 is the bottleneck. Your provider's cache doesn't know you changed anything, and has no way to find out. It just waits.
TTL — the number that decides everything
Every DNS record carries a number with it: TTL (Time To Live), in seconds. It means "keep me this long".
| TTL | In hours | What it means |
|---|---|---|
| 300 | 5 minutes | The change shows up almost immediately |
| 3600 | 1 hour | Common default. A working day. |
| 14400 | 4 hours | Frequent on older setups |
| 86400 | 24 hours | You will be waiting. A lot. |
The trick that actually works: if you know you're moving the site in three days, drop the TTL to 300 today. Once the old TTL expires, the whole world is only holding your answers for five minutes. Then you make the real change and it appears within minutes. Afterwards you put the TTL back up.
If you've already made the change — too late. The TTL that governs the wait is the one on the old answer, not the new one.
Why changing nameservers takes longer than changing an A record
They're two different things at two different levels.
- An A record lives in your zone. Change it and the record's own TTL applies — typically an hour.
- Nameservers (NS) live in the
.comor.bgzone, at the registry. TTLs there are far longer — for.comthe registry returns 48 hours.
That's why "up to 24–48 hours" is what you hear about nameserver changes, and "within minutes" about A-record changes. Both are true, for different operations. Which one you need: How to point your domain.
How to check where it's got to
Online, easiest: dnschecker.org — enter the domain and see what servers in 20+ countries return. Green ticks everywhere = done.
From your own machine:
nslookup company.com
Works on Windows, Mac and Linux with nothing to install. On Mac and Linux this is more precise:
dig +short company.com
To bypass your provider's cache and ask a public resolver directly:
nslookup company.com 1.1.1.1
If that returns the new IP but your browser doesn't, the problem is a local cache, not DNS.
"It works for everyone else, not for me"
Almost always a cache somewhere between your browser and the internet. In order of likelihood:
- The browser. Open the site in a private window or a different browser.
- Windows. Open Command Prompt and run
ipconfig /flushdns. - Mac. In Terminal:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - The router at home or in the office. Unplug it for ten seconds.
- Mobile data. Load the site over mobile with Wi-Fi off. If it works there, the problem is your network, not the domain.
One thing that genuinely can get stuck
There's a case where waiting doesn't help: if the domain was parked or pointed at a non-existent address and some server cached the negative answer. That expires too, but under a different rule (the zone's SOA minimum), and it's sometimes longer than you'd expect.
If it still doesn't work after 48 hours, stop waiting. Email us — it takes five minutes to see whether the problem is in the zone, the delegation, or a cache.
While you wait, the site is not down
If you're migrating to us, your old site keeps serving throughout. Anyone still seeing the old IP sees the old site; anyone seeing the new IP sees the new one. Nobody sees an error. That's why we don't touch the old host until we're certain everything has moved.