You changed a DNS record, but your site still shows the old version. So how long does DNS propagation take? For most record changes, it takes a few minutes to a few hours. Nameserver changes are slower and can take up to 48 hours.
A common mistake makes the wait longer than it needs to be. People lower the record's TTL and change the record at the same moment. The wait is set by the old TTL, which is the timer that was on the record before you touched it. Lower that timer a day ahead, wait, and only then make the real change.
Want to see where your change stands right now? Our free DNS Propagation Checker asks 8 public DNS servers and shows which ones already have your new value. Below you'll find wait times for each record type, a safe step-by-step plan, and a simple way to work out why your DNS isn't updating.
| Quick answer | Details |
|---|---|
| What you'll use | Access to your DNS panel, plus our free DNS Propagation Checker (no sign-up) |
| Typical wait | Minutes to a few hours for most records. Up to 48 hours for nameserver changes. |
| What sets the wait | The TTL that was on the record before you changed it |
| Result | You'll know whether your new website, email or SSL settings are live, and what to fix if they aren't |
How long does DNS propagation take? The short answer
Most DNS changes reach users within minutes to a few hours. To be safe, plan for up to 48 hours, especially when you change nameservers.
Minutes to a few hours for most changes
DNS (Domain Name System) works like the internet's phone book. It turns a name like example.com into the number address (IP address) of the computer that hosts your site. When you edit a record, your DNS host has the new answer right away. The delay comes from other servers that still remember the old answer.
If your record had a short timer, most of the world picks up the change quickly. If it had a long one, some visitors keep seeing the old answer until that timer runs out.
Why you still hear "24 to 48 hours"
That number is a safe ceiling, not an average. GoDaddy's help page on propagation time says most updates take a few hours, but you should allow up to 48 hours. Hosts quote the upper limit so nobody panics too early, and most record edits finish long before it.
How it works: saved copies expiring, not data being pushed
This is the part that confuses most people. Nothing gets "sent out" to the world when you save a DNS change. Instead, many helper servers each keep their own saved copy, and each one asks again only when its copy expires.
Three terms make the rest of this page easier:
- Authoritative nameserver: the server that holds the true records for your domain. Everyone else copies from it.
- Recursive resolver (DNS cache): a helper server run by your internet provider (ISP), Google, Cloudflare and others. It looks up answers for you and remembers them for a while.
- TTL (Time to Live): a timer, in seconds, on each record. It tells resolvers how long they may keep a saved copy before asking again.
Picture each resolver writing your old address on a sticky note with an expiry time. Until that time passes, it reads the note instead of calling you to check. That's why you might see your new site while a friend in another city still sees the old one.
DNS propagation time by record type
For almost every record type, DNS propagation time is roughly one old TTL. Nameserver (NS) changes are the exception, because an extra step at the domain registry adds delay.
The table below gives rough guides based on what hosts and registrars publish. Use it to plan, not as a promise.
| Record | What it does (plain words) | Rough wait (guide, not a rule) | Watch out for |
|---|---|---|---|
| A | Points your domain to an IPv4 address (your server's number address) | About one old TTL, often minutes to a few hours | This is the record you usually change when moving to a new host |
| AAAA | Like an A record, but for the newer, longer IPv6 addresses | About one old TTL | A forgotten old AAAA record can send some visitors to the old server |
| CNAME | A nickname that points one name to another name | About one old TTL, plus the TTL of the name it points to | Often used for www and for store or landing page services |
| MX | Tells the world which mail server receives your email | About one old TTL | Keep the old mailbox active until the change finishes |
| TXT | A text note used for domain checks and email rules like SPF and DKIM | About one old TTL | Ownership checks may fail until the new note is visible |
| CAA | Lists which companies may issue SSL certificates (the padlock that encrypts your site) for your domain | About one old TTL | A wrong value can block your new SSL certificate |
| SOA | The zone's info card, with a serial number (version) and timers | Updates as your other records change | Its serial number helps spot servers that are out of sync |
| NS | Says which servers are in charge of your domain's records | The slowest. Allow up to 48 hours. | The new DNS host must already have all your records |
Why nameserver changes take longest
Your registrar is the company that sold you the domain. The registry (for example, the operator of .com) keeps the master list of which nameservers run each domain. When you switch nameservers, the change has to reach that master list before anything else happens.
Then resolvers have to let go of the old NS answer, and those answers can carry long timers set at the registry level. Some ISPs also hold answers longer than the TTL asks. That's why Namecheap and GoDaddy both tell customers to allow up to 48 hours for a nameserver switch.
A simple way to picture it: changing an A record is like changing your phone number in the phone book. Changing nameservers is like moving the whole phone book to a new office, and everyone has to learn the new office address first.
Your old TTL sets the wait, not the new one
Say your A record had a TTL of 86,400 seconds, which is one full day. You lower it to 300 seconds and change the IP address in the same minute. A resolver that saved the old record an hour earlier will keep it for about 23 more hours. It never sees your new short timer until its old note expires.
Now say you lowered the TTL to 300 seconds a full day earlier. By the time you change the IP, saved copies carry the five-minute timer, so most resolvers switch over within minutes. It's the same change with a very different wait.
What is TTL, and what should you set it to?
TTL is how long, in seconds, other servers may keep a saved copy of your record. A short TTL makes changes show up faster. A long TTL makes everyday lookups a little quicker but slows down future changes.
The Cloudflare DNS docs on TTL put it simply: the TTL controls how long a record is cached, so it controls how long updates take to reach users.
| TTL in seconds | In plain time | When it makes sense |
|---|---|---|
| 60 | 1 minute | The lowest value Cloudflare allows on DNS-only records for non-Enterprise plans |
| 300 | 5 minutes | A good setting just before a planned change. Cloudflare uses it for proxied records ("Auto"). |
| 3,600 | 1 hour | A sensible everyday value for many small sites |
| 86,400 | 1 day | Records that almost never change. Also the highest value Cloudflare allows on DNS-only records. |
Why not keep it low forever? GoDaddy notes that shorter TTLs send more lookups to your nameserver. That's fine for a short time, but there's little reason to stay at five minutes once things settle. Our view: drop it low for the move, then raise it back to an hour or a day.
How to change DNS and check propagation, step by step
Lower the TTL first, wait one old TTL, make the change, then confirm it with a propagation checker. Raise the TTL again once every server agrees.
1. Lower the TTL before the DNS change
About a day or two before your move, open your DNS panel. Set the TTL to 300 seconds on the records you plan to change, and leave everything else alone. Of all the steps here, this one does the most to shorten your wait.
2. Wait at least one full old TTL
If the old TTL was one day, wait one day. If it was one hour, an hour is enough. This gives every saved copy time to expire and come back with the new five-minute timer.
3. Set up the new home before you point to it
Get your new server, website and mailboxes working first. It's like moving into a new house: you want the lights and water on before you send out your new address.
If you're switching nameservers, add every record at the new DNS host before the switch. That means A, AAAA, www, MX, TXT and anything else you use. Otherwise your site or email can go dark the moment the new nameservers take over.
4. Make the change, then open the checker
Update the record. Then go to our DNS Propagation Checker, type your domain, and choose the record type (A, AAAA, CNAME, MX, NS, TXT, SOA or CAA). Press Check, and our server asks 8 public resolvers, including Google, Cloudflare and Quad9, what they currently see.
5. Add the Expected value and read the results
Type the value you expect, such as your new IP address, into the Expected value (optional) box. The tool then compares each server's answer with yours, so you don't have to match long numbers by eye. Each row also shows the TTL, which tells you how long that server may keep an old answer.
6. Turn on auto-refresh
Tick Auto-refresh every 30 s and leave the tab open. You'll watch servers switch to the new value one by one, without pressing Check over and over.
7. Raise the TTL again
Once every server shows the new value and your site and email work, set the TTL back to something longer, such as 3,600 seconds. Keep the old server running for at least one more day as a safety net.
What the checker can't see: it asks 8 public resolvers, not every ISP on earth, and not your own laptop. Each resolver refreshes on its own schedule, so timing can differ from place to place. Your ISP's resolver or your device can still hold an old copy after all 8 servers show your new value.
Why is my DNS not updating?
Usually, old saved copies just haven't expired yet. If every server still shows the old value long after the old TTL has passed, the record probably wasn't saved in the right place or has a typo.
| What you see | Likely cause | What to do |
|---|---|---|
| The checker shows a mix of old and new values | Saved copies are still expiring | Wait one old TTL and leave auto-refresh on |
| All 8 servers show the old value well after the old TTL | Record not saved, edited at the wrong DNS host, or a typo | Run an NS check to see which host is in charge, and edit there |
| The checker shows the new value everywhere, but you see the old site | Your browser, device, router or ISP still has the old copy | Clear your caches, restart, or try mobile data |
| A brand-new subdomain says "not found" | A "not found" answer was saved earlier (negative caching) | Wait it out, or flush the name at Google Public DNS |
| The site loads, but with an SSL warning | The certificate isn't set up on the new server yet, or a CAA record blocks it | Check with our SSL Certificate Checker |
| Email stopped arriving | MX record missing at the new host, or old mailbox closed too early | Check MX in the checker and reopen or keep the old mailbox |
You see the old site, others see the new one: clear local caches
Your browser and computer keep their own small DNS memory. In Chrome, go to chrome://net-internals/#dns and click Clear host cache. Restarting your device and router also helps.
For a quick test, load the site on your phone using mobile data, not Wi-Fi. If it works there, the problem is your local network, not your DNS. Our guide on checking if a website is down for everyone or just you walks through more of these quick tests.
Flush the cache at Google Public DNS
Google offers a free Flush Cache tool. According to the Google Public DNS FAQ, you don't need to prove you own the domain, but you do have to pass a reCAPTCHA. After a nameserver change, Google suggests flushing the main domain first, then subdomains like www.
For a stale CNAME, Google suggests starting at the last name in the chain and working back to the name you looked up. Keep in mind that a flush only helps people who use Google's resolver. It won't clear your ISP's cache.
New subdomain not found: negative caching
This one catches a lot of people. Say you typed shop.example.com into your browser before you created the record. The resolver got a "this name doesn't exist" answer, also called NXDOMAIN, and it can remember that answer for a while.
How long depends on your SOA record. Under RFC 2308 on negative caching, the time is the lower of the SOA record's own TTL and its MINIMUM field. So the new subdomain looks broken even though the record is fine. Wait a bit, flush it at Google, and avoid testing names before they exist.
Still wrong after 48 hours: check your settings
GoDaddy's advice is clear: if things still look wrong after 48 hours, suspect your DNS settings. At that point, more waiting won't fix it. Check these in order:
- Run an NS check in the propagation checker. Are you editing records at the host those nameservers belong to?
- Look up the exact record. Is the value spelled right, with no extra characters?
- Compare the SOA serial number across servers. Different numbers mean your nameservers are out of sync with each other.
Our DNS Lookup tool is handy here for reading one record in full detail.
Common DNS change mistakes and fixes
Most "slow propagation" problems turn out to be setup mistakes. These are the ones we'd check first.
| Mistake | What happens | Fix |
|---|---|---|
| Editing DNS at the registrar while nameservers point to another host | Your changes never go live, because nobody reads that panel | Edit records wherever your nameservers point |
| Switching nameservers before copying all records | The site, email or both stop working | Rebuild every record at the new host first, then switch |
| Changing the record and the TTL on the same day | You still wait the full old TTL | Lower the TTL a day or two ahead |
| Forgetting www or an old AAAA record | Some visitors land on the old server | Update or remove every record that points to the old host |
| Typing the full domain where the panel adds it for you | You get odd names like www.example.com.example.com | Follow your panel's examples, then confirm in the checker |
| Putting a CNAME on the root domain (example.com) | The record is rejected or breaks other records, since the root must also hold NS and SOA | Use an A record, or your DNS host's alias option if it has one |
| Testing only on your own device | You see stale results and think nothing changed | Use the checker, then test on mobile data |
| Closing old hosting or email too early | Visitors and messages on stale DNS hit a dead server | Keep both running until all checks agree, plus a day |
Pro tips for a smooth DNS move
A calm DNS move comes down to good timing and a safety net. These habits help most.
- Move on a quiet day. Pick a time when few customers visit and when you're around to watch the checker.
- Write down every record before you start. A screenshot of your current DNS panel is a cheap backup.
- Treat email with extra care. When you change MX records, keep the old mail service active until the new MX shows everywhere. Recheck your SPF and DKIM TXT records too, since they prove your emails really come from you. Our guide to SPF, DKIM and DMARC explains what each one does.
- Use the Expected value box. A match-or-no-match result is much faster to read than comparing long IP addresses by eye.
- Don't flush and refresh in a panic. If the old TTL hasn't passed yet, the system is working as designed.
Moving a website or email? Let us handle the DNS
If you'd rather not juggle TTLs, nameservers and mailboxes yourself, our Cloud & DevOps team can plan and run the whole move. We set up cloud hosting (the servers your site runs on), deployment pipelines and monitoring, with SSL and regular backups as standard.
Every project gets a dedicated team and project manager, with weekly demos so you always know where things stand. SEO and performance are built in from day one, not patched on after launch. Once you're live, our maintenance plans cover updates, security patches, backups and performance monitoring.
We've worked with businesses for over 10 years and have delivered 491+ projects for clients worldwide. After a free discovery call, you get a fixed quote with milestones and no hidden costs. Our team replies within one business day. See everything we offer on our services page, and request a free quote when you're ready.
Check your DNS now (free)
The fastest way to know if your change is live is to look. Open our free DNS Propagation Checker, enter your domain, pick the record type and press Check. There's no sign-up, it works in your browser, and nothing is stored.
Frequently Asked Questions
How do I check DNS propagation?
Use a propagation checker that asks several public DNS servers for your record at once. In our free DNS Propagation Checker, enter your domain, pick the record type and press Check. Add your new value in the Expected value box to see which servers already match it.
How long do nameserver changes take?
Nameserver changes are the slowest kind of DNS update. Namecheap says they may take 24 to 48 hours to take effect. If they still haven't updated after 48 hours, Porkbun suggests the new nameservers may have a setup problem, so run an NS lookup in a propagation checker.
Can I speed up DNS propagation?
You can't force other servers to drop their saved copies early. What you can do is lower the TTL to about 300 seconds a day or two before the change. You can also flush your domain at Google Public DNS, which helps people who use Google's resolver.
Why do I see the old site when others see the new one?
Your browser, computer, router or ISP is still holding an old saved copy. Clear Chrome's host cache at chrome://net-internals/#dns, restart your device, or test on mobile data. If the site works on mobile data, your DNS is fine.
What TTL should I use?
Before a planned change, 300 seconds (5 minutes) works well. Once the change is live everywhere, raise it to 3,600 seconds (1 hour) or 86,400 seconds (1 day). Long TTLs make lookups a little faster but slow down your next change.
Why can't I flush my domain at Google Public DNS?
The Google Public DNS FAQ says domains that use EDNS Client Subnet can't be flushed. This is a feature some DNS providers use to give location-based answers. For those records, Google advises keeping TTLs at 15 minutes or less so changes reach users quickly.
Is the DNS Propagation Checker free?
Yes. Our DNS Propagation Checker is a free online tool with no sign-up, and it doesn't store your lookups. It checks 8 public resolvers and supports A, AAAA, CNAME, MX, NS, TXT, SOA and CAA records. Try the DNS Propagation Checker now.
