The new site opens on your phone. Your colleague still sees yesterday’s version. Before changing the address again, work out which layer is returning the old information.
Names and cached answers
DNS resolvers can remember answers for a period governed by a record’s time to live, or TTL. A resolver with a still-valid cached answer may continue returning the previous address after the authoritative record changes.
There is no single moment when every cache worldwide refreshes together. Reducing a TTL after an old answer has already been cached does not retroactively shorten that earlier cached lifetime.
The page itself may also be cached
Getting the current server address does not guarantee receiving newly generated content. A browser or a content delivery layer may still reuse a stored response.
Write down what differs: the resolved address, the page content or both. Calling every delay “DNS propagation” can send you toward the wrong fix.
Change one thing at a time
As a site owner, compare the authoritative DNS answer with the resolver used by the affected visitor. Then check the expected content at the destination and the HTTP caching rules.
Avoid repeatedly editing records while waiting. Each additional change makes it harder to reconstruct which version a visitor received and why.
Plan a move with overlap
Before a planned migration, review TTL values and allow existing cache lifetimes to pass after any advance adjustment. Keep the previous destination usable during the transition when your setup allows it.
For a visitor, a forced refresh can test a browser-cache issue, but it does not clear every network cache. Give support the exact address, approximate time and what you see. Those details help distinguish a delayed change from an unrelated fault.