What Is DNS Propagation? How Long It Takes and How to Check (2026)

If you have ever changed a domain's DNS settings and then been confused about why your website sometimes shows the new version and sometimes the old one, or why your site is reachable for you but not for a colleague in a different city, DNS propagation is the answer. It is one of those technical concepts that is genuinely important to understand if you manage websites, change hosting providers, or work with domains regularly, yet it is rarely explained beyond the vague reassurance that changes "take up to 48 hours."

This guide explains how DNS actually works, what propagation means in concrete terms, what controls how fast it happens, and what you can do to manage it when you have a time-sensitive migration coming up.

Quick Summary

• DNS propagation is the time it takes for a DNS record change to spread to resolvers around the world
• It happens gradually, not all at once: different visitors see different versions depending on which resolver their device queries
• TTL (Time to Live) is the main factor controlling propagation speed, and lowering it before a change is the most effective preparation
• Most visitors see the updated record within a few hours; full global propagation can take up to 48 hours
• You can check propagation status using tools like whatsmydns.net or dnschecker.org

How DNS Works

Before understanding propagation, it helps to understand the system it is part of. DNS, the Domain Name System, is the mechanism that translates a human-readable domain name like yourdomain.com into a numeric IP address like 203.0.113.45 that computers use to route connections. When someone types your domain into their browser, a DNS lookup happens behind the scenes before any connection to your server is made.

The DNS lookup process involves several components. Your domain's authoritative nameserver is the definitive source of truth for your DNS records. It is the server that knows, for example, that your domain's A record points to a particular IP address. When you update a DNS record through your registrar or hosting control panel, you are changing the record on your authoritative nameserver.

But visitors' browsers do not query your authoritative nameserver directly every time someone visits your site. That would create enormous load on authoritative servers worldwide. Instead, when a visitor tries to resolve your domain, their device queries a recursive resolver, which is typically operated by their ISP, their employer's network, or a public service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The recursive resolver does the actual work of looking up the record, fetches it from your authoritative nameserver, and then caches the result locally so it does not have to look it up again for every subsequent request.

This caching is what creates DNS propagation. The cached copy of your DNS record lives in resolvers all over the world, and each one holds onto it for a defined period of time before fetching a fresh copy. When you change a DNS record, the authoritative nameserver has the new value immediately. But every cached copy of the old record still exists in resolvers everywhere, and those resolvers will continue serving the old record until their cached copy expires.

What TTL Is and Why It Matters

TTL stands for Time To Live. It is a number, measured in seconds, that you set on each DNS record. When a recursive resolver fetches your record from the authoritative nameserver, it also receives the TTL value and stores it along with the record. The resolver will serve the cached record for the duration of the TTL before fetching a fresh copy.

A TTL of 3600 means the record is cached for one hour. A TTL of 86400 means it is cached for 24 hours. A TTL of 300 means it is cached for five minutes.

The TTL value set at the time a resolver caches the record is what matters, not the TTL value at the time you make a change. This is a subtle but important point. If your A record had a TTL of 86400 when a resolver last queried it, that resolver will continue serving the cached record for up to 24 hours after you make a change, regardless of whether you lower the TTL after making the change. The lower TTL only affects resolvers that query your nameserver after the change is made.

This is why the standard professional advice is to lower your TTL well before a planned migration. If you lower your A record TTL from 86400 to 300 at least 24 to 48 hours before your planned change, every resolver that queries during that preparation period will cache the record for only five minutes. When you then make the actual DNS change, most resolvers will pick up the new value within minutes rather than hours.

After the migration is complete and stable, you can raise the TTL back to a higher value. Running with a very low TTL indefinitely is not necessary and generates more DNS query traffic than needed.

Why Different Visitors See Different Things

This is the aspect of DNS propagation that confuses people most. During the propagation window, two visitors loading your domain at the same time may get completely different results. One sees your new hosting environment. The other sees your old server. Your email client can connect fine. Your colleague's cannot. You check your site and it loads, then report to your hosting provider that everything is fine, when in fact it is not fine for many of your visitors yet.

This happens because different devices and networks use different recursive resolvers, and those resolvers have cached different versions of your records depending on when they last queried your authoritative nameserver.

A visitor using their home ISP's resolver might have had the old record cached for 18 hours of a 24-hour TTL, meaning it will expire in 6 hours and be replaced with the new one. A visitor using Google's 8.8.8.8 resolver might have queried just after your change and already has the new record. A visitor at an office might be using a corporate DNS resolver with aggressive caching that holds onto records longer than the TTL suggests, extending the inconsistency further.

There is no way to force other networks' resolvers to clear their cache on demand. The only reliable lever you have is the TTL you set before the change, and the only thing to do during propagation is wait.

The Difference Between Record Changes and Nameserver Changes

