DNS Propagation: Why Your Changes Take Time

You update a DNS record — point your domain to a new server, swap in a new MX record, add a TXT record for email authentication — and then you reload the site in your browser. Nothing's changed. You check again ten minutes later. Still nothing. A friend across the country says the new version is loading fine on their end.

This is DNS propagation: the gap between "I updated the record at my authoritative server" and "the whole internet sees the new value." It's almost never instant, it's almost never broken, and it follows a few rules that, once you understand them, take all the mystery out.

Why it isn't instant

When you change a DNS record, you change it in one place: the authoritative server for your domain. That's the server your DNS provider runs that holds the canonical, current values. But nobody on the internet actually talks to your authoritative server directly. They talk to caching resolvers — servers run by ISPs, by public providers like Cloudflare or Google, and by every operating system on every device — that asked your authoritative server for the value some time ago and remembered the answer.

So the chain looks like this. Your browser asks the operating system. The operating system asks the resolver configured on the network — usually an ISP resolver or a public one like 1.1.1.1. That resolver, if it doesn't have the answer cached, asks the authoritative server. The answer comes back along with a number called the TTL, and every layer in that chain caches the value for as long as the TTL allows.

Until the cached copy expires, every device behind those caches sees the old value. Multiply that by every resolver on the internet, each holding the previous answer for some independent amount of time, and "propagation" is really just "waiting for every cache to expire." The conventional 24-to-48-hour window people quote comes from worst-case TTLs of a day plus a safety margin. In practice, most resolvers are updated within minutes.

What TTL actually does

Every DNS record carries a number called TTL (time to live), measured in seconds. It tells caching resolvers: "you may keep this answer for at most N seconds before asking again." When a resolver sees a record with TTL 3600, it stores the answer and serves it for the next hour without going back to the authoritative server. After the hour, the next query triggers a fresh lookup.

The common values you'll see, and what they mean in practice:

• 300 — five minutes. Used when you're about to make changes, or for records that need to flip quickly (failover IPs, CDN cutovers).
• 3600 — one hour. A reasonable default for most records.
• 86400 — one day. Used for records that essentially never change, like your SOA or top-level NS records. Reduces query load on your authoritative server.

The trick to fast propagation is to lower your TTL before the change, not at the same time. If your record currently has TTL 86400 and you update both the value and the TTL together, every resolver that recently cached the old value will hold it for up to a day — your shiny new TTL only applies to future caches. But if you set the TTL to 300 first and wait a full day, every cache fully turns over within five-minute windows by the time you change the record. The actual switchover then completes in minutes.

Once propagation is done you can raise the TTL back up. Stable records deserve high TTLs — they reduce load on the authoritative server and shave a few milliseconds off the average lookup. Low TTLs are an operational tool, not a permanent state.

How to check whether you've propagated

Loading the site in your browser doesn't really tell you much, because your browser and your OS have their own caches, and so does your local resolver. The right way to check is to query multiple independent resolvers and see what each one currently returns. If they all agree on the new value, you're propagated. If some still show the old value, you're not yet — give it time.

That's exactly what the DNS Propagation tool does: it queries eight public resolvers (Cloudflare and its security/family variants, Google, NextDNS, dns.sb, AliDNS, and DNSPod) over DNS-over-HTTPS and shows you what each one currently has cached for your domain. The result lands in a table where each row is a resolver, with a status dot, the answer it returned, the remaining TTL on its cached copy, and the response time.

The status dots are the headline. All green with consistent answers means you're done. Green with inconsistent answers means you're partway through propagation — some resolvers have the new value, others still have the old one cached. Red means the resolver returned NXDOMAIN (the name doesn't exist) or errored. Amber means the resolver responded but had no record of that type, or timed out.

For a deeper look at every record type a domain publishes — not just the one you're changing — the DNS records tool queries all the common types in one pass against a single resolver. The two tools complement each other: one for breadth across resolvers, one for breadth across record types.

"It works for me but not for them"

Sometimes you update a record, confirm propagation looks complete, and then someone reports the site is still down for them. A few specific things explain almost every case.

Your browser has its own DNS cache. Chrome and Firefox both keep a short-lived cache independent of the OS. The fix is to restart the browser, or visit chrome://net-internals/#dns in Chrome and clear it. Most people don't need to know this exists, but it can mask a propagation issue when you're the one waiting.

Your OS has a DNS cache too. On Windows it's the DNS Client service — run ipconfig /flushdns in a terminal. On macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux with systemd-resolved, sudo resolvectl flush-caches. Useful when you're troubleshooting locally and want a clean slate.

Some ISPs cache aggressively. A few residential ISPs ignore your TTL and cache for much longer — sometimes hours or days beyond what you specified. There's nothing you can do about it from the authoritative side. Users on those networks can switch to a public resolver like 1.1.1.1 or 8.8.8.8 and bypass the problem.

Negative caching is a thing. If a resolver asks for a record that doesn't exist yet, it caches the NXDOMAIN response too — usually for the SOA record's minimum field, often 5-15 minutes. So if you create a brand new record and check it from a resolver that probed before you created it, that resolver may still report "doesn't exist" for a while even though the record now does. This is why testing brand-new records works better with a public resolver you know hasn't queried for it.

Different resolvers, different states. Even within one provider, different geographic clusters can be at different cache states. Google DNS in California and Google DNS in Tokyo are technically separate cache populations, and a record can be propagated in one while still showing the old value in the other. CDNs add yet another layer of caching on top, especially for the IPs they're serving from.

The simple version

If you remember three things:

• DNS changes aren't instant because every resolver caches answers for up to the record's TTL.
• Lower your TTL before a planned change and wait for the old TTL to expire. Propagation then completes in minutes.
• To check progress, query multiple resolvers and compare. Don't trust your own browser — it's caching too.

If you're new to DNS in general, the DNS records primer covers what each record type means and where they fit. Otherwise, you're ready to actually check whether your records are out in the world yet.