DNS propagation: why your website changes aren't showing yet

Changed nameservers or DNS records and still seeing the old site? What "propagation" really is, how long it takes, how to check it, and how to speed it up.

You moved your website to a new host, or pointed your domain at a new service, and you are still seeing the old site. Or your phone shows the new site and your laptop shows the old one. Or your email has gone quiet. Your new host says to "wait for DNS propagation, up to 48 hours", which is true but not very helpful when your business is on the other end.

This guide explains what is actually happening during those hours, why different people see different versions, how to check where the change has reached, and what you can do to shorten the wait next time.

What "propagation" really is

The word suggests your change is slowly travelling across the internet. It isn't. When you save a DNS change, it takes effect on your DNS provider's servers within seconds or minutes. What takes time is everyone else forgetting the old answer.

Looking up a domain name is slow by computer standards, so the answer is saved (cached) at several points: by your internet provider's DNS servers, by public resolvers such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1, by your operating system and by your browser. Each saved answer carries a TTL (time to live), a number of seconds set by whoever owns the record, telling everyone how long they may reuse it before asking again. Until that time runs out, they keep using the old answer, and they are right to.

So "propagation" is the period during which caches all over the world expire at different moments. Someone whose provider looked up your domain just before the change sees the old site for the full TTL. Someone whose provider had never looked it up sees the new one immediately. That is why the results are inconsistent, and why a website can look fine for you and broken for a customer.

How long it actually takes

The 48-hour figure your host quotes is a ceiling, not an estimate. Most visitors see a change much sooner. If something still has not updated after 48 hours, it is almost never propagation; there is a mistake in the setup, covered further down.

How to check where the change has reached

First find out what you are actually seeing, rather than guessing from how the page looks.

• A global checker such as whatsmydns.net queries DNS servers in dozens of countries and shows which answer each one has. A mix of old and new answers means propagation is under way. All new means you are waiting on local caches. All old means check your setup.
• Ask a specific public resolver directly from a terminal. On a Mac or Linux use dig; on Windows use nslookup.

# What do Google and Cloudflare currently return?
dig yourdomain.com A @8.8.8.8 +short
dig yourdomain.com A @1.1.1.1 +short

# Which nameservers does the registry say are in charge?
dig yourdomain.com NS +short

# Windows
nslookup yourdomain.com 8.8.8.8

Compare the IP address that comes back with the one your new host gave you. If the authoritative answer is right and only some resolvers are wrong, it is propagation, and it will sort itself out. The WHOIS lookup tool also shows which nameservers are set at the registrar.

How to speed it up

Before a change: lower the TTL

If you know a move is coming, this is the only step that really shortens the wait. A day or two before, lower the TTL on the records you will change (the A record for your domain and www, and MX if email is moving) to 300 seconds, which is five minutes. Wait at least as long as the old TTL so every cache has picked up the short one. Then make the change: the old answer now disappears within five minutes. Once everything is stable, raise the TTL back to an hour or more.

Lowering the TTL does not help nameserver changes, because the nameserver TTL belongs to the registry rather than to you. For a move with no visible gap, keep the old hosting running until the new nameservers have fully taken over. Our guide to moving a website without downtime covers the full order of steps.

After a change: clear the caches you control

You cannot clear your internet provider's cache, but you can clear your own, and you can ask the big public resolvers to forget your domain:

• Mac: run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in Terminal.
• Windows: run ipconfig /flushdns in Command Prompt.
• Chrome: open chrome://net-internals/#dns and click Clear host cache.
• Phones: turn airplane mode on and off.
• Google Public DNS: use the flush cache page.
• Cloudflare 1.1.1.1: use the purge cache page.

Preview the new server before DNS catches up

To check a migrated site before everyone sees it, you can point just your own computer at the new server by adding a line to its hosts file (/etc/hosts on a Mac, C:\Windows\System32\drivers\etc\hosts on Windows) with the new IP address followed by your domain. Remove the line when you are done, or you will keep seeing that server whatever DNS says later.

Still wrong after 48 hours? It isn't propagation

If the global checker shows the old answer everywhere, or the change never arrives, one of these is almost always the reason:

1. 1You edited records in the wrong place. DNS records only count where your nameservers point. If your domain uses your host's or Cloudflare's nameservers, records edited at the registrar are ignored, and vice versa. Run the NS lookup above and edit the zone at whichever company it names.
2. 2The nameserver change was never saved, or it was saved with a typo. Check it in the WHOIS result.
3. 3DNSSEC is still set for the old provider. If DNSSEC was on and you changed nameservers without removing the old DS record at the registrar, validating resolvers reject your domain and visitors see "can't be reached". Remove or update the DS record.
4. 4You are looking at another cache. A CDN, a caching plugin or the browser can serve an old copy of the page even after DNS is correct. Test in a private window, and purge the CDN or plugin cache.
5. 5The domain has expired or is on hold. The WHOIS status shows this.

What about email during the change?

Email follows the same rules through your MX records, but it is more forgiving than a website: a sending server that cannot deliver keeps retrying, typically for several days, before it bounces a message. The risk during a move is mail arriving at the old mail server after you stop checking it. Keep the old mailbox working until the new MX records have been in place for longer than their old TTL, and check both. If you are also changing email providers, set up the SPF, DKIM and DMARC records described in our email security guide at the same time, so mail from the new provider is not marked as spam.