Not all DNS changes propagate the same way. There is an important distinction between changing an individual DNS record (like updating an A record or an MX record) and changing the domain's nameservers entirely.

When you update an individual record like your A record, you are changing a record on the same authoritative nameserver. Resolvers that have cached the old A record will fetch the new one when their TTL expires. The propagation time is controlled by the TTL on that specific record.

When you change your domain's nameservers, you are pointing your domain to a completely different authoritative nameserver. The information about which nameserver is authoritative for your domain is itself cached in the global DNS hierarchy at the registry level. The registry TTL for nameserver delegations is typically 24 to 48 hours and is not something you can change. This is why moving a domain to a new hosting provider, which usually involves a nameserver change, takes longer than simply updating a record on your existing nameserver.

During a nameserver change, the situation is more complex. A resolver may query the new nameserver and get new records. Another resolver may still be querying the old nameserver because it has the old delegation cached. This is why you should keep both the old and new hosting environments running and serving your site during a nameserver migration, so visitors receive a valid response regardless of which nameserver their resolver queries.

How to Check Propagation Status

While you are waiting for propagation to complete, you can monitor how much of the global DNS system has picked up your new records using a few tools.

Whatsmydns.net and dnschecker.org both query DNS resolvers in dozens of locations worldwide and show you what each one is returning for your domain. Enter your domain, select the record type you want to check (A for your IP address, MX for mail servers, NS for nameservers, TXT for SPF, DKIM, or DMARC records), and you will see a map and list showing which resolvers have the new value and which still have the old one. This tells you how far along propagation is at any given moment.

From your own command line, you can query a specific DNS server directly using dig:

dig yourdomain.com @8.8.8.8

This queries Google's public resolver for your domain. Changing the server after the @ symbol lets you query different resolvers and compare results. On Windows, the equivalent command is:

nslookup yourdomain.com 8.8.8.8

If you want to bypass local DNS caching on your own machine entirely and see what the authoritative nameserver currently says, you can query it directly. Find your authoritative nameserver first:

dig yourdomain.com NS

Then query that nameserver directly:

dig yourdomain.com @ns1.yourdomain.com

This shows you the source of truth immediately, regardless of what any caching resolver is returning. This is useful to confirm your change was made correctly on the authoritative side before blaming propagation delays.

What to Do During a Migration

DNS propagation during a hosting migration requires some planning to minimize disruption. The general principle is to make changes that affect as few visitors as possible for as short a time as possible.

Lower your TTL in advance. At least 24 to 48 hours before your planned migration, lower the TTL on your A record, MX record, and any other records you plan to change to 300 seconds (5 minutes). This ensures that by the time you make the actual changes, resolvers around the world will pick up the new values within minutes.

Keep the old environment running during the migration. While propagation is in progress, some visitors will still be reaching your old server. If you take the old server offline immediately after updating DNS, those visitors will get errors until their resolver picks up the new record. Keep the old server functional and serving your site until propagation is substantially complete.

For email in particular, do not update your MX records until your new mail server is fully configured and tested. If your MX records change before the new mail server is ready, inbound email may be lost during the gap. Unlike web traffic, email that bounces during a misconfiguration window is gone permanently.

After the migration is confirmed stable, raise your TTL back to a reasonable value. A TTL of 3600 (one hour) is a practical balance between propagation speed and DNS query efficiency for most domains. Very large sites sometimes use longer TTLs. Sites that change DNS frequently benefit from shorter TTLs.

DNS Propagation and Cloudflare

If your domain uses Cloudflare's nameservers, DNS changes made within Cloudflare's dashboard propagate within seconds to a few minutes across Cloudflare's global network. This is significantly faster than standard DNS propagation because Cloudflare's infrastructure is designed to push updates to its edge nodes rapidly.

However, external resolvers that have cached your record from before the change will still hold onto it until their TTL expires. So even with Cloudflare, a change to a record that had a high TTL when it was last cached may take the full TTL duration to propagate fully to all visitors. The rapid internal propagation only means that Cloudflare's own nodes have the new value quickly. Visitors whose resolvers query Cloudflare after the change will see it immediately. Visitors whose resolvers have a cached copy will see the old value until it expires.

Managing DNS Through WHMCS

If your domain is registered or your DNS is hosted through our platform, DNS records can be managed directly from your WHMCS client area without needing to access a separate registrar panel. Navigate to My Domains, click Manage next to the relevant domain, and select DNS Management. Changes made here take effect on our authoritative nameservers immediately, after which propagation to resolvers worldwide proceeds based on the TTL of each record.

If you are planning a migration and need to lower your TTL in advance, this is also done through the DNS Management section. If you need help understanding what changes to make for a specific migration scenario, open a support ticket and our team can review your current DNS configuration and advise on the correct sequence of changes.