DNS propagation is the lag between saving a DNS change in your panel and the rest of the internet answering with that new data. Resolvers normally reuse cached answers for their TTL (time to live), with exceptions such as negative caching and serving stale data during some failures. There is no single global flip. Some networks update in minutes; others keep the old A, MX, or NS for hours.
Check what the site’s server resolver returns with FindMyIP’s DNS Lookup. This post is about timing and caches — not how to decode every record type (see how to read DNS lookup results for that).
What actually propagates
When you edit DNS, you change the authoritative answer on the nameservers that own the zone. Recursive resolvers can reuse a cached answer instead of asking again immediately. Their cache state may differ from the authoritative nameservers and from the resolver used by another device.
So “propagation” is mostly cache expiry, not a file copying itself around the planet. People still use the word; the useful mental model is TTL + which resolver you asked.
TTL in plain English
Each record carries a TTL in seconds (often 300, 3600, or 86400).
- Low TTL (for example 300) — caches forget sooner; changes show up faster; more DNS queries
- High TTL (for example 86400) — fewer lookups; a bad or old answer can stick for a day
Before a planned cutover, operators often lower TTL a day ahead, wait for old high TTLs to die, make the change, then raise TTL again. If you change a record that still has a long TTL from yesterday, expect long waits even if the panel looks correct.
Propagation is not a fixed “24–48 hours” law. Negative caching also applies to some missing-name answers, and serve-stale behavior can temporarily retain answers beyond their TTL during failures. That phrase is a worst-case habit from eras of long TTLs and slow registrars. The relevant record and delegation TTLs, negative caches, provider publication delays and resolver behavior all affect the wait. Use a TTL plan before changing providers to prepare rather than relying on a universal countdown.
Why your laptop and your phone disagree
Different devices use different resolvers:
- Home Wi‑Fi often uses the ISP’s resolver
- Phones on cellular use the carrier’s
- Some browsers or OS settings use encrypted DNS to a third party
- VPNs may force their own DNS
Each cache has its own clock. One path can show the new A record while another still serves the old IP. That is normal during a change window — not proof you edited the wrong panel (though editing the wrong nameservers is still a common separate bug; confirm NS first).
How to check without guessing
- Confirm you edited the DNS host that NS points to (wrong panel = “never propagates”).
- Note the TTL in your DNS provider’s settings. FindMyIP does not display ordinary record TTLs.
- Query with DNS Lookup for the exact name (
example.comvswww.example.com). - Compare apex and
wwwif both matter. - For a real resolver comparison, use a query tool that explicitly selects different recursive resolvers, and record each resolver and time. Opening FindMyIP from another network still queries through this site’s server; it does not reliably compare the visitors’ resolvers.
- For mail cutovers, watch MX (and related TXT) the same way — web A records can be live while mail still follows the old MX.
A new value proves only that the particular query returned it at that time. Compare the authoritative answer and selected recursive resolvers when investigating disagreement; do not infer global completion from repeated visits to one web tool.
Common myths
- “It always takes 48 hours.” There is no universal deadline; inspect the relevant caching and provider behavior.
- “Flushing my browser cache fixes DNS.” Browser cache ≠ resolver cache. OS/resolver flush tools help locally; they do not rewrite the world’s ISPs.
- “Propagation failed.” Often the change is not on the authoritative nameservers yet, or you are looking up a different hostname than you edited.
- “HTTPS errors mean DNS is not ready.” Certificates can fail after DNS already points at the new host. Get the IP right first; fix TLS second.
When records look correct but the site fails
A new A or AAAA answer only points a client toward a server. That server still needs the correct site, certificate and application configuration. Diagnose a site that still will not load before changing more DNS records. A public-IP lookup describes your connection; it cannot establish whether a domain’s migration is complete.
Privacy note (short)
Public DNS lookups show how a domain is configured. Your own browsing resolver path is separate: default DNS often goes through your network operator. Encrypted DNS or a VPN can change who sees those queries. For verifying a domain change, DNS Lookup is the right tool; to see your connection’s visible address after a VPN, use What Is My IP.
Record which answer you checked
DNS propagation is cache expiry guided by TTL, not magic worldwide sync. Lower TTL before big moves when you can, edit the nameservers that actually answer, then verify with repeated lookups until the new records stick. When answers still look alien, decode them with the DNS record guide — timing and meaning are two different jobs.