How to check DNS propagation for your domain

How long DNS propagation takes

Nothing is actually pushed around the world when you edit DNS. Your domain's nameservers start giving the new answer straight away. What takes time is the resolvers run by internet providers, offices, Google and Cloudflare: each one keeps a cached copy of the old answer until its TTL (time to live, in seconds) runs out, and only then asks again. That's why two people on different networks can see different sites for a while.

For the details of each record type and how TTL values are chosen, see DNS records explained.

Step 1: Write down the values you expect

A check is only useful if you know what "done" looks like. Note the exact value you set, because most confusion comes from comparing against the wrong thing.

• Moved your website: the server IP shown under General Information on the cPanel home screen, or the IPv4 address of your VPS in the client area.
• Changed nameservers: the two names in your hosting welcome email, such as ns1.your-assigned-ns. Our guide to pointing a domain to your hosting shows where to find them.
• Changed email: the MX host and priority your mail provider gave you, plus any SPF or DKIM TXT records.

Also note the old value. When you see it in a result, you'll know that resolver simply hasn't refreshed yet, rather than something being wrong.

Step 2: Check public resolvers with our DNS lookup

The quickest test needs no software. Open our free DNS lookup tool, enter the domain, choose the record type (A for a website, NS for nameservers, MX for email) and run it. It asks Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8) the same question at the same moment and shows both answers side by side, with the TTL each one still has left.

How to read the result:

• Both show the new value: the change is live for most of the internet. Anyone still seeing the old site has a local cache; go to Step 4.
• One new, one old: normal while propagating. The TTL on the old answer tells you, in seconds, how long that resolver will keep it.
• Both old, hours later: the change may not have been saved where it counts. Check the authoritative nameserver in Step 3.
• An error such as SERVFAIL: usually a DNSSEC mismatch after a nameserver change; see troubleshooting.

Step 3: Check from your own computer

The command line lets you do one thing a website can't: ask your domain's authoritative nameserver directly. Its answer is the truth that every resolver will eventually copy, so if it's wrong, waiting won't help. Pick your computer:

# 1. Which nameservers is the domain using?
Resolve-DnsName yourdomain.in -Type NS -Server 8.8.8.8

# 2. Ask one of those nameservers directly (the truth)
Resolve-DnsName yourdomain.in -Type A -Server ns1.your-assigned-ns

# 3. What do public resolvers have cached, and for how long?
Resolve-DnsName yourdomain.in -Type A -Server 1.1.1.1 -DnsOnly
Resolve-DnsName yourdomain.in -Type A -Server 8.8.8.8 -DnsOnly

nslookup -type=NS yourdomain.in 8.8.8.8
nslookup yourdomain.in ns1.your-assigned-ns
nslookup yourdomain.in 1.1.1.1

# 1. Which nameservers is the domain using?
dig +short NS yourdomain.in

# 2. Ask one of those nameservers directly (the truth)
dig +short A yourdomain.in @ns1.your-assigned-ns

# 3. What do public resolvers have cached, and for how long?
dig +noall +answer A yourdomain.in @1.1.1.1
dig +noall +answer A yourdomain.in @8.8.8.8

# Nameserver change? Follow the delegation from the root down
dig +trace NS yourdomain.in

In the full answers, the number after the name is the TTL remaining in that resolver's cache. A line such as yourdomain.in. 2410 IN A 198.51.100.10 means that resolver will keep serving the old IP for another 2,410 seconds, about 40 minutes, and then fetch the new one. Run it again later and you'll see the number count down.

Step 4: Clear the DNS cache on your device

When public resolvers already show the new value but your own screen doesn't, the stale copy is on your side: in the operating system, the browser or your router. Clear the one that applies; it's harmless and takes seconds.

ipconfig /flushdns
# or, in PowerShell
Clear-DnsClientCache

# macOS (enter your Mac password when asked)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved (Ubuntu and most desktops)
sudo resolvectl flush-caches

On a phone there's no flush button: turn Airplane mode on for ten seconds and off again, or switch between Wi-Fi and mobile data, which also gives you a second network to compare. On Android, a Private DNS provider set in network settings is used instead of your Wi-Fi's resolver.

Still old after that? Restart your Wi-Fi router, which often runs its own small cache, and check that your computer's hosts file doesn't still hold a test entry for the domain from a migration. Migrate your website shows where that file lives.

Step 5: Make the next change propagate faster

You can't hurry a cache that already holds the old answer, but you can make sure the next change only waits five minutes:

1. Lower the TTL a day ahead

   Set the records you're about to change to 300 seconds in cPanelDomainsZone Editor or at your DNS provider. Do it at least one old TTL before the move (a day is safe), because resolvers only learn the shorter TTL when their current copy expires.

2. Make the change

   Most visitors now switch within five minutes. Check with the DNS lookup tool until both resolvers agree.

3. Raise the TTL again

   Once everything works, set it back to 3600 or the cPanel default of 14400. Long TTLs mean fewer lookups and slightly faster first visits.

Changing nameservers? The registry's TTL is fixed, so instead make both old and new DNS give the same answers before you switch. Copy every record, including MX and TXT, into the new zone first; then it doesn't matter which nameserver a visitor's resolver asks during the changeover.

DNS propagation troubleshooting