How do I check if DNS has propagated?

Ask the authoritative nameservers with dig @nameserver to confirm the new value is published, then ask public resolvers such as 1.1.1.1 and 8.8.8.8. The TTL they show is the time left before their cached copy expires.

Can I speed up DNS propagation?

Not after the change. Lower the TTL well before a planned change, and clear your own caches when testing. Cloudflare and Google let you purge one name from their public resolvers.

Why do I see the new site but my colleague sees the old one?

You use different resolvers, and theirs still has the old answer cached. It updates when that copy’s TTL runs out.

DNS Propagation Explained: How to Check It

Q: How long does DNS propagation take?

Up to the old record’s TTL for ordinary records, often 5 minutes to an hour. Nameserver changes at the registrar can take up to 48 hours, since parent zones such as .com cache NS records that long.

DNS propagation is the time between changing a DNS record and everyone seeing the new value. Nothing is actually pushed out: resolvers around the internet keep serving the copy they cached until its TTL (time to live) runs out, then ask again. Most record changes are seen everywhere within the old record’s TTL, often minutes to an hour. Nameserver changes at the registrar can take up to two days. To check where a change stands, ask the domain’s own nameservers what they publish, then ask a few public resolvers what they still have cached.

What happens when you change a record

A visitor’s browser doesn’t ask your DNS provider directly. The question passes through several caches, and each one may answer from memory:

The browser keeps recent answers for a short while.
The operating system has its own resolver cache.
A recursive resolver at the ISP, the company network or a public service such as 1.1.1.1 or 8.8.8.8 caches each answer for as long as its TTL allows.
The authoritative nameservers for your domain hold the real records. Only they know about your change at first.

When you save a change at your DNS provider, the authoritative nameservers usually serve it within seconds or minutes. Every cache further down keeps the old answer until its copy expires. Two visitors on different networks can therefore see different servers for a while, and that is normal, not an error. The TTL is set per record, in seconds, by you; the glossary entry on DNS propagation has the short version.

How long DNS propagation takes

Ordinary records: the old TTL

For an A, AAAA, CNAME, MX or TXT record, the longest wait is the TTL the old record had when resolvers cached it. A record with a TTL of 3600 can be served from cache for up to an hour after you change it. Lowering the TTL at the same moment as the change doesn’t help, because resolvers that already hold the old copy keep it for the old TTL.

Nameserver changes: the parent zone

Moving a domain to another DNS provider means changing its NS records at the registrar. Those are published in the parent zone, such as .com, and the parent sets their TTL, not you. You can see it yourself by asking a .com server directly:

dig +norecurse @a.gtld-servers.net example.com NS

The answer lists the nameservers with a TTL of 172800 seconds, which is 48 hours. That is where the “up to 48 hours” advice comes from. During that time some resolvers ask the old provider and some the new one, so both must serve the same records until the change has settled.

New names: negative caching

If someone looked up a name before it existed, for example a new subdomain you tested too early, resolvers may cache the “no such name” answer too. RFC 2308 sets how long: the lower of the SOA record’s minimum field and the SOA record’s own TTL. That is why a brand-new subdomain can show DNS_PROBE_FINISHED_NXDOMAIN for a while on one network and work on another.

Applications that hold on to addresses

A long-running program, such as an application server or a proxy, may resolve a hostname once when it starts and keep the address until it restarts, whatever the TTL says. If one service still talks to the old server after everyone else has moved, restart it before you suspect DNS.

How to check DNS propagation

Work from the source outward. First confirm that the change is published, then see which caches still have the old answer.

1. Find the authoritative nameservers

dig NS example.com +short

If these aren’t the nameservers of the provider where you made the change, you edited the wrong zone. That is a common reason a change “never propagates”.

2. Ask each nameserver directly

dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short

Repeat for every nameserver in the list. They should all return the new value and the same SOA serial number, the third field of the SOA answer. A server with an older serial hasn’t received the update yet; that is propagation inside your provider, and it usually settles within minutes.

3. Ask public resolvers

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Without +short, dig shows the TTL in each answer. From a resolver, that number is the time left on its cached copy: an old value with 1200 seconds left will be replaced within 20 minutes. On Windows, nslookup -type=A example.com 1.1.1.1 asks a specific resolver, without the TTL. Our free DNS lookup shows the answers and TTLs for any record type from our server’s resolver in Stockholm, without installing anything.

4. Follow the delegation after a nameserver move

dig +trace example.com

+trace starts at the root and follows the referrals down to your nameservers, ignoring caches on the way. If the trace ends at the new provider, the registrar change is live, and what remains is caches catching up.

Plan a change so propagation doesn’t hurt

You can’t speed up propagation after a change, but you can make it short before you start. For a move to a new server:

When	Step
At least one old TTL before	Lower the record’s TTL, for example from 3600 to 300 seconds.
Before the change	Set up the new server and test it, for example with a hosts file entry or `curl --resolve`.
The change	Point the record at the new server and check the authoritative answer.
During propagation	Keep the old server running and serving the same content. Some visitors still reach it.
A day or so later	Raise the TTL again and switch off the old server.

For a nameserver move, copy every record to the new provider first and compare the two zones record by record, MX and TXT included. A forgotten TXT record breaks email authentication; the SPF, DKIM and DMARC checker shows whether it still passes. If the domain uses DNSSEC, follow the new provider’s steps for the DS record at the registrar, since a DS record that doesn’t match the new nameservers makes validating resolvers answer SERVFAIL.

Clearing caches you control

You can clear your own caches to see the new value sooner, which helps when you test. It changes nothing for your visitors.

macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: open chrome://net-internals/#dns and clear the host cache.
Public resolvers: Cloudflare and Google let you purge one name from their caches, at 1.1.1.1’s purge page and Google Public DNS’s flush page.

Your ISP’s resolver and those of your visitors can’t be cleared from outside. They expire on their own schedule.

When it isn’t propagation

If the authoritative nameservers still return the old value, waiting won’t help. Look for one of these instead:

The wrong zone or provider. The record was changed at a provider the domain no longer uses.
The wrong name. The apex (example.com) and www.example.com are separate records.
A proxy in front. With a CDN or proxy enabled for the record, public DNS returns the proxy’s addresses, not your server’s, by design.
A record that never saved, or a typo in the value. Compare what you see in the provider’s panel with the dig answer.

The DNS record types entry explains what each record does, and the website down checklist covers the steps after DNS.

Know when a record changes with Uptimecheck

Propagation is the planned kind of DNS change. The unplanned kind, a typo during a migration or a hijacked registrar account, is the one worth an alert. Uptimecheck DNS monitoring watches A, AAAA, CNAME, MX, NS, SOA, TXT and CAA records:

It asks the domain’s authoritative nameservers directly, so a change shows at the next check, with no resolver cache in between. When the nameservers give different answers, the monitor page says so.
A new set of records is alerted once two checks in a row have seen it, with the old and new values, and kept in the record’s history.
Enter the values you expect, and the check fails whenever the published records don’t match them, which also confirms that a planned change went live.
Checks run as often as every minute. Start includes 10 DNS monitors, Professional 25 and Business 150.

Pair it with uptime checks on the site itself and domain expiry monitoring. To set one up, see how to set up DNS monitoring, and read how to detect hijacked DNS records for the warning signs.

Know the moment your records change. Try Uptimecheck free for 14 days, no credit card required.

DNS Propagation: Why Changes Take Time and How to Check