DNS Basics
What DNS Propagation Means and Why Changes Aren't Instant
Why a DNS update doesn't reach every visitor at once, how TTL and resolver caching cause the delay, and how to check where a change actually stands.
0-48h
Typical range for full global DNS propagation
TTL
The setting that determines how long resolvers cache an answer
24/7
Human support for propagation and DNS timing questions
Free
DNS management included with hosting
In short
DNS propagation is the term for the delay between changing a DNS record and that change being visible to every visitor worldwide, caused by resolvers (run by ISPs, corporate networks, and public services) caching the previous answer for as long as its TTL (time to live) allows before checking again. There's no single global 'push' — each resolver independently decides when to re-fetch.
In practice this usually means anywhere from a few minutes to 48 hours, with most resolvers catching up within a few hours for a typical TTL, though some caches can hold on longer regardless of what the TTL says.
A DNS record change looks instant from inside the control panel where it was made — the new value saves immediately. But that panel only controls the authoritative record; it has no direct control over the thousands of independent resolvers scattered across ISPs, offices, and devices worldwide that are each caching their own copy of the old answer.
This guide explains what's actually happening during that gap, why TTL settings matter so much for how long it lasts, and how to check propagation status honestly rather than assuming a site is broken just because one particular network hasn't caught up yet.
Why There's No Single Moment DNS 'Updates'
DNS is a distributed system with no central switch. When a record changes at the authoritative nameserver, that new value is available immediately to anyone who asks fresh — but most lookups don't go straight to the authoritative source every time, since that would be needlessly slow. Instead, resolvers along the way (an ISP's DNS servers, a corporate network's internal resolver, a public resolver like a well-known 8.8.8.8-style service) cache the answer and reuse it.
Each of those resolvers independently decides when its cached copy has expired and it's time to check again, based on the TTL the record specified the last time it was fetched. That's why two people on different networks, checking the same domain at the same moment, can genuinely see two different results during a propagation window — neither is wrong, they're just looking at different caches.
How TTL Controls the Length of the Delay
TTL (time to live) is a number, in seconds, attached to every DNS record specifying how long a resolver is allowed to treat its cached copy as valid before re-checking. A record with a TTL of 3600 tells resolvers they can reuse the cached answer for up to an hour; a TTL of 300 shortens that window to five minutes.
The practical implication: lowering a record's TTL well before a planned change (a migration, for example) shortens how long the old value can linger in caches once the change actually happens. This has to be done in advance, though — lowering the TTL at the same moment as the change doesn't help, since resolvers are still working off whatever TTL was in effect the last time they fetched the record.
Why Some Resolvers Seem to Ignore TTL Anyway
TTL is a guideline resolvers are expected to respect, but it isn't a strict global guarantee enforced by anyone. Some corporate networks, public Wi-Fi systems, or heavily cached resolver software occasionally hold onto an old answer longer than the TTL technically allows, whether due to aggressive caching settings, outdated software, or simple misconfiguration on their end.
This is the main reason propagation estimates are always ranges rather than exact numbers — the overwhelming majority of resolvers behave correctly and refresh on schedule, but a small number of outliers can make it seem like a change 'isn't working' for one specific visitor or network well after most of the internet has already updated.
Checking Propagation Status Properly
Rather than relying on a single device or network, a global DNS propagation checker queries resolvers in multiple regions simultaneously and shows the current answer each one returns, giving a realistic picture of how far a change has actually spread rather than one anecdotal data point. Seeing the new value returned in most regions, with a few stragglers still on the old one, is entirely normal mid-propagation.
It's also worth checking the record directly against the authoritative nameserver (bypassing cache entirely), which confirms the change was actually saved correctly at the source — useful for ruling out a typo or a save that didn't take, as opposed to a delay that's simply still working itself out across caches.
DNS Changes Handled With the Timing Explained Upfront
Hosting Cheap's DNS panel shows current TTL values clearly, so a planned migration or record change can be timed with a lowered TTL in advance rather than guessing why a change hasn't shown up everywhere yet.
Free managed migration accounts for propagation timing as part of the move, keeping the transition smooth rather than leaving visitors to land unpredictably on old or new infrastructure mid-change.
- DNS panel with visible, editable TTL values
- Free managed migration timed around DNS propagation
- 24/7 human support for propagation status questions
- Daily backups in place during any DNS or hosting transition
Why Hosting Cheap
What you get
Visible TTL Controls
Lower a record's TTL in advance of a planned change to shorten the propagation window.
Free Managed Migration
DNS changes during a move are planned with propagation timing already accounted for.
24/7 Human Support
Get a clear answer on whether a slow-to-update record is a caching delay or a real error.
Daily Backups
A safety net while DNS changes are still working their way across global resolvers.
Free Auto-Renewing SSL
Stays valid and ready the moment DNS finishes pointing traffic at the new server.
Pure NVMe SSD + LiteSpeed
The destination server is fast and ready the instant each resolver catches up.
How It Works
Get set up in a few steps
Lower the TTL in advance
For a planned change, reduce the record's TTL a day or more ahead of time so old caches expire faster.
Make the DNS change
Update the record once the shortened TTL window has had time to take effect across resolvers.
Check propagation globally
Use a multi-region DNS lookup tool rather than a single device to see real spread of the update.
Included
Everything you need, on every plan
- TTL lowered well in advance of any planned DNS change
- Record change confirmed saved correctly at the authoritative nameserver
- Propagation checked using a multi-region tool, not a single network
- Old value expected to linger briefly on some networks even after most have updated
- TTL restored to a normal, higher value once the change has fully settled
- Local DNS cache cleared on the device being used to test the change
FAQ
Frequently asked questions
How long does DNS propagation usually take?
Most resolvers catch up within a few hours, though the full range is commonly cited as anywhere from a few minutes up to 48 hours depending on the record's TTL and how individual networks cache.
Can I speed up DNS propagation?
The only real lever is lowering the TTL before making the change, which shortens how long resolvers are allowed to hold onto the old cached answer. There's no way to force propagation faster after the change has already been made.
Why does the DNS change work on my phone but not my laptop?
Different devices and networks query different resolvers, each with its own cache and refresh schedule, so it's normal for one to show the new value before another. Clearing the local DNS cache on the lagging device often resolves it faster than waiting.
Does DNS propagation affect email as well as websites?
Yes, any record type — A, MX, TXT, CNAME — is subject to the same caching and TTL behavior, so an MX record change for email follows the identical propagation pattern as a website's A record change.
Is DNS propagation the same everywhere in the world?
No, propagation speed varies by region and by which resolvers a given network uses, which is exactly why a multi-region DNS lookup tool is more useful than checking from a single location.
Should I panic if my site shows old content the day after a DNS change?
Not necessarily — while most resolvers update within hours, a small number of networks occasionally hold cached answers longer than expected. Checking a multi-region propagation tool clarifies whether it's genuinely still spreading or whether something else needs fixing.
Plan DNS Changes Without the Guesswork
Editable TTLs and migrations timed around propagation keep changes predictable instead of confusing.
Get Started