Quick definition
DNS propagation is the period after a DNS change when some visitors still get the old answer. Nothing is pushed out: resolvers keep cached records until each record's TTL expires, then fetch the new value.
When you change a DNS record, for example to point your website at a new server, the change takes effect right away on your DNS provider's authoritative nameservers. Yet for a while some people reach the old server and others reach the new one. That in-between period is what people call "DNS propagation."
The name is a little misleading. Nothing is broadcast or pushed across the internet. The delay comes from caching.
How caching causes the delay
Most devices do not ask your authoritative nameservers directly. They ask a recursive resolver, usually run by an internet provider, a company network or a public DNS service. The resolver looks up the answer once and keeps it in its cache so it can answer the next request quickly.
Every DNS record carries a TTL (time to live): the number of seconds a resolver may cache it before discarding it. If your A record has a TTL of 3,600, a resolver that looked it up just before your change can keep handing out the old address for up to an hour. A resolver whose cached copy had already expired fetches the new address on its next lookup.
So "propagation" is really many independent caches expiring on their own schedules. Operating systems and some applications keep their own caches as well, which is why one device can lag behind another on the same network.
Changes that can take longer
- Nameserver changes. Switching DNS providers means changing the nameservers listed for your domain at the registrar, which updates the delegation in the parent zone, such as .com. Resolvers cache that delegation using a TTL set by the registry rather than by you, so a nameserver move can take longer to settle than an ordinary record change, and you cannot shorten it in advance.
- Names that did not exist before. If someone looked up a name before you created it, resolvers may cache the "no such record" answer. Under RFC 2308, that negative answer is cached for the lower of the zone's SOA record TTL and its SOA MINIMUM value.
Why online checkers disagree
Propagation checkers query resolvers in different places and show what each one has cached. Mixed results during the TTL window are normal and do not mean something is broken. The answer that matters is the one your authoritative nameservers return.
Limitations
You cannot clear other organizations' caches. The main lever you control is the TTL on your records, and it only helps if you lower it far enough ahead of the change for the old, longer-lived copies to expire.
A practical example
An online booking site plans to move to a new server on Saturday morning. Its main A record has a TTL of 86,400 seconds (24 hours). Changed without preparation, some customers could keep reaching the old server, and making bookings on it, for up to a day.
Instead, on Thursday the team lowers the TTL to 300 seconds (five minutes). By Saturday every copy cached under the old 24-hour TTL has expired. They switch the record, keep the old server running in read-only mode for an hour as a safety net, then raise the TTL again once traffic has moved.
Why it matters
DNS decides where your website, email and other online services are found. During a migration, two servers may receive traffic at once: orders can land on the old system, email can be delivered to the old mail server, and customers can see an outdated site. Understanding caching lets you plan changes so this window lasts minutes rather than a day, and keeps you from relying on emergency DNS changes that cannot take effect quickly.
Common mistakes
- Lowering the TTL at the same moment as the change. Resolvers that already cached the record keep it for the old TTL. Lower it at least one full old-TTL period in advance.
- Shutting down the old server immediately. Keep it running until the old TTL has passed, or visitors with cached answers reach a dead server.
- Forgetting email records. A website move often touches MX, SPF and other records too. Missing one can interrupt email even when the website works.
- Editing DNS at the wrong provider. Changes only matter at the provider your domain's nameservers point to.
- Trusting a checker over the source. Query your authoritative nameservers directly to confirm the change is published correctly.
- Leaving very short TTLs in place permanently. Short TTLs mean more lookups against your DNS provider. Raise them again once a change has settled.
Why two people see different answers
At 10:00 a record on the authoritative nameserver is changed from the old address 203.0.113.10 to the new address 198.51.100.20. The record's TTL is 3,600 seconds (one hour). Resolver A cached the old answer at 9:50, so it keeps serving the old address until 10:50 and its users reach the old server until then. Resolver B cached the old answer at 8:30; that copy expired at 9:30, so when it is asked again at 10:05 it fetches the new address and its users reach the new server straight away. Nothing is pushed out: each resolver picks up the change only when its cached copy's TTL runs out.
Record change vs. nameserver change
| Changing a DNS record | Changing nameservers | |
|---|---|---|
| Where you make it | In the zone at your DNS provider | At your domain registrar |
| What controls the delay | The TTL of the record you changed | The delegation TTL set by the registry, plus cached records from the old provider |
| Can you shorten it in advance? | Yes, by lowering the record's TTL | Not the registry's delegation TTL |
| Main risk | Some visitors briefly reach the old server | Old and new providers answer differently if their records do not match |
Frequently asked questions
How long does DNS propagation take?
For an ordinary record change, up to the TTL that record had before the change, which is often between a few minutes and a day. Nameserver changes can take longer, because they also depend on TTLs set by the domain's registry.
Can I speed up DNS propagation?
Only before the change, by lowering the TTL ahead of time. After the change you cannot clear other networks' caches, although you can clear the cache on your own computer or browser to see the new answer sooner.
Why does my site work on my phone but not on my laptop?
The two devices are probably using different resolvers, for example mobile data versus office Wi-Fi, or one device still has the old answer in its local cache. Both will see the change once their cached copies expire.
Sources
- RFC 1035: Domain Names - Implementation and Specification, RFC Editor (IETF) (accessed November 9, 2026)
- RFC 2308: Negative Caching of DNS Queries (DNS NCACHE), RFC Editor (IETF) (accessed November 9, 2026)