Why do some people see my new DNS records and others don't?

Each resolver cached the old answer at a different moment and keeps it until its TTL runs out, so they update at different times.

Can I speed up DNS propagation?

Only in advance: lower the record's TTL, to 300 seconds for example, at least one old-TTL period before the change. Nothing can make other resolvers drop a cached answer early.

How do I flush my DNS cache?

On Windows run ipconfig /flushdns. On macOS run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. In Chrome, use "Clear host cache" at chrome://net-internals/#dns. This only clears your own device.

How Long Does DNS Propagation Take? Why It Varies

Q: How long does DNS propagation take?

For an ordinary record change, up to the old record's TTL—often 5 minutes to an hour. Nameserver changes can take up to the parent zone's NS TTL, which is 48 hours for .com and .net.

You change a record and some people see the new value immediately while others see the old one for hours. This is usually described as "DNS propagation", as if the change were slowly spreading across the internet. Nothing actually spreads: your authoritative servers have the new data almost at once. What you are waiting for is caches expiring. Knowing which caches, and for how long, makes the delay predictable.

How long does DNS propagation take?

Anywhere from a few seconds to about two days, depending on what you changed and how long resolvers were told to cache the old answer. As a rule of thumb:

What you changed	How long until everyone sees it
A brand-new record nobody has looked up yet	Almost immediately
An existing A, AAAA, CNAME, MX or TXT record	Up to the record's old TTL—often 5 minutes to 1 hour, up to 24 hours for a TTL of 86400
A new record that someone looked up before it existed	Up to the zone's negative-caching TTL (from the SOA record), commonly 5 minutes to 1 hour
Nameservers at your registrar	Up to the parent zone's NS TTL—48 hours for `.com` and `.net`, often less elsewhere

The often-quoted "24 to 48 hours" is a worst case for nameserver changes, not a fixed waiting period. If the authoritative servers still show the old value after you saved a change, waiting won't help: the change didn't land where you think it did.

TTLs are the main factor

Every record has a TTL. When a resolver fetches it, it may keep and reuse that answer until the TTL runs out. If a record has a TTL of 86400 (one day) and a resolver fetched it five minutes before your change, that resolver can serve the old value for almost a full day. Another resolver that happened not to have it cached will fetch the new value right away.

That is why changes look random: each resolver's cache started its countdown at a different moment.

Plan ahead: lower the TTL (to 300 seconds, for example) at least one old-TTL period before a planned change. After the change is confirmed, raise it again.

Negative caching: "it doesn't exist" is cached too

If someone looked up a name before you created it, the resolver cached the fact that it didn't exist. The duration comes from your zone's SOA record—the lower of the SOA's own TTL and its minimum field (RFC 2308). With an hour-long negative TTL, a record you just created can stay invisible to that resolver for up to an hour.

The same applies to record types: asking for an AAAA record that didn't exist yet caches "no AAAA here".

Nameserver changes take longer

Changing nameservers at your registrar is slower than changing a record, for two reasons:

The registry has to publish the new NS records in the parent zone. Most do this within minutes, some take longer.
The delegation NS records in the parent usually have long TTLs—a day or two is common for TLDs. Resolvers that cached the old delegation keep asking the old nameservers until that expires.

So during a provider move, keep the old provider serving correct records until the old delegation TTL has passed. Deleting the zone at the old provider too early is a classic cause of a partial outage.

Other caches along the way

Large public resolvers run many separate cache instances. Two queries to the same address can reach different instances with different cached values.
Operating systems and browsers keep their own short-lived DNS caches.
Some resolvers enforce minimum TTLs, or serve stale data when your servers are unreachable (RFC 8767), extending how long old answers live.
Applications, such as long-running services, connection pools and some language runtimes, may resolve a name once and never look again until restarted.

How to flush your DNS cache

If your own device still shows the old value after public resolvers have updated, clear its cache:

System	Command
Windows	`ipconfig /flushdns`
macOS	`sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`
Linux (systemd-resolved)	`resolvectl flush-caches`
Chrome	Open `chrome://net-internals/#dns` and choose "Clear host cache"

This only clears caches on your device. It can't make your ISP's resolver, or anyone else's, forget an answer early—only the TTL does that. That's why lowering the TTL in advance is the only real way to "speed up propagation".

Checking what's really going on

Query the authoritative servers directly. If they return the new value, the change is in place and you are waiting on caches.
If they return the old value, the change wasn't saved, or you edited a zone at a provider that isn't the one delegated. Check the delegation.
Query a few public resolvers and look at the TTLs. The remaining TTL on a cached answer tells you roughly how long until that resolver refreshes.

The DNS Record Inspector can query Cloudflare, Google, Quad9 or your authoritative servers, so you can compare their answers and TTLs side by side.

A note on "propagation checkers"

Tools that query a list of resolvers around the world show a useful sample, but only a sample. There are millions of resolvers, each with its own cache. A sample of twenty that all show the new value does not prove every user sees it—it shows those twenty resolvers do, at that moment.

Used with that in mind, a sample is still the fastest way to see whether a change is landing. The DNS Propagation Checker compares public resolvers with the authoritative answer and shows how long each cached copy has left.