What Is DNS Propagation and How Long Does It Take?
DNS propagation is shorthand for different recursive resolvers updating cached answers at different times after an authoritative DNS change.
How it works
DNS changes do not spread as one global event. Authoritative servers publish the new record, while recursive resolvers refresh according to TTL and their cache state. A and AAAA records, MX records, and TXT policies can all appear inconsistent during that period.
Why DNS changes do not update everywhere at once
DNS propagation is a convenient phrase, not a literal broadcast. You change a record at the authoritative DNS provider, which becomes the source of truth for the zone. Recursive resolvers operated by ISPs, companies, and public services then ask those authoritative servers when they need a fresh answer. Until then, they can use an answer already held in cache.
A resolver caches an answer for the record's time to live (TTL). If an A record had a 3,600-second TTL and a resolver fetched it one minute before your change, that resolver may continue returning the earlier answer for nearly another hour. Another resolver with no cached answer can show the new value immediately. That difference is the usual reason two people see different results after a change.
Negative answers can be cached too. If a resolver recently received a no-record or no-domain answer, it may retain that result for the zone's negative-cache TTL. This matters when adding a new host, TXT policy, or mail record: a correct new record can coexist briefly with a cached absence.
Records, routing, and apparently inconsistent answers
The same cache rules apply to A and AAAA address records, CNAME aliases, MX mail routing, NS delegation, and TXT data such as SPF and DMARC. A web move can look partly complete when an A record is fresh but a related AAAA record is still cached. An email change can be confusing when MX and TXT records refresh on different schedules.
Not every difference is a stale cache. CDNs, geo-distributed DNS, and load-balanced services can deliberately return different addresses by resolver location or network. Split-horizon DNS can also give internal users a private answer and the public internet a different one. Compare the requested record type and authoritative configuration before treating a difference as an error.
For a planned migration, lowering TTL beforehand can reduce the period that new caches keep the old answer. Lowering it after the change cannot erase cache entries created under the old TTL. Leave enough lead time for existing caches to age out, then make the change and verify it.
A practical troubleshooting flow
First, confirm the record was saved in the correct authoritative zone and that the hostname is complete. Check whether a CNAME, an old AAAA record, or an unexpected nameserver delegation is affecting the result. If a website is involved, test both address families and verify that the destination server is ready before changing DNS.
Next, note the TTL and compare several public recursive resolvers. If they agree with the authoritative answer, a local device, browser, or corporate resolver may be the remaining cache. Avoid repeatedly changing records while troubleshooting; every change can create a new set of cache states. Keep a short timeline of the old value, new value, TTL, and the resolver observations.
For example, moving example.com from one host to another may show the new A record on one public resolver while another still returns the old address. That does not prove either resolver is broken. It normally means they refreshed at different moments. If the authoritative response itself is old, the issue is at the DNS provider or delegation level instead.
Using the DNS Propagation Checker
Our DNS Propagation Checker compares a selected record across public resolvers. Matching answers are a useful agreement signal; different answers point to a cache, geographic DNS behavior, or configuration worth investigating. An unavailable resolver is reported separately from a resolver that returned no record.
The checker is not proof of worldwide propagation. It does not query every ISP, your office resolver, or every CDN region, and it cannot clear a cache. Use it alongside a direct DNS lookup and the authoritative zone settings. For ownership and delegation questions, a WHOIS / RDAP lookup can provide helpful surrounding context.
Suppose a new MX record is visible on two public resolvers but an older resolver still returns the previous host. Keep both mail services able to receive mail while the old TTL can still be in use, rather than deleting the old target immediately. Likewise, when replacing a CNAME, check the target record as well as the alias: a fresh alias can still point to a target whose address has not updated as expected. The useful question is which resolver, record type, and authoritative answer produced the difference.
Practical guidance
- Check the authoritative zone and the published TTL before changing anything else.
- Compare A and AAAA records separately when a service supports both address families.
- Use the DNS Propagation Checker as a resolver-agreement signal, not worldwide proof.
Common question
How long does it take? It depends largely on TTL, cached data, and resolver refresh behavior.