After you change a website address, email provider or hosting service, one person may see the new service while another still reaches the old one. That uneven period is commonly called DNS propagation. For a small business, it can mean customers reaching an old site, mail going to the wrong system, or a launch appearing broken on some connections.
DNS changes are not pushed to every device at once. Your authoritative nameservers publish the current records. Recursive resolvers operated by internet providers, workplace networks or public DNS services look them up for users and keep copies in cache. The original DNS design in RFC 1034 uses distributed data and local caching rather than one instantly synchronised database.
When a resolver has an unexpired answer, it can return that value without asking your authoritative nameserver again. Another resolver may have no cached copy and fetch the new answer immediately. This is why a change can work on office internet but not on mobile data. Cloudflare's resolver documentation confirms that a recursive service contacts authoritative nameservers when its cache has no answer.
Each DNS record has a time to live, or TTL, expressed in seconds. It tells resolvers how long they may cache that answer. A longer TTL improves the chance of a fast cached response, while also making later changes slower to appear. That trade-off is explained in Cloudflare's TTL reference.
The important value is the TTL attached to the old answer before you edit it. Lowering the TTL at the same moment as the destination will not shorten copies already cached under the previous, longer value. If a change is planned, reduce the relevant TTL at least one existing TTL period beforehand. Once the move is stable, return it to your normal setting rather than leaving an unusually short TTL indefinitely.
Propagation is often blamed for configuration errors. If the authoritative nameserver already returns the wrong value, waiting only preserves the mistake. A missing record, CNAME conflict, incorrect MX priority, stale AAAA record, broken DNSSEC chain, or disagreement between authoritative nameservers needs correction. Also remember that browser, operating system, router and application caches can sit in front of the recursive resolver. Clearing one local cache may help your test, but it does not refresh caches used by customers.
Ask for help before the change if you cannot identify the authoritative DNS provider, do not know which records belong to website or email services, are changing nameservers, or have DNSSEC enabled. Contact support promptly if authoritative servers disagree, queries return SERVFAIL, email stops flowing, HTTPS fails at the new address, or different results remain after the previous TTL should have expired. Provide the domain, record type, expected value, time changed and test results from more than one network.
If you want domain management backed by an Australian team, review Hosting Australia's domain registration and transfer options.
A sound DNS change assumes a temporary overlap between old and new answers. Lower the TTL in advance, prepare both destinations, verify every affected record type and keep a rollback path. That turns propagation from an unpredictable outage risk into a controlled transition your business can test and monitor.
