DNS propagation: why website changes take time to show

You moved the site to a new server this morning. On your laptop the new design loads perfectly. Your colleague two streets away still sees the old homepage, and a customer on mobile data sees something in between. Nobody has broken anything. This is DNS propagation, and the word itself is misleading, because nothing is actually spreading outwards. What is really happening is that thousands of independent resolvers are each holding an old answer until their copy expires.

Understanding that distinction changes how you plan changes, and stops you from making things worse while you wait.

Why the word propagation is misleading

When you edit a record, the change is instant at your authoritative nameservers. There is no queue and no global rollout. The delay comes from everyone else.

Between a visitor and your nameservers sits a chain of caches: their device, their browser, sometimes their router, and above all their internet provider's resolver. Each of those keeps answers for a while so it does not have to ask again for every page load. Until the copy they hold expires, they keep serving it, whatever you changed.

That is why the experience is patchy rather than gradual. Two people on the same street with different providers can see different versions of your site for hours.

TTL: the number that decides how long you wait

Every DNS record carries a time to live, measured in seconds. It is the instruction to resolvers: you may remember this answer for this long.

• 300 seconds is five minutes, suitable just before and during a migration.
• 3600 seconds is one hour, a common default.
• 14400 seconds is four hours.
• 86400 seconds is a full day, often used for records that never change.

The crucial point that trips people up: lowering the TTL only helps if you do it in advance. If a record currently has a 24-hour TTL and you lower it to five minutes at the same moment as changing the address, resolvers that already cached the old answer will still hold it for up to a day, because they took your old instruction before you revised it.

How to plan a migration around the TTL

1. Two days before: look at the current TTL of the records you will change, usually the A, AAAA, CNAME and MX rows.
2. At least one full old-TTL period before the switch: lower those TTLs to 300 seconds and save. If the old TTL was a day, do this two days ahead to be safe.
3. Prepare the new destination: have the site fully working and the certificate issued at the new server before touching DNS.
4. Make the change during your quietest hours. For consumer sites in India, early morning usually sees the least traffic.
5. Keep the old server running for at least a week, serving the same content, so visitors still holding the old address are not shown an error or an outdated page.
6. After a stable day or two: raise the TTLs back to an hour or more.

The step people skip is the last one before the switch: making the new server ready first. Pointing DNS at a server that is not finished converts a smooth move into visible downtime.

Checking a change from more than your own browser

Your own machine is the worst place to test, because it has the most caching layers and the strongest muscle memory about the old site.

• Query the authoritative nameservers directly. If they return the new value, your part of the job is finished and everything else is waiting.
• Use an online lookup tool that checks resolvers in several countries and cities, so you can see the spread rather than one data point.
• Test on mobile data, which uses a different resolver from your office broadband.
• Use a public resolver such as Google's or Cloudflare's to cross-check. These update quickly and are a good early signal.
• Flush your own caches: the browser, the operating system's DNS cache, and the router if it caches.
• Check the site by IP address, using a hosts file entry, to confirm the new server serves the right content independently of DNS.

How long propagation really takes

For a simple record change with a one-hour TTL, most visitors see the new answer within an hour or two, and almost everyone within a day. Nameserver changes at the registrar take longer, commonly several hours up to 48, because those delegation records sit higher in the chain and are cached with their own long TTL.

A handful of resolvers ignore short TTLs and hold answers longer than instructed, and some office networks and devices cache aggressively. This is the long tail that makes 24 to 48 hours the honest answer to give a client, even when the practical change happens far sooner.

Mistakes that make the wait worse

• Editing repeatedly while waiting. Each change resets your certainty about what is cached where and can leave several versions circulating.
• Switching the old server off immediately. Anyone still holding the old address gets a hard failure rather than an old page.
• Changing web hosting and mail at the same moment. If something goes wrong you cannot tell which change caused it, and email problems are harder to detect than website ones.
• Judging success from your own screen. Browser caching and service workers can show you an old page even after DNS is correct.
• Assuming propagation explains everything. If the authoritative nameservers already return the new value and a page is broken, the fault is on the server, not in DNS.

Set expectations before the switch

Practical preparation beats explanation afterwards. Lower TTLs in advance, tell colleagues and any waiting client that both old and new versions may appear for up to a day, and keep both servers alive during the overlap. If you have a migration coming up and want it timed and verified properly, our team handles this regularly as part of hosting and migration work.

Frequently asked questions

How long does DNS propagation take?

Usually minutes to a few hours for record changes, and up to 48 hours for nameserver changes. The dominant factor is the TTL that was in place before you made the edit.

Can I speed up DNS propagation?

Not after the fact. You can only prepare by lowering the TTL well in advance. Flushing your own caches helps you personally, not your visitors.

Why do some people see the new site and others the old one?

Because each resolver caches independently and expires its copy at a different moment. Two visitors with different internet providers can get different answers for hours.

Does DNS propagation affect email too?

Yes. MX record changes cache in the same way, so mail can be delivered to both the old and the new server during the overlap. Keep the old mailbox accessible until you are sure everything arrives at the new one.