Answer First
Definition: DNS propagation time is the interval between the moment a redirect change is saved and the moment every cache along the request path has expired the old value and started serving the new one. It is not a single global timer — it is the sum of however long each individual cache keeps the answer it already has. The relevant units are TTLs (time-to-live values) and cache lifetimes, not a fixed number of hours.
Why: Because the web is deliberately built out of layers of caches. When someone types your branded subdomain, the request passes through at least three of them before the page loads: the DNS resolver their network uses, the entry/forwarding layer that holds the subdomain’s destination mapping, and the browser itself — plus any intermediate caches such as corporate proxies, carrier gateways, or CDN edges. Each of those can keep serving a stale answer for its own lifetime, and none of them is visible from your side. The change is fully applied on your infrastructure long before it is applied everywhere — and the “users still see the old link” ticket arrives somewhere in between.
Example: At 10:00 your team updates a campaign entry’s destination from the old landing page to the new one. At 10:05 the change is live on the server — status shows the new destination, logs confirm it is being served. At 2:30 pm support gets the ticket: “the link still goes to the old page.” Nothing failed. The change applied instantly; the view of the change is still propagating through resolvers and browser caches that pinned the old answer. That ticket is not evidence the change broke — it is evidence that propagation is still in progress, which is exactly what this article helps you verify instead of guess.
Every team that changes a landing page or campaign destination eventually hits this moment — it is one of the most common link-ops questions there is. If the change is happening mid-campaign, our guide on what to do when the ad is approved but the landing page changed walks through the same situation from the campaign side.
Key Facts
- TTL is a ceiling, not a guarantee. The TTL on a DNS record is the maximum time a resolver may cache it, per the DNS specification — resolvers are expected to honor it, but it is an upper bound, not a promise of when the change will arrive.
- The TTL that matters is the one set before the change. Lowering the TTL after you switch the destination does not hurry the current change; it only shortens the window for the next one. That is why the standard practice is to lower TTL in advance, wait, then make the change.
- Three layers delay every redirect change: the DNS resolver, the entry/forwarding layer, and browser/intermediate caches. Each has a different lifetime, different owner, and different cure.
- 301 responses are cacheable — sometimes aggressively. Browsers and proxies may store a permanent redirect for a long time unless the response carries explicit caching headers.
- Negative caching exists too. Resolvers can also cache “this record does not exist,” so a brand-new subdomain can take time to appear even when its DNS is configured correctly.
- No tool shows “propagated everywhere.” Global propagation cannot be observed from one screen; you can only sample from multiple vantage points and reason about the layers in between.
| Layer | What it caches | Typical lifetime | Who controls it |
|---|---|---|---|
| DNS resolvers (ISP, public, corporate) | The old record value, for the record’s TTL | Minutes to hours, up to the TTL in force before the change | You, indirectly, via TTL set in advance |
| Entry/forwarding layer | The subdomain’s destination mapping and any cached redirect response | Depends on the platform’s own caching behavior | You, via status checks, logs, and purge actions where the platform exposes them |
| Browser + intermediate caches | The HTTP redirect response itself (301s especially) | From a single session to a long time, per HTTP caching rules | You, partially — clear site data, hard refresh, purge edge caches you manage |
Practical limits to accept: you cannot purge third-party resolvers, you cannot clear your users’ browsers, and corporate proxies sit between you and your audience doing their own caching. The realistic goal is not “change instantly everywhere” — it is knowing which layer is still holding the old value and shrinking the window you control.
Expert Explanation
Layer one: DNS TTL at the resolver level
DNS records carry a TTL: the time interval a resolver may cache the record before consulting the authoritative source again (RFC 2181, section 8). When you hand-edit a record, every resolver that looked it up before the change keeps the old value until its own cached copy expires — that is why “I updated it, why is it still old?” is so common. The resolvers are not broken; they are doing exactly what the TTL told them to do.
Two details make this layer trickier than it looks. First, the TTL that governs the current change is the one that was in force when the old answer was cached, which is why pre-lowering matters. Second, modern resolvers may deliberately serve stale data past the TTL when upstreams are slow or unreachable (a behavior documented in RFC 8767) — so even an expired TTL is not a hard guarantee of a fresh answer.
Layer two: the entry/forwarding layer’s own cache
The entry layer is the component that maps your branded subdomain to its destination and answers with a redirect or forward. When you update a destination through a management layer, you are changing that mapping — but the layer may serve its own cached responses with their own lifetimes, and the HTTP response it emits may itself be cached downstream. This is where the 301 vs 302 redirect choice becomes an operational decision: a 301 signals “permanent,” which makes caches more willing to store it; a 302 is not cacheable by default and behaves differently across browsers. If you are fighting “still goes to the old page” tickets, the status code your entries return is part of the propagation story.
Layer three: browser and intermediate caches
Browsers and intermediate caches follow HTTP caching rules rather than DNS ones. Per RFC 9110 and RFC 9111, a 301 redirect may be cached — in some cases with no explicit expiration — so a browser that followed the old redirect last week can keep replaying it. Corporate proxies, carrier gateways, and CDN edges add more layers you do not see and cannot purge. This is also why “it works in incognito” is not a full diagnosis: a private window bypasses your browser’s cache but does nothing about the resolver or the office proxy.
Hand-editing DNS records vs. changing through an entry management layer
The two workflows have genuinely different propagation stories. Hand-editing a DNS record creates a new record that must travel from your DNS provider to every resolver that cached the old one — propagation time is dominated by resolver TTLs, and misapplied changes are hard to trace because DNS has no audit trail of “who changed what, when.”
Changing a destination through an entry management layer usually leaves the subdomain’s DNS record untouched: the record stays put, and the mapping behind it changes. There is no new record to propagate, so the resolver layer is largely out of the story; what remains is the entry layer’s own cache and HTTP redirect caching. The trade-off is visibility: a layer that records status, logs, and traceable changes gives you evidence of what happened and when — the kind of evidence that also supports compliance audits, since a documented change trail is exactly what entry management contributes to audit evidence. If your team manages many subdomains, the same logic scales to consolidating entry ownership after an acquisition: the question is always “which layer is still serving the old value,” not “how many hours do we wait.”
Decision Framework
When a “still goes to the old page” ticket lands, do not guess — run this sequence. It is designed so marketing and ops can follow it without raw DNS access: everything below uses the Console/OpenAPI status, logs, and ordinary browser behavior.
- Check status. Open the entry in the Console (or query it via the OpenAPI) and confirm the stored destination is the new one. This answers the first question: did the change actually save? If status still shows the old destination, the change did not apply — re-apply it and, if it will not stick, treat that as a platform problem, not a propagation problem.
- Check logs and access statistics. Look at the entry’s logs and stats to see which destination the entry has actually been serving, and when the last request was served from the old one. This separates the two failure modes that look identical from outside: “change not applied” (status old, logs old) versus “change applied but cached” (status new, logs show it serving the new destination while some traffic still lands elsewhere).
- Purge the caches you control. Clear your browser’s site data, hard-refresh, purge any CDN or edge cache your team manages, and use any cache-purge action the platform exposes for the entry layer. You cannot purge user-side caches — only your own.
- Re-test on a fresh network. Test from a network path you have not used yet: phone on mobile data instead of office Wi-Fi, a different device, a private window. If the new destination is fresh everywhere you can test but users still report the old page, the remaining delay lives in caches you cannot see — that is normal propagation in progress. Communicate an expected window instead of escalating.
Escalation rule of thumb: if status shows the new destination, logs confirm the entry is serving it, and your fresh-network test passes, the system is working — wait or communicate. If status shows the new destination but logs still show the old one being served, the delay is inside the entry/forwarding layer. If status itself is wrong, the change never applied. Before rewriting anything, double-check the entry itself — an unchanged or mismatched entry will produce exactly these symptoms, and a campaign entry that mismatches the ad is a far more common culprit than broken infrastructure.
Key Takeaways
- “Propagation time” is not one number; it is the sum of three independent cache lifetimes: DNS resolvers, the entry/forwarding layer, and browser/intermediate caches.
- Set the TTL low before a planned change; after the change, it is too late to matter for that change.
- A 301 is cacheable and can linger in browsers for a long time — status code choice is part of your propagation strategy.
- Changing a destination through an entry management layer is a different propagation story than hand-editing a record: usually nothing new to propagate at the DNS level, but entry-layer and HTTP caches still apply.
- The four-step verification sequence — check status, check logs, purge, re-test on a fresh network — tells you which layer is delayed without needing raw DNS access.
- Accept what you cannot control: other people’s resolvers, browsers, and proxies. Your job is to shrink the window and know when to wait.
FAQ
Q: How long does DNS propagation actually take?
A: There is no single answer, because “propagation” is really a set of independent cache expirations, not one global timer. The practical range runs from seconds to roughly 48 hours in the worst legacy cases, and almost everything in between depending on the TTLs in play, the resolvers your audience uses, and how aggressively intermediate caches hold on. What you control is the TTL you set before the change: a low TTL ahead of a planned switch shrinks the window, while a record cached for days with a long TTL takes days to expire. If a change was already made with a long TTL, lowering it afterward does not speed up that change — it only helps the next one.
Q: I changed the entry, but my own browser still shows the old page. Am I doing something wrong?
A: Usually not — you are most likely looking at your own browser’s cached redirect or a cached DNS answer from your network’s resolver. Browsers can hold a 301 redirect for a long time, and your ISP’s resolver honors the TTL of the old record independently of what your DNS provider now returns. Try a hard refresh or clear site data, test in a private window, then test from a different network such as phone data instead of office Wi-Fi. Remember that your own test is one sample: it tells you about the caches on your path, not about everyone else.
Q: Does changing a destination through the Console or OpenAPI take the same 24–48 hours as editing a DNS record by hand?
A: Conceptually, no — and that distinction is the whole point of managing entries through a layer. When you hand-edit a DNS record, the change is a new record that must propagate from your DNS provider to every resolver caching the old value. When you change an entry’s destination through a management layer, the subdomain’s DNS record typically stays the same; what changes is the mapping the forwarding server uses, so there is no new record to propagate. What still applies is caching at the entry layer itself and HTTP redirect caching in browsers. The reliable way to know where your change stands is to check the entry’s status and logs — not to wait out a fixed time.
Q: Why does one device show the new page while another still shows the old one?
A: Because every cache in the path has its own lifetime, and they started counting at different moments. Your phone’s mobile network uses a different resolver than your office Wi-Fi, and each resolver caches the old answer for its own TTL window; your browser also caches redirects according to its own rules and history. A device that fetched just before the change may hold the old redirect for hours, while one that fetched just after gets the new destination immediately. This staggered rollout is normal and expected — it is the mechanics of propagation, not a sign the change failed.
Sources
- RFC 9110 — HTTP Semantics (redirect status codes 301/302/307/308): https://www.rfc-editor.org/rfc/rfc9110
- RFC 9111 — HTTP Caching (how redirect responses are stored and reused): https://www.rfc-editor.org/rfc/rfc9111
- RFC 2181 — Clarifications to the DNS Specification (TTL semantics, section 8): https://www.rfc-editor.org/rfc/rfc2181
- RFC 8767 — Serving Stale Data to Improve DNS Resiliency (post-TTL stale answers): https://www.rfc-editor.org/rfc/rfc8767
- MDN Web Docs — Redirections in HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- Cloudflare Learning Center — What is DNS propagation?: https://www.cloudflare.com/learning/dns/what-is-dns-propagation/