Why do my DNS changes show for some people but not others?

Different resolvers cached your old record at different moments, so each one holds the stale value until its own remaining TTL counts down to zero. Until that happens, those users keep seeing the old answer.

How can I speed up DNS propagation?

Lower the record's TTL well before you make the change, wait one full old-TTL period so the low value is in effect everywhere, then update the record. New lookups will then expire quickly.

DNS Propagation: Why Changes Take Time (and How to Speed It Up)

Q: How long does DNS propagation take?

Anywhere from a few minutes to about 48 hours. The time is governed by the TTL on the record you changed and by how aggressively various resolvers cache, not by data physically spreading across the internet.

How Long Does DNS Propagation Take?

DNS propagation typically takes anywhere from a few minutes to about 48 hours, and most well-configured records update for the majority of users within a few hours. The word "propagation" is misleading, though. Nothing actually travels or spreads across the internet, and no central database pushes your change outward. What you are really waiting on is caching expiry. Resolvers around the world saved a copy of your old record, as the caching model in RFC 1035 describes, and each one keeps serving that copy until its cached time runs out. Only then does the resolver fetch the fresh answer from your authoritative nameservers. Grasp this distinction and the rest follows; for the foundation behind it, read DNS records explained.

Because each resolver cached your record at a different moment, they all expire at different moments too. That is why a change can look live for you while a colleague across the country still sees the old site. The data is correct at the source the instant you save it; the delay lives entirely in the caches between your authoritative servers and each user. If you want to track that expiry in real time, how to check DNS records walks through watching the values flip over.

What TTL Is and How It Controls Caching

TTL, or Time To Live, is a number measured in seconds attached to every DNS record. It tells resolvers how long they may cache the answer before asking again. Set a TTL of 3600 and the record may be held for one hour; set 86400 and it may be held for a full day. RFC 2181 clarified how this value should be interpreted and handled. TTL is the single biggest lever you control over how fast a change is seen, since it directly sets the maximum staleness window.

Here are common TTL values and what they mean in practice:

TTL (seconds)	Human-friendly	Caching behavior	Rough propagation expectation
300	5 minutes	Very short cache, fast updates	Most resolvers refresh within ~5-15 minutes
3600	1 hour	Common default	Most updates seen within an hour
14400	4 hours	Moderate	Several hours for broad coverage
86400	24 hours	Long, efficient cache	Up to a full day, sometimes longer

Shorter TTLs mean faster changes but more lookups hitting your nameservers. Longer TTLs reduce query load and are slightly faster for end users, but they make changes slow to take effect. There is no single right value; it is a trade-off you tune based on how often a record changes.

Why Resolvers Update at Different Times

Picture your old record with a one-hour TTL. One resolver cached it 5 minutes before your change, so it stays stale for 55 more minutes. Another cached it 58 minutes before and refreshes almost immediately. A third had nothing cached at all and gets the new value on its first lookup. Multiply that across thousands of resolvers worldwide, and a staggered rollout replaces any clean switch. None of this is a bug to fix, and no button forces every resolver on earth to dump its cache at once.

The Special Case: Nameserver and Registrar Changes

Changing the actual records inside a zone is one thing. Changing which nameservers are authoritative, or moving to a new DNS provider entirely, is slower and riskier. Nameserver delegation lives at the TLD level and often carries longer TTLs that you do not directly control, so these changes can take the full 24 to 48 hours to settle. See NS records explained for how delegation works and why nameserver changes propagate more slowly than ordinary record edits. The safe practice is to keep the old provider's zone serving correct records during the transition so users hitting either set of nameservers get the right answer.

How to Speed Up Propagation

You cannot force the world to forget your old record early, but you can shrink the window before you change anything. The technique is simple and reliable:

Lower the record's TTL to a small value such as 300 seconds.
Wait one full old TTL period. If the old TTL was 86400, wait a day so every cache has picked up the new low value.
Now make your real change. Because the TTL is already low, new lookups expire within minutes.
After the change is confirmed everywhere, raise the TTL back to a sensible value.

The work is in the planning, not the change itself. Lowering the TTL the day before a migration turns a potential 24-hour wait into a 5-minute one.

A common point of confusion: flushing your local DNS cache only affects your own machine. It does nothing for anyone else, because their resolvers still hold their own copies. It is useful for confirming a change reached the source, but it is not a propagation fix.

Check Your Records With Our Tool

The fastest way to confirm where a change stands is to look up the live records and compare them against what you expect. Our DNS checker queries records directly so you can watch the new values appear and confirm your authoritative servers are answering correctly. Run a free DNS check at domainintel.app to see your current records in seconds and verify your changes are taking hold.