What Is DNS Propagation?
DNS propagation is the delay between changing a DNS record and that change taking effect everywhere on the internet, as servers and devices worldwide update their cached copies. Because resolvers store DNS answers for a set time (the TTL) to speed up browsing, an update can take from a few minutes to around 48 hours to be seen by everyone. During propagation, some visitors see the new setting while others still see the old, which is why DNS changes are not instant.
- Typical duration
- Minutes to 48 hours (industry-typical)
- Main cause
- Cached DNS answers held for the record's TTL
- TTL
- Time To Live, how long an answer is cached
- Effect
- Some users see old records, others the new
What is DNS propagation? #
DNS propagation is the term for the time it takes for a change to a DNS record to spread across the internet and be seen by everyone. When you edit a record, updating an A record to point at a new server, changing MX records, or switching nameservers, the change happens instantly at your authoritative source, but the rest of the internet does not learn about it immediately. That is because DNS answers are cached by resolvers and devices around the world to make browsing fast, and those caches hold the old value until they expire. As caches expire and refresh at different times in different places, the new record gradually reaches everyone, a process that can take from minutes to about 48 hours. During this window, some people see your update while others still see the old setting. Understanding propagation prevents panic during launches and migrations, and it is why we plan DNS changes rather than flipping them blindly. For the underlying system, see /wiki/what-is-dns.
Why does DNS propagation take time? #
The delay exists by design, to make the internet fast. Every DNS lookup could, in theory, travel all the way to your authoritative nameservers, but that would be slow and would overload those servers, see /wiki/what-is-a-nameserver. Instead, resolvers, run by internet providers, networks, and public services, cache the answers they receive and reuse them for repeat lookups, so most queries are answered locally and instantly. Each record carries a TTL, or Time To Live, that tells resolvers how long they may keep the cached answer before checking again. Until that TTL expires, a resolver keeps serving the old value even after you have changed it. Because resolvers around the world cached your record at different moments, their TTLs expire at different times, so the update reaches them staggered rather than all at once. This caching is what makes propagation gradual, and it is also why the TTL you set is the single biggest factor in how quickly a change takes hold.
What is TTL and how does it affect propagation? #
TTL, or Time To Live, is a value attached to every DNS record that specifies how many seconds resolvers should cache the answer before requesting a fresh copy. A record with a TTL of 3600 is cached for one hour; a TTL of 86400 is cached for a full day. TTL directly controls propagation speed: the shorter the TTL, the sooner caches expire and pick up your change, and the longer the TTL, the longer old values linger. This is why the standard trick before a planned change is to lower the TTL, say to 300 seconds, a day or two in advance, so that when you make the actual change, caches everywhere refresh within minutes rather than hours. After the change settles, you can raise the TTL again for efficiency and reduced load. Setting TTLs thoughtfully is the difference between a near-instant cutover and a stressful, drawn-out one. We manage TTLs deliberately around every migration and launch, part of the care built into /services/website-migrations and /services/domains-dns-email.
How long does DNS propagation actually take? #
In practice, most DNS changes are visible to the majority of users within a few hours, and many within minutes if the TTL was low, but the common guidance of up to 48 hours reflects the worst case. Several factors influence the real duration: the record's TTL is the biggest, followed by how aggressively various resolvers and internet providers honor TTLs, some override short TTLs with their own minimums, and whether you changed a record or the nameservers themselves. Nameserver changes tend to take longer because they involve registry-level updates and TLD caching on top of resolver caching. Geography plays a role too, as different regions refresh at different times. The honest answer is that propagation is variable and not fully within your control, which is why plans should assume it may take up to two days even when it usually finishes far sooner. We set expectations clearly with clients and monitor progress rather than guessing, using tools like /tools/website-down-checker to confirm reachability from multiple locations.
What happens to my website during propagation? #
During propagation, your website can be in a split state: visitors whose resolvers have picked up the change reach the new server, while those still holding the cached old record reach the previous one. If you have set up the change correctly, with the new server fully ready and serving the same site, this is invisible and harmless, everyone sees a working site, just from one server or the other. Problems arise when the new destination is not fully prepared, or when you take the old server offline before propagation completes, in which case some visitors hit a broken or missing site. This is why best practice is to keep the old server running until propagation finishes, ensuring nobody lands on a dead endpoint. For stores and lead-generating sites, this overlap protects revenue during a move. We always stage and verify the new environment first, keep the old one live through the transition, and monitor until the change is universal, as part of /services/website-migrations, so customers never see disruption.
DNS propagation during a website migration #
Migrations are where propagation matters most, because you are moving a live site and cannot afford downtime or lost email. The safe sequence is: build and test the site on the new server using a temporary URL, replicate every DNS record including web and email, lower the relevant TTLs a day or two ahead, then update the A record or nameservers and keep the old server running until propagation completes, see /wiki/what-is-an-a-record and /wiki/what-is-a-nameserver. Email deserves special care, because MX records and authentication records must be in place on the new side before the switch, or mail can drop during the overlap, see /wiki/what-is-an-mx-record and /wiki/what-is-a-txt-record. Throughout, you monitor from multiple locations to confirm the change is spreading. This disciplined approach turns a risky change into a seamless one. Our /services/website-migrations team follows exactly this playbook, and we verify the live result with /tools/website-down-checker and /tools/email-deliverability-checker.
How do you check DNS propagation? #
You can watch propagation progress with DNS lookup tools that query resolvers in many locations at once, showing whether each is returning the old or new value. Global propagation checkers are especially useful because they reveal the staggered nature of the update, some regions updated, others not yet. You can also query specific public resolvers directly to see what they currently return. For a business-friendly check, our /tools/website-down-checker confirms whether your site is reachable from multiple vantage points, which is a practical proxy for whether the change has reached those areas. If you are moving email, /tools/email-deliverability-checker helps confirm mail records are live and correct. The key is not to judge propagation from your own computer alone, since your local cache or provider may lag or lead the rest of the world. Checking from multiple locations gives the true picture. We monitor propagation this way during every change so we know precisely when a cutover is complete.
Common propagation misunderstandings #
Several myths cause needless worry. The first is thinking a change failed because it did not work immediately, in reality it is almost always just propagating, and patience, not repeated edits, is the fix, editing again mid-propagation only muddies the picture. The second is judging propagation solely from your own device; your local cache, browser cache, or internet provider may show old or new results out of step with the wider internet, so always check from multiple locations. The third is expecting nameserver changes to be as quick as record changes, they usually take longer. The fourth is forgetting that some internet providers ignore short TTLs and impose their own minimums, so a few users may lag even after most have updated. Finally, flushing your local DNS cache updates only your machine, not the world. Knowing these realities keeps launches calm. We explain them to clients up front so changes feel controlled rather than mysterious, part of the guidance in /services/domains-dns-email.
How to minimize propagation delays #
You cannot eliminate propagation, but you can shrink its impact with preparation. The most effective step is lowering TTLs on the records you plan to change a day or two in advance, so caches everywhere expire quickly when you make the switch, then raising them again afterward. Timing the change for a low-traffic window reduces how many visitors experience any overlap. Fully preparing the new destination before switching, with the site and all records in place, ensures that whichever server a visitor reaches, they see a working site. Keeping the old server live until propagation completes prevents anyone from hitting a dead endpoint. For nameserver changes, replicating all records on the new provider first is essential. Finally, monitoring from multiple locations tells you exactly when the change is universal so you can safely retire the old setup. This preparation turns propagation from a risk into a non-event, and it is the standard process we follow on every launch and migration through /services/website-migrations.
FAQ
How long does DNS propagation take?
Most changes are visible within a few hours, and often within minutes if the TTL is low, but the common guidance allows up to 48 hours for the worst case. Nameserver changes tend to take longer than simple record edits. The record's TTL is the biggest factor in how quickly the change spreads.
Why isn't my DNS change working yet?
It is almost certainly still propagating. Resolvers around the world cache the old value until its TTL expires, so the change reaches everyone gradually. Editing the record again mid-propagation only causes confusion. Check from multiple locations rather than just your own device, and give it time, see /wiki/what-is-dns.
What is TTL in DNS?
TTL (Time To Live) is how long, in seconds, resolvers cache a DNS answer before requesting a fresh one. A lower TTL means changes propagate faster; a higher TTL means old values linger longer. Lowering the TTL a day before a planned change makes the switch take effect quickly.
Will my website go down during DNS propagation?
Not if the change is done correctly. As long as the new server is fully ready and you keep the old one running until propagation finishes, visitors reach a working site from one server or the other. Downtime happens only when the new destination is not prepared, which our migrations avoid, see /services/website-migrations.
Can I speed up DNS propagation?
You cannot force the whole internet to update instantly, but lowering TTLs before a change, preparing the new destination fully, and timing the switch for a quiet window all reduce its impact. Flushing your local DNS cache only updates your own machine, not other users around the world.
Why do I see the new site but my customer still sees the old one?
Because propagation is staggered, your resolver has picked up the change while your customer's resolver is still serving the cached old record until its TTL expires. This split state is normal during propagation and resolves as caches refresh worldwide, which is why we keep the old server live during migrations.
Was this helpful?