DNS Propagation Explained: How TTL Works and How to Check Changes

You change an A record, a nameserver or an email record, and the confusion starts. Your laptop shows the new site, your phone shows the old one, a colleague sees an error, and the advice online is "wait up to 48 hours". That makes DNS propagation sound like a process that spreads your change around the world. It is not. Nothing is pushed anywhere. You are waiting for many separate caches to run out of time.

This guide explains what DNS propagation really is, how TTL (time to live) sets the clock, why some people see old answers for longer than others, and how to prepare a change so the wait is short. It then shows how to check your DNS host and public resolvers one by one, so you can tell "not there yet" from "I made a mistake". It is for site owners and developers about to move a website, change hosts or switch email.

Short answer: DNS propagation is the time it takes for resolvers to stop serving a cached copy of an old DNS answer. Nothing is pushed out. Each cache keeps a record for the TTL it was given, so a change becomes visible when the old TTL runs out, and lowering the TTL beforehand shortens that wait.

Before you begin

You need access to wherever your DNS is hosted (often not the registrar), a terminal with dig or, on Windows, nslookup, and a list of the records you plan to change. Record the current values and TTLs first, including the nameservers. If you are moving a website, keep the old server running until the move is verified, and read DNS Records Explained: A, AAAA, CNAME, MX and TXT for what each record does.

The risk is timing: a wrong record that gets cached stays visible until its TTL ends. Make one change at a time.

What does DNS propagation actually mean?

A DNS answer passes through several layers on the way to a visitor. RFC 9499, the DNS terminology document, describes the main players: an authoritative server holds the zone's contents and answers for it, a recursive resolver looks answers up for clients and is expected to cache them, and a stub resolver (built into your device) relies on a recursive resolver.

Layer	Who runs it	Where the cache is
Authoritative servers	Your DNS host	None: this is the source of truth.
Recursive resolver	Your ISP, your employer, or a public service	Large, shared by many users.
Operating system and apps	The visitor's device	Small, per device.

When you edit a record, only the authoritative servers change at once. Every other layer keeps whatever it already holds until it expires. "Propagation" is the word for those expiry times passing, resolver by resolver, which is why different people see different answers at the same minute.

How does TTL decide how long the old answer lasts?

TTL is the time-to-live value attached to each record, in seconds. RFC 9499 describes it as the time interval for which a record may be cached before the source is consulted again, and says a cache operator may shorten it.

Imagine an A record with a TTL of 3600 seconds (one hour), changed at 10:00:

Time	What happens
09:30	Resolver A looks the record up and caches the old IP for one hour.
10:00	You publish the new IP at your DNS host.
10:10	Resolver B has nothing cached, asks the authoritative server and gets the new IP at once.
10:30	Resolver A's copy expires. Its next lookup fetches the new IP.

The worst case is a resolver that cached the old answer a moment before your change: it keeps serving it for nearly the full old TTL. That is also why lowering a TTL after a change does nothing for caches that already hold the old value. The lower number only helps once the previous, longer TTL has expired. Lower it at least one full old TTL before you switch.

TTL (seconds)	In human time	Typical use
300	5 minutes	Records you are about to change.
3600	1 hour	A common general-purpose value.
86400	1 day	Stable records you rarely touch.

Short TTLs make changes quick and cost more lookups; long TTLs reduce lookups and slow every change. Providers may limit the range you can choose, so check your DNS host's minimum and maximum.

Why do some people still see the old answer?

If the old TTL has not passed, the answer is simply the cache working as designed. When it has passed and someone still sees the old value, look for one of these:

A device cache. Your own machine caches too. On Windows, ipconfig /displaydns shows the resolver cache and ipconfig /flushdns clears it.
A negative cache. If a name did not exist when someone looked, that answer was cached too. RFC 2308 says NXDOMAIN and NODATA answers should be cached, with a lifetime taken from the zone's SOA record, and that values of one to three hours have been found to work well while values above a day have been found problematic. Visiting new.example.com before you have created it can therefore make it look broken for a while after you add it.
A resolver that serves stale data. RFC 8767 allows a recursive resolver to use expired data when it cannot refresh it from the authoritative servers, and suggests a maximum stale time of one to three days. This only applies when the authoritative servers cannot be reached.
Authoritative servers that disagree. If one of your nameservers still holds the old zone, some lookups will return old data no matter how long you wait. Google's Public DNS troubleshooting guidance suggests comparing the SOA serial numbers of the servers: different serials suggest a server is serving stale data, which only the DNS operator can fix.

There is no single official number for "how long propagation takes". The upper bound for an ordinary record change is the old TTL, plus unusual cases such as the ones above. Resolvers may also cut lifetimes short: Google Public DNS says its cache lifetimes are generally limited to six hours even when the TTL is longer, but a long TTL is no reason to expect an early change.

Is changing nameservers different from changing a record?

Yes. A record change edits data inside your zone. A nameserver change edits the delegation: the NS records in the parent zone, which tell resolvers where your zone lives. RFC 9499 defines delegation as created when an NS record set is added in the parent zone. Your registrar publishes those records into the parent zone, so you may not control their TTL. This guide gives no hour count because it depends on the parent zone; check your registrar's wording and allow longer than for a record edit. If the move changes the domain name itself, also read Change a Domain Name Without Losing SEO. Google's Public DNS FAQ also says that after changing nameservers you should flush the main domain before its subdomains.

Step-by-step instructions

Step 1: Record the current state

Capture what exists before you change it:

dig +noall +answer example.com A
# example.com.  3600  IN  A  203.0.113.10
dig +noall +answer example.com NS
dig +nssearch example.com

