What propagation means
"DNS propagation" is a widely-used but slightly misleading term. DNS records do not push out to resolvers when you make a change — resolvers pull answers on demand and cache them for a period defined by the record's TTL. The "propagation" that takes time is actually cache expiry: resolvers around the world holding cached copies of your old records will continue serving them until their cache entries expire.
The important distinction is between authoritative answers and cached answers. If you query your domain's authoritative nameserver directly, you always get the current record immediately after making a change. If you query a public recursive resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, your ISP's resolver), you get whatever that resolver has cached — which may be minutes or hours old.
This is why "it works for me but not for my colleague" is a common post-change experience. You flushed your local DNS cache and your resolver picked up the new record quickly. Your colleague's resolver still has the old value cached.
How TTL works
The Time-to-Live field on a DNS record tells resolvers how many seconds to cache the answer before re-querying. A record with TTL 3600 will be cached for up to one hour by compliant resolvers. After that, the resolver discards the cached entry and makes a fresh query to the authoritative server.
Important nuances:
- Negative caching (NXDOMAIN TTL): When a resolver queries for a name that does not exist, the nameserver returns an NXDOMAIN response with a TTL (sourced from the SOA record's minimum field). Resolvers cache this negative result too. If you add a new record for a name that was previously queried and got an NXDOMAIN, resolvers will continue returning NXDOMAIN until their negative cache entry expires.
- The TTL countdown starts at query time: A resolver may query for a record at second 0 and cache it for 3600 seconds. Another resolver might query at second 1800 and also cache it for 3600 seconds. At second 3600, the first resolver re-queries; the second does not until second 5400.
- Low TTL vs caching efficiency: Lower TTL means faster propagation but higher query load on your authoritative servers. Most operators use 300–3600 for records that may change, and 86400 or higher for stable records like root MX or NS.
Lowering TTL before changes
The standard operational procedure for minimizing propagation time is to lower the TTL well before making the change:
- Check the current TTL of the record you intend to change.
- Lower the TTL to 300 (5 minutes) at least 24–48 hours before the planned change — enough time for all resolvers with cached copies to refresh at the new low TTL.
- Make the record change. With a 5-minute TTL, most resolvers will pick up the new value within minutes.
- After the change is stable, raise the TTL back to a sensible value (e.g., 3600 or 86400).
If you forget to pre-lower the TTL and change a record with a 24-hour TTL, some resolvers may serve the old answer for up to 24 hours after your change.
Checking propagation
The most reliable way to check whether your change has propagated is to query multiple resolvers simultaneously and compare the answers. Resolvers in different geographic locations and operated by different organizations will have independent caches at different stages of expiry.
Useful public resolvers to query:
- Cloudflare:
1.1.1.1and1.0.0.1 - Google:
8.8.8.8and8.8.4.4 - Quad9:
9.9.9.9 - Mullvad:
194.242.2.2
If all four return the new record, propagation is effectively complete for the major resolvers. If some return old values, note the TTL remaining in their response — that tells you when they will re-query.
Use the Compare mode in the DNS inspector to fan out a query to all resolvers simultaneously and display differences side-by-side. Disagreements between resolvers are highlighted, making it immediately clear which resolvers are still serving stale data.
Common propagation scenarios
- MX record change (email switchover): New MX records propagate like any other record. However, mail senders cache MX lookups aggressively. Expect some mail to go to the old provider for up to the old TTL after the change. Stage the cutover by accepting mail at both old and new providers during the transition window.
- A record change (hosting migration): With a 5-minute TTL pre-lowered, most users will reach the new server within 10–15 minutes. Plan for the old server to remain reachable during the transition and keep any sessions or state synchronized if applicable.
- CAA record addition: Propagates quickly because CAA records are rarely cached at all (most resolvers only check them on-demand during certificate issuance). However, CAs may cache negative responses — if a CA queried and found no CAA record, check whether the CA honors low TTLs on negative cache.
- NS delegation change (slowest): Changing nameservers requires the parent zone (e.g.,
.comregistry) to update its delegation record. This can take 24–48 hours to propagate through the registry infrastructure, independent of TTL. The old nameservers must remain authoritative and serving correct records throughout.
Why some resolvers are slower
Not all resolvers honor TTL as specified. ISP-operated resolvers may apply a minimum cache floor (often 5 minutes regardless of TTL) or a maximum cap (extending long TTLs). Some Anycast deployments have per-node caches, so different instances of 8.8.8.8 may have different cache states depending on which anycast node your query reaches. Negative caching (NXDOMAIN) sometimes outlasts the SOA minimum TTL due to implementation quirks.
What you cannot control
Once a record is cached by a third-party resolver, you have no mechanism to flush it remotely. CDN edge caches (which may issue their own DNS lookups for origin health checking) can also hold stale data. The local OS DNS cache on user machines may add another layer — Windows and macOS both cache DNS responses independently of the resolver. After making a change, communicate the expected propagation timeline to your team rather than treating a specific cutover time as hard.