You updated a DNS record. The change shows up on your computer immediately. Your colleague in another country still sees the old site. Two hours later, a third person reports they're seeing the new version. A day later, everything looks consistent.
This is DNS propagation. Understanding what's actually happening makes it less frustrating — and knowing which variables you control can shorten the wait significantly.
What DNS does and why changes don't apply instantly
DNS — the Domain Name System — maps domain names to the IP addresses that servers actually run on. When you type example.com into a browser, a DNS resolver translates that name into an IP address before the browser knows where to connect.
That lookup doesn't go directly to your registrar every time. It goes to a recursive resolver — a server operated by your ISP, your employer's network, or a public provider like Google (8.8.8.8) or Cloudflare (1.1.1.1). The resolver caches the answer it gets from the authoritative nameserver. Once it has the answer cached, it returns the cached version to every device on its network — until the cache expires.
When you update a DNS record at your registrar or DNS host, the authoritative nameserver immediately has the new record. But every resolver on the internet that already cached the old record still has the old data. They will keep using it until the cache entry expires. That is what propagation is: waiting for caches around the world to expire and fetch the fresh record.
TTL: the number that controls propagation speed
Every DNS record carries a TTL (time-to-live) value, measured in seconds. TTL tells resolvers how long they are allowed to cache the record before they must fetch a fresh copy from the authoritative nameserver.
A TTL of 3600 means resolvers cache the record for one hour. After an hour, they fetch a new copy. A TTL of 300 means caches expire every five minutes. A TTL of 86400 means resolvers can hold the record for 24 hours before refreshing.
The most common default is 3600 (one hour) or 14400 (four hours), depending on the DNS provider. Many shared hosting setups leave TTL at 86400 — meaning every resolver on the internet could hold a cached copy for up to 24 hours after you make a change.
TTL is the one propagation variable you control before you make a change. If you lower the TTL to 300 (five minutes) several hours before a DNS change, resolvers that refresh during that window will pick up your new record within five minutes of the change going live. This is standard practice before any planned migration: lower TTL first, wait at least one full old-TTL cycle to ensure old long-lived cache entries have expired and been refreshed at the new TTL, then make the change.
How long propagation actually takes
The number commonly quoted is "24 to 48 hours." That figure is the worst case: a record with a 24-hour TTL that a resolver cached at exactly the wrong moment. In practice, propagation under normal conditions is often faster.
With a 3600-second TTL, most resolvers will have the new record within one to two hours of the change going live. With a 300-second TTL pre-set before the change, the majority of resolvers are updated within 10 to 15 minutes. Resolvers that only query your domain occasionally may take longer, but they represent a small fraction of actual traffic.
The exception is nameserver delegation. When you change the nameservers for a domain — not just an A or CNAME record, but the NS records themselves — the update goes through the TLD registry: .com, .org, .net, or the relevant country-code TLD. The registry has its own update cycle, typically every few hours. Nameserver changes can genuinely take 24 to 48 hours for the full resolver network to see the new delegation, because the registry update is not instant and resolver caches for root and TLD records belong to servers you have no influence over.
Checking propagation progress
The most reliable way to check whether a DNS change has propagated is to query the authoritative nameserver directly, bypassing any caches. You can do this with the AT USE DNS Lookup tool, which sends the query from our server — a different network vantage point than your own ISP's resolver.
To see what the authoritative answer is for a domain, query the NS record type first to identify the nameservers, then run an A, CNAME, or MX lookup depending on which record you changed. If the lookup returns your new record, the authoritative server is publishing it correctly. If clients in a specific region still see the old record, their resolver's cache hasn't expired yet.
For full propagation visibility — seeing the record from resolvers in North America, Europe, and Asia simultaneously — tools that run checks from dozens of geographic vantage points at once are useful for confirming that propagation is progressing globally, not just from one location.
Why different users see different results
Two users in the same city using different ISPs may see different DNS results for the same domain at the same moment. Their ISPs' resolvers cached the record at different times and have different expiry moments. A user on Google's 8.8.8.8 resolver sees the fresh record as soon as 8.8.8.8's cache expires. A user on their corporate network's internal resolver may wait longer if that resolver updates less frequently.
This is why "my colleague says it works" is not a reliable signal about whether propagation is complete. It means propagation is complete for their resolver — not necessarily for anyone else's.
It is also why clearing your local DNS cache doesn't guarantee you'll see the new record. Flushing your local cache (Windows: ipconfig /flushdns; macOS: sudo dscacheutil -flushcache) only removes your machine's cached copy. If your ISP's resolver still has the old record, you'll get the old record again on the next lookup — fetched from upstream rather than from your local cache.
Common propagation scenarios
The type of change determines propagation behavior:
A record change (new server IP). Depends entirely on TTL. With a 3600-second TTL, most traffic shifts within one to two hours. Pre-lowering TTL to 300 before the change cuts that to under 15 minutes for most users.
CNAME change. Same TTL dependence as A records. CNAMEs typically propagate on the same timeline as A record changes.
MX record change (email routing). Propagates like an A record by TTL, but email queues that collected during the window need to drain. Servers that cached the old MX record will continue delivering to the old mail server until their cache expires. Most mail servers retry undelivered messages for 24 to 72 hours before bouncing, so email during propagation is typically delayed, not lost.
Nameserver delegation (NS records at the TLD). The slowest scenario. The TLD registry update is handled on the registry's schedule, not your TTL. Plan for 24 to 48 hours and schedule any nameserver change during a low-traffic window.
TXT record change (SPF, DKIM, DMARC). Propagates by TTL. After a TXT change for email authentication records, allow time for propagation and a full mail delivery cycle before expecting all receiving servers to use the new record.
Can you make propagation faster?
The only lever you control is TTL — and only before you make the change. Lowering TTL to 300 several hours in advance is the single most effective action available. Once the change is live, you cannot flush other resolvers' caches. You cannot tell ISP resolvers to re-query. You can only wait for the TTL to expire.
After propagation is confirmed complete — checking from multiple geographic vantage points shows the correct record — raise the TTL back to a higher value (3600 or higher) to reduce DNS query load during normal operation. Running a low TTL indefinitely is unnecessary and increases the query volume sent to your nameservers.
What to do while you wait
If you need to test the new server before propagation completes, edit your local hosts file (Windows: C:\Windows\System32\drivers\etc\hosts; macOS/Linux: /etc/hosts) to point the domain to the new IP directly, bypassing DNS entirely. This lets you verify the new server is configured correctly before the cutover is visible to users.
For email record changes, monitor your mail server logs during the propagation window. Mail queued to the old MX record should drain to the old server and eventually redirect as propagation completes. If you're decommissioning the old mail server immediately, keep it running long enough to receive mail that arrives during the propagation window.
Check propagation status with the DNS Lookup tool. Run the lookup for your specific record type — A, MX, TXT, or CNAME — and verify the authoritative answer matches your change. Once you see the correct record from external vantage points, propagation is functionally complete for the vast majority of users.