+noall +answer prints name, type, TTL and value for each record. +nssearch finds the zone's authoritative nameservers and shows the SOA record each returns, so you can see their serial numbers. On Windows, nslookup -type=A example.com shows the address.

What success looks like: You have saved the current values, TTLs and nameservers.

Step 2: Lower the TTL before the move

Set the TTL on the records you will change to something short your DNS host allows, such as 300 seconds. Then wait at least as long as the old TTL, so every cache has dropped the old, longer entry. If the old TTL was one day, change it a day or more before the move.

What success looks like: A lookup from a public resolver reports the short TTL, and the old TTL's worth of time has passed.

Step 3: Make the change at the authoritative servers

Edit the record, then ask the authoritative servers directly, bypassing every cache:

dig +short @ns1.dns-host.example example.com A
dig +nssearch example.com

The first line asks one authoritative server by name. Replace the name with one from your NS list. All of them should return the new value, and +nssearch should show the same SOA serial everywhere. If one differs, wait for the sync or ask your DNS host.

What success looks like: Every authoritative server returns the new value.

Step 4: Compare public resolvers

Ask different recursive resolvers the same question:

dig +noall +answer @8.8.8.8 example.com A
dig +noall +answer @1.1.1.1 example.com A

Read the results with this table:

Authoritative answer	Resolver answer	Meaning
New	New	That resolver has caught up.
New	Old	It is still within the old TTL or a negative or stale entry. Wait and retry.
Old	Old	The change did not publish, or one nameserver is out of sync. Recheck your DNS host.

Repeat the query a minute later. A caching resolver often reports a smaller remaining TTL each time, which shows the answer is coming from its cache. Web-based "propagation checker" sites query a selection of resolvers and can help, but cannot see every cache.

What success looks like: You can tell, resolver by resolver, whether the difference is waiting or a mistake.

Step 5: Clear the caches you control

Clearing a cache does not speed anyone else's; it only lets you test cleanly.

Windows: ipconfig /flushdns.
Linux with systemd-resolved: resolvectl flush-caches.
Google Public DNS: its Flush Cache tool refreshes cached answers for common record types and most domain names. It needs a reCAPTCHA but not proof of ownership. After a nameserver change, flush the main domain before subdomains. Domains using EDNS Client Subnet cannot be flushed, and Google recommends TTLs of 15 minutes or less for them.

Other operating systems and browsers have their own commands, so check their documentation.

What success looks like: Your own machine and Google's public resolver both return the new answer.

Step 6: Verify the service, not just the record

Open the site from a phone on mobile data, send a test email if you changed MX records, and confirm the certificate matches the new host. Copy any verification TXT records to the new DNS host, so ownership checks such as Search Console verification keep working. Keep the old server answering until its access log shows traffic has stopped. If you must pause the site during the move, use a proper 503, as described in 503 Service Unavailable Maintenance Mode. If you also changed URLs, follow the checks in Website Migration SEO Checklist and Pre-Launch QA: From Staging to Production.

What success looks like: The site and mail work from at least two networks, and the old server sees no more visitors.

Step 7: Raise the TTL again and keep watching

After everything is stable, set the TTL back to a longer value such as 3600 seconds, to cut lookups. Keep an eye on DNS during the first days: Search Console's Crawl Stats Host status includes a DNS resolution measure, and Google handles a DNS failure while fetching robots.txt like a server error. If visitors report errors, HTTP Status Codes Explained for SEO helps you read what the server is returning. An uptime monitor gives faster warning; see Website Uptime Monitoring. Crawvix's "Domain resolves" check reports a failure when a domain returns NXDOMAIN or has no A or AAAA record, and its nameserver check looks for at least two.

What success looks like: The TTL is back at a normal value, and no DNS problem has appeared in monitoring or Search Console.

Final verification checklist

Old records, TTLs and nameservers were saved before the change.
The TTL was lowered at least one old TTL before the move.
Every authoritative nameserver returns the new value and the same SOA serial.
Public resolvers such as 8.8.8.8 and 1.1.1.1 return the new value.
The website and email work from at least two different networks.
The old server stayed up until its traffic stopped.
The TTL was raised again after the move was stable.
DNS monitoring shows no resolution failures after the change.

Common mistakes to avoid

Lowering the TTL at the last minute. Caches already holding the old value ignore the new number until the old TTL ends.
Waiting without checking the authoritative servers. If the change never published, no wait will fix it.
Visiting a hostname before creating it. The "does not exist" answer can be cached.
Switching off the old server immediately. Visitors with cached answers still arrive there.
Changing nameservers and records together. Do one, verify, then the other.

Frequently asked questions

How long does DNS propagation take?

There is no single official figure. For a normal record change, the upper bound is the old TTL, so a one-hour TTL means about an hour, and a one-day TTL means up to a day. Nameserver changes depend on the parent zone, so allow longer.

Does DNS propagation affect my SEO?

Not directly. What matters is whether crawlers and visitors can resolve your hostname: Google treats failures such as DNS problems on robots.txt as server errors. A well-prepared change avoids downtime, which is what this guide is for.

Can I speed up DNS propagation?

Not for other people's caches. You can lower the TTL ahead of time, and flush your own caches and Google Public DNS for testing, but you cannot flush every resolver in the world.

Should I keep a low TTL permanently?

Usually not. A short TTL means faster changes but more lookups. Use it around planned changes, then raise it.

Why does my site work on my phone but not my laptop?

They are probably using different resolvers or different caches, and one still holds the old or negative answer. Flush the laptop cache and compare dig results from both resolvers.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.