What Is DNS Propagation and Why Does It Take 24 to 48 Hours?

You change a DNS record, your host says “it can take 24 to 48 hours”, and for the rest of the day your website loads perfectly on your phone and not at all on your office laptop. Nothing is broken. This is DNS propagation, and understanding it is the difference between a calm migration and a panicked one.

What DNS actually does

Every website lives on a server with a numeric IP address, something like 203.0.113.45. Nobody wants to type that, so the Domain Name System acts as the internet’s address book: you type a domain name, DNS returns the IP address, and your browser connects to it.

The address book is not in one place. It is copied across millions of servers worldwide — your internet provider’s resolver, your office router, your operating system, your browser. That distribution is what makes DNS fast and resilient. It is also exactly why a change takes time to appear everywhere.

So what is propagation?

Propagation is the window between you changing a DNS record and every one of those cached copies worldwide catching up.

Strictly speaking, DNS doesn’t “spread”. Nobody pushes your new record out to the world. Instead, each cached copy simply expires on its own schedule, and the next person to ask gets the new answer. Propagation is millions of independent caches timing out at different moments — which is why the change looks patchy while it happens.

TTL: the number that controls everything

Every DNS record carries a value called TTL, or time to live, measured in seconds. It tells any server that caches your record how long to hold onto it before asking again.

• TTL 300 = five minutes. Caches refresh quickly; changes appear almost immediately.
• TTL 3600 = one hour. A common default.
• TTL 86400 = 24 hours. Very common, and the reason for the “up to 48 hours” warning.

Here is the part that catches everyone out: lowering the TTL only helps if you do it in advance. If your TTL is 86400 and you drop it to 300 and immediately change your A record, every resolver that already cached the old record is still holding the old 24-hour instruction. Your change is invisible to them for another day.

The correct sequence is: lower the TTL, wait for the old TTL period to pass (24 hours if it was 86400), then make your actual change. Now it lands in five minutes. Raise the TTL back afterwards, because a permanently low TTL means more lookups and marginally slower first connections.

Why it looks different on different devices

This is the single most confusing symptom, and it is completely normal.

Your mobile phone on 4G uses your mobile network’s resolver. Your laptop in the office uses your broadband provider’s resolver. Those two caches expire at different times, so for a few hours one device sees the new server and the other sees the old one. Nothing is wrong. They will converge.

There is also caching closer to home: your operating system keeps a DNS cache, and so does your browser. You can often see the new record before your colleagues simply because you cleared yours.

Why “up to 48 hours” is usually pessimistic

The 24–48 hour figure is a safe worst case, not a typical one. In practice:

• With a TTL of 300 set in advance, most of the world sees the change within minutes.
• With a default TTL of 3600, most traffic moves within an hour or two.
• Changing nameservers rather than individual records takes longer, because that change goes through the domain registry itself and those records have their own, longer TTLs.

Some internet providers also ignore short TTLs and hold records longer than they are told to, which is the real source of the occasional two-day tail.

How to check propagation properly

Loading your own website in your own browser is the least reliable test there is, because you are looking through several layers of your own cache.

Better options:

• Command line. Run nslookup yourdomain.com (Windows) or dig yourdomain.com (macOS and Linux). This queries DNS directly and shows you the IP being returned, plus the remaining TTL.
• Query a specific resolver. nslookup yourdomain.com 8.8.8.8 asks Google’s public DNS, bypassing your provider entirely.
• A global checker. Online DNS propagation tools query resolvers in dozens of countries at once and show you a map of which regions have updated.

To clear your own cache: on Windows, ipconfig /flushdns in an admin command prompt. On macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Then restart your browser, because it keeps its own separate cache.

The records you will actually deal with

• A record — points your domain at an IPv4 address. This is the one you change when you move hosts.
• AAAA record — the same thing for IPv6.
• CNAME — points one name at another name, commonly used for www.
• MX record — directs your email to a mail server. Entirely separate from your website, which is why you can move hosting without moving email, and vice versa.
• TXT record — holds text, most importantly your SPF, DKIM and DMARC records that prove your email is legitimate. Forgetting to recreate these after a move is a classic cause of mail suddenly landing in spam.
• NS record — names the authoritative nameservers for your domain. Changing these moves DNS control wholesale, and takes the longest to settle.

How to avoid downtime entirely

The elegant answer to propagation is to make the answer correct on both servers during the window.

If your site is fully working on the new server before you change DNS, then it does not matter which server a given visitor reaches during propagation — both show a working site. That is exactly why our migration guide insists on testing through your hosts file before touching DNS, and on keeping the old hosting running for a week afterwards.

For email it works the same way: create the mailboxes on the new server first, then change the MX record. Mail arriving at either server during the window has somewhere to land.

Frequently asked questions

Can I speed up DNS propagation?

Not once you have made the change — the caches holding the old record will expire when they expire. The only real lever is lowering your TTL 24 to 48 hours before the change. You can clear your own device’s cache to see the new record sooner, but that does nothing for your visitors.

Will my website be down during propagation?

Not if you prepare. Visitors reaching the old server see the old site; visitors reaching the new one see the new site. Downtime only happens if you switch DNS before the new server is ready, or if you cancel the old hosting too early.

Why can I see my site but my client can’t?

Different resolvers, different cache expiry times. Ask them to try on mobile data instead of their office network — if it works there, it is propagation, not a fault.

Does changing nameservers take longer than changing an A record?

Yes, usually. Nameserver changes are handled by the domain registry and typically carry longer TTLs, so they can genuinely take a day or more. If you only need to point the site at a new server, changing the A record at your existing DNS provider is faster.

What is the ideal TTL to run day to day?

3600 seconds — one hour — is a sensible default for most business websites. It keeps lookups efficient while meaning any emergency change is live within the hour. Drop to 300 in the run-up to a planned migration, then put it back.

Do I have to move my domain to move my hosting?

No. Your registrar and your host can be different companies indefinitely; you just point the DNS at the host. Plenty of people do consolidate both eventually because one login is easier than two. Our domains page covers registration and transfers.

Need a hand with the DNS side?

Getting records right is the part of a migration where a second pair of eyes genuinely pays for itself — particularly the SPF, DKIM and DMARC records that decide whether your email reaches the inbox. We set all of this up for customers moving to Salasar Hosting, and we will look at your current zone with you before anything changes.

Call +91 99620 05753 or get in touch. If you are still deciding on a plan, start with shared hosting or VPS hosting.