DNS Propagation Explained: How Long It Really Takes

You changed a DNS record twenty minutes ago and the site still looks wrong on your phone. Someone on your team swears it's fixed. Your neighbor says it's still broken. Nobody's lying — this is what DNS propagation actually looks like, and once you understand why it's uneven, you stop refreshing the page every ninety seconds and start checking the right things instead.

Symptom: The Change "Isn't Working" but It Actually Is

This shows up in a few predictable ways after you update an A record, switch nameservers, or add an MX record:

• The new site loads on your laptop but the old one still shows on your phone over mobile data.
• A colleague in another city sees the update instantly; you don't see it for six hours.
• Email starts bouncing right after an MX change, then quietly starts working again the next morning.
• nslookup from your machine returns the old IP even though you're positive you updated the record correctly in the Zone Editor.

None of this means the change failed. It means the internet hasn't finished asking around yet.

Cause: DNS Is a Cache, Not a Live Broadcast

There's no central switch that flips the moment you hit save. Every DNS record has a TTL (Time To Live) — a number in seconds that tells every resolver that reads it "you can trust this answer for this long before you have to ask again." Nothing pushes the update out to the world; the old answer just keeps getting served, from cache, until it expires on its own.

Who's actually holding the stale copy

That's why two people ten feet apart can see different versions of your site: they're not hitting the same cache. Your phone's carrier and your home Wi-Fi's ISP are two completely separate resolvers with two completely separate expiry clocks.

Nameserver changes are the slow one

Changing a single A record only has to wait out that record's TTL. Changing nameservers is slower and less predictable, because the registry itself needs to update, and that update has its own TTL — often 24-48 hours — regardless of what TTL you'd set on individual records at the old provider. This is the one case where "just wait a day" is genuinely the right answer, not an excuse.

Fix: What to Actually Do While You Wait

1. Check propagation from outside your own network

Don't trust your own browser — it's the most cached thing in the chain. Use a tool that queries resolvers around the world at once:

• whatsmydns.net — shows the record from 20+ locations globally in one screen.
• dig yourdomain.com +short @8.8.8.8 — bypasses your local resolver and asks Google directly.
• dig NS yourdomain.com — confirms which nameservers are actually authoritative right now, which matters if you're not sure the registrar change even saved.

If whatsmydns shows the new value in most locations but your own browser still shows old, the DNS change worked — the problem is local caching, not the record.

2. Flush the cache that's actually stale

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Just the browser
Close every tab for the domain and restart the browser,
or open the site in an incognito/private window first.

Flushing your own machine's cache never speeds up what your ISP or a visitor's phone carrier has cached — it only fixes what you personally see.

3. Lower the TTL before you make the change, not after

This is the move that actually shortens propagation, and it has to happen in advance:

1. A day or two before a planned migration or nameserver switch, log in to the current DNS provider's zone editor.
2. Drop the TTL on the records you're about to change — from the default 3600 or 14400 seconds down to 300 (5 minutes).
3. Wait at least as long as the old TTL, so every resolver that already cached the record re-fetches it and picks up the new, shorter TTL.
4. Now make your real change. Any resolver checking in will re-ask within 5 minutes instead of within an hour or a day.
5. Once things have settled, put the TTL back up to a sane default (3600+) — a permanently low TTL adds unnecessary load and slightly slower normal resolution.

If you're moving to Getwebup and didn't lower TTL in advance, don't panic — most A record changes still clear within an hour or two for the majority of visitors, even on the old default TTL. It's nameserver changes and unusually high TTLs (86400+, a full day) where advance planning actually matters.

4. Keep both environments alive during the window

Whatever you do, don't take the old host offline the moment you flip DNS. Some percentage of visitors will keep hitting the old server for hours based on their resolver's cache. Keep the old site and mailbox running in parallel until propagation checks clean across most global locations — then decommission the old one.

Prevention: Make the Next Change Painless

• Set a calendar reminder to lower TTL 48 hours before any planned nameserver or major DNS change.
• Keep a record of your current DNS zone (screenshot or export) before touching nameservers — MX, TXT/SPF/DKIM, and CNAME records are easy to forget and don't propagate back on their own.
• Test from a public checker, not your own browser, before declaring a DNS change "done" or "broken."
• For anything time-sensitive (a launch, a marketing email blast), do the DNS change on a quiet day with buffer time, never minutes before it needs to be live.

DNS propagation isn't a bug in your setup — it's caching working exactly as designed, just not on a schedule you control. Plan around the TTL instead of fighting it, and "it's still showing the old site" stops being a mystery and starts being a number you can predict.