How long does a DNS change take? What affects propagation time

Short answer

There’s no single fixed answer to how long a DNS change takes. It depends heavily on what kind of change you’re making. Updating a single A, CNAME or MX record usually propagates within minutes to a few hours. Changing a domain’s nameservers,

the typical step when switching hosting providers, takes 24-48 hours, and occasionally up to 72 hours.. This guide covers why a DNS change isn’t instant, what actually drives DNS propagation time, and the practical steps for managing a domain or hosting migration without downtime.

When does a DNS change come up?

For an agency or a business, a DNS change usually comes up in one of three situations: switching hosting providers (moving the site to a new server), switching email providers (updating MX records), or pointing a subdomain at a new service, such as a CDN or a form tool. In all three cases, there’s a transition period until visitors’ browsers pick up the updated information pointing to the right server, and estimating that period correctly is one of the more important parts of a launch plan.

How long does a DNS change take: nameservers vs. A single record

Updating a single A, CNAME or MX record and changing a domain’s nameservers are technically very different operations, and their propagation speed reflects that.

Updating a single record (A, CNAME, MX)

When you change just one record, say the A record pointing to your site’s IP address, the change takes effect almost immediately at your registrar’s or DNS provider’s authoritative server. The rest of the propagation depends on when resolvers around the world expire that record from their cache. That timing is tied directly to the record’s TTL, and it usually completes within minutes to a few hours.

Changing nameservers

Changing a domain’s nameservers, the most common step when moving from one hosting provider to another, moves more slowly. This change also has to be announced to the root DNS servers and the domain registry, and that extra step is the main reason a nameserver change typically takes 24-48 hours. With some registrars it can stretch to 72 hours.

How TTL (Time to Live) determines propagation time

TTL is a value, in seconds, that tells resolvers how long to keep a DNS record cached. If a record’s TTL is set to 3600 (one hour) and you change it, a resolver that already queried that record can keep returning the old answer, unaware of the change, for up to an hour. A higher TTL, say 86400 seconds or 24 hours, makes propagation slower. A lower TTL, such as 60-300 seconds, makes the change visible faster, at the cost of more queries hitting your DNS servers.

That’s why it’s standard practice to lower a record’s TTL a few days before a planned migration, so that by the time the actual change happens, resolvers are already working off a low TTL and pick up the new record much faster. Cloudflare’s own TTL documentation states plainly that a change to a TTL setting only takes effect once the currently cached TTL expires. That’s exactly why lowering TTL ahead of time works, and doing it right before the cutover doesn’t.

Other factors that affect propagation time

Factor	Effect
TTL value	A high TTL slows propagation down; a low TTL speeds it up
Nameserver change vs. Single record	Nameserver changes are slower because they require root server notification
Registrar processing speed	Some registrars process zone updates in minutes, others in hours
The user’s ISP	Some ISPs don’t fully respect TTL and refresh records on their own schedule instead
Browser/OS cache	A local cache can keep showing the old result for a while even after server-side propagation is done

How to check DNS propagation status

To see how a change looks across the world, tools like dnschecker.org query the same record from multiple DNS servers in different countries and list the results on one screen. If you’d rather use the command line, dig yourdomain.com (macOS/Linux) or nslookup yourdomain.com (Windows) show exactly what your own machine is resolving to right now. If the change was just made and these commands still return the old IP address, that’s expected, the right response is to wait out the TTL, not to assume something is broken.

Practical steps for a downtime-free DNS change

Following this order when planning a hosting or server migration keeps visitor and email disruption to a minimum.

1. Lower the TTL ahead of time

At least 24-48 hours before the migration date, lower the relevant record’s TTL to something low, like 300 seconds. That way, when the actual change happens, resolvers hold the old record for a much shorter window.

2. Get the new environment ready and tested beforehand

Before touching the DNS record, make sure the site (and its SSL certificate, if applicable) is fully working on the new server, typically by connecting directly to the server’s IP address or previewing the site through a temporary hosts file entry.

3. Don’t shut down the old server right away

Until propagation finishes (24-48 hours for a nameserver change), some visitors will still be routed to the old server. Keeping the old server active for a few extra days means those users get uninterrupted access in the meantime.

4. Plan MX records separately

If the email provider is also changing, MX records go through the same propagation process. Expect some email to arrive with a delay during the transition, and where possible, leave the old mail server accepting email for a while longer to avoid losing messages.

5. Make the change during low-traffic hours

Applying the DNS change when the site and email get the least traffic, usually overnight, reduces the number of users who could be affected by any confusion during the propagation window.

Common mistakes

The most common mistake is shutting down the old hosting account or server right after a nameserver change, visitors who still reach the old server before propagation finishes then run into a “site not found” error. The second common mistake is not having the SSL certificate set up on the new server ahead of time; once DNS propagates, visitors reaching the new server can hit a certificate error, something we cover in more depth in our guide to what an SSL certificate is. The third mistake is overlooking MX records, teams often plan for web traffic but forget about email, which can cause outgoing or incoming mail to go missing after the switch.

Checklist

Lower the relevant record’s TTL and test the new server or site ahead of the migration date. Apply the change during low-traffic hours and monitor propagation with dnschecker or dig/nslookup. Don’t shut down the old server until propagation finishes (24-48 hours), plan MX records separately, and confirm the SSL certificate is ready in the new environment.

Next step

A well-planned DNS change is effectively invisible to visitors; a poorly planned one can cost you visitors, disrupt email, and trigger trust-eroding errors. If a server or hosting migration is part of a larger site redesign, our guide to what to check before redesigning your website is worth reviewing too. If you’d rather have DNS, hosting and server migrations managed end-to-end with minimal downtime risk, our group company Web Tasarım Ofisi provides technical support for exactly that.

To have your corporate website’s infrastructure managed by a professional team, explore our corporate web design service or get in touch with us.

Sources

• Cloudflare, DNS TTL reference documentation, the official explanation of how TTL determines how long DNS records stay cached