How DNS Propagation Works and How Long It Actually Takes
Every developer eventually encounters the "48 hours" myth. You change a DNS record, ask when it will take effect, and someone tells you to wait up to 48 hours. That number is technically defensible in edge cases, but in practice it causes two problems: it makes developers wait too long when propagation is already done, and it gives them no framework for diagnosing when something has actually gone wrong. Here is what is actually happening under the hood.
What Actually Happens When You Change a DNS Record
When you update a DNS record at your registrar or DNS host, the change is written to your authoritative nameservers almost immediately. These are the servers that hold the ground truth for your domain. The change is live at the source within seconds.
The complication is caching. DNS was designed for a world with billions of queries per day, and querying authoritative servers for every lookup would collapse the system. So resolvers cache answers. When Google's 8.8.8.8 looks up your domain and gets an answer, it stores that answer locally and serves it from cache until the TTL (Time To Live) expires. TTL is a number you set on each DNS record, measured in seconds.
This is the critical insight: the maximum propagation time for any DNS change is approximately equal to the old TTL on that record at the time you make the change. Not 48 hours. Not any fixed number. Whatever TTL was set before you changed it.
If your A record had a TTL of 86400 (24 hours) and you just changed it, resolvers that have a fresh cached copy of the old record can serve it for up to 24 more hours. If your TTL was 300 (5 minutes), propagation is effectively complete for most users within 10 minutes.
Why Different People See Different Results
After you make a DNS change, you might be able to reach your new server immediately while a colleague on a different network still hits the old one. This is not a bug. It is DNS working as designed.
Every resolver maintains its own independent cache. Your ISP's resolver, Google's 8.8.8.8, Cloudflare's 1.1.1.1: they all cache separately. If your ISP's resolver happened to fetch your record two minutes ago and your TTL is 300 seconds, you will see the old value for another three minutes. Your colleague's ISP resolver might have fetched it twenty minutes ago and already expired the cache, so they see the new record immediately.
This is why "it works on my machine" is a common complaint during DNS migrations. The person reporting the problem is likely behind a resolver that has a fresh-ish cached copy of the old value. Checking against multiple resolvers directly, rather than relying on your local machine's DNS, is the only way to get an accurate picture of propagation status.
Record Type Propagation Differences
Not all record types propagate at the same effective speed, even when TTLs are identical. The difference comes down to how aggressively different systems cache specific record types.
| Record Type | Typical Propagation | Notes |
|---|---|---|
| A / AAAA | TTL-dependent | Straightforward. Propagation time = old TTL at time of change. Most resolvers follow TTL honestly. |
| CNAME | TTL-dependent | Same as A records. Watch for recursive CNAME chains: each hop has its own TTL. |
| MX | Can lag longer | Mail servers cache MX records aggressively and often ignore low TTLs as a spam mitigation measure. Budget extra time for email routing changes. |
| TXT (SPF / DKIM) | Often the last to propagate | Receiving mail servers cache SPF and DKIM lookups heavily. DKIM changes in particular can take several hours even with a 300s TTL. Most email failures after a DNS change are TXT-related. |
| NS | Complex (can take hours) | NS record changes involve the parent zone (registry/registrar) and are handled differently than zone-level records. Allow 24–48 hours for NS delegation changes at registrars. |
| SOA | Managed by DNS host | You typically do not change SOA records directly. The SOA serial number increments automatically and signals secondary nameservers to pull zone updates. |
How to Lower TTL Before Making Changes
The professional approach to DNS migrations is something most developers learn the hard way, after a painful incident. Here is the playbook.
At least 24 hours before you plan to make a DNS change, lower the TTL on the affected records to 300 seconds (5 minutes). This step is critical and often skipped. If your current TTL is 86400 and you lower it right before making the change, you get no benefit. You have to wait for the old TTL to expire first before the new low TTL kicks in for the resolvers that just cached it.
Once you have waited 24 hours with a TTL of 300, every resolver's cache is expiring every 5 minutes. Make your DNS change. Within 10 minutes, the vast majority of resolvers will have the new record. Check a few public resolvers directly to confirm. Once you are confident propagation is complete, raise your TTL back to something sensible: 3600 (1 hour) for records that might need to change again, 86400 (24 hours) for stable records that improve resolver performance with longer caches.
This two-step TTL strategy (lower before, raise after) is the difference between a DNS migration that resolves in 10 minutes and one that has your team watching a status page for 24 hours.
3600s (1 hr): Good default for most records. Balances propagation speed with resolver efficiency.
86400s (24 hr): Use for stable records (e.g., your main A record once infrastructure is settled). Reduces resolver load but slows any future changes.
How to Check Propagation Yourself
Checking your own machine's DNS tells you what your local resolver has cached, which is only one data point. To get an accurate picture of global propagation, you need to query multiple resolvers directly and compare their responses.
The tool below queries 6 resolvers in parallel (Google, Cloudflare, Level3, Quad9, Verisign, and HurricaneE) using live DNS queries, not a cached database. It tells you whether all resolvers agree (propagated) or whether they are still returning different values (in progress). You can query any record type: A, AAAA, CNAME, MX, TXT, NS, or SOA.
If you have just made a DNS change and one resolver is still returning the old value, that resolver's cache simply has not expired yet. Check back in a few minutes. If a resolver is still returning the old value after several TTL cycles have passed, you may have a configuration issue worth investigating.
After a domain migration, it is also worth checking your SSL certificate to ensure the new server's certificate is valid. A DNS change that routes traffic to the wrong IP, or to an IP without a valid cert, will cause browser warnings even if DNS itself resolved correctly.