If you want the full picture of what each DNS record type does, we've covered that separately in DNS records explained. This one assumes you already know roughly what an A record or an MX record is, and just want to understand why the internet hasn't caught up to your change yet — and what you can actually do about it right now, mid-migration, rather than just waiting.
"Propagation" is the wrong mental model
The word makes it sound like your change is a ripple spreading slowly outward across the internet. It isn't. The moment you save a DNS change, it's live on your domain's authoritative nameservers — the source of truth for that record. There's no delay there, and no wave rolling out from it.
What actually delays things is caching. Every DNS record carries a TTL (Time To Live), a number of seconds that tells any resolver "you're allowed to remember this answer for this long before you have to ask again." Anyone who looked up your domain recently — their ISP's resolver, a corporate DNS server, their own device — is holding a cached copy that's still considered valid until its TTL runs out, completely unaware that the real answer already changed.
So the honest description of what you're waiting for isn't "propagation". It's a scattered collection of independent caches, each holding a stale answer, each expiring on its own separate clock. There's no coordination between them, which is exactly why two people can look at your site at the same moment and see two different servers.
Why one person sees the new site and another doesn't
This is the part that trips people up mid-migration, because it feels like something's broken. It isn't — it's just cache timing.
Say the record had a one-hour TTL. If your colleague looked up the domain ten minutes before you made the change, their resolver cached the old answer and won't ask again for close to an hour. If you look it up fresh right now, your resolver has no cached copy, asks the authoritative nameserver directly, and gets the new answer immediately. Same domain, same instant, two different answers — because you're not really asking the same question. You're each asking your own cache first.
Mobile networks and some corporate DNS setups make this worse, not because they're slower, but because they often sit behind additional layers of shared resolvers serving many users from one cache. It's still the same mechanism, just with more caches in the chain between you and the authoritative answer.
How to check what's actually live right now
Stop refreshing your browser — it's checking your own cached answer, which tells you nothing about whether the change actually took. Query a public DNS server directly instead, which forces a fresh lookup rather than reading from anyone's cache:
dig yourdomain.com @8.8.8.8That asks Google's public resolver specifically, bypassing whatever your ISP or device currently has cached. If you don't have dig installed (it ships by default on macOS and most Linux systems; on Windows you can use nslookup instead), a web-based DNS checker that queries multiple resolvers around the world works just as well for a quick sanity check.
If that query already returns your new value, the change worked and any stale results you're personally seeing are purely a caching artefact on your end — not a sign anything is wrong.
The TTL move that makes a migration painless
If you know a change is coming — a host migration, a new mail provider, anything where a clean cutover matters — don't just make the change and hope. Prepare the TTL in advance:
- A day or two before the cutover, lower the TTL on the specific records you're about to change — commonly down to 300 seconds (five minutes). This doesn't change anything visible yet; it just tells caches to stop holding the answer for as long, starting now.
- Wait until the old, longer TTL has fully expired everywhere before you cut over. If the record previously had a one-hour TTL, give it at least that long after lowering it, so no cache anywhere is still holding the old long-lived value.
- Make the actual change once the short TTL is in effect everywhere. Because caches are now only holding the answer for five minutes at a time, the cutover feels close to instant for almost everyone.
- Once things have settled — a few days after the migration — raise the TTL back up to a more normal value. A very low TTL forever means more DNS lookups for no ongoing benefit.
This only works if you plan ahead. Lowering the TTL at the same moment you make the actual change doesn't help — anyone who already cached the old value at the old (longer) TTL is still holding it for the original duration. The lower TTL has to already be in effect, and the old TTL has to have already expired, before the real change goes out.
Before you assume it's DNS at all
A genuine amount of "DNS isn't updating" turns out to be nothing to do with DNS:
- Your browser cached the page itself, separate from DNS entirely. Try a private/incognito window before concluding anything.
- Your operating system has its own local DNS cache, distinct from your browser and your ISP. It usually clears on its own well within the TTL window, but it's a real extra layer worth knowing about if you're troubleshooting.
- You changed the record in the wrong place. This is the single most common actual cause of "DNS won't update" — the change was made in a control panel that isn't where the domain's nameservers actually point. If in doubt, confirm where the domain's nameservers point before assuming the DNS system itself is being slow.
The honest summary: DNS changes are fast. What feels slow is caches you can't see, expiring on their own schedule. Query the authoritative answer directly, plan your TTL ahead of a migration rather than during it, and most "DNS is broken" moments resolve themselves in minutes rather than hours.
Mid-migration and not sure if it's actually gone wrong? Send through what you're seeing and we'll tell you straight away whether it's caching or an actual misconfiguration.
Get in touch →Frequently asked questions
How long does DNS propagation actually take?
There's no fixed propagation time. The change is live on the authoritative nameservers almost immediately — what you're waiting on is cached copies expiring, governed by TTL. Most changes are visible to most people within minutes to an hour.
Why do two people see different versions of my site after a DNS change?
Their resolvers cached the old record at different times, so their caches expire at different moments. It isn't a fault in DNS — just independent caches on independent schedules.
How do I check a DNS change without waiting for my own cache to clear?
Query a public resolver directly, e.g. dig yourdomain.com @8.8.8.8, which bypasses your local and ISP cache and shows what a fresh lookup returns right now.
Should I lower my TTL before a migration?
Yes. Lower it a day or two beforehand so the old, longer TTL fully expires before you cut over — then the actual switch feels close to instant instead of leaving stragglers on the old server for hours.