You changed your nameservers, hit save, and now your site is a blank page or a "server not found" error. You refresh. Nothing. Then it loads fine on your phone, which somehow makes it feel worse. Welcome to one of the most stressful hours in running a website.
Quick answer: A domain not propagating usually isn't broken. After a nameserver change, DNS updates spread across the internet gradually, from a few minutes up to 48 hours (rarely 72), because resolvers keep cached copies of the old records until their TTL expires. As of 2026, most changes finish within 1 to 4 hours. If it has been longer than 48 hours, the problem is almost always a misconfiguration, not propagation.
This guide comes straight from the incidents we handle. Our team resolves 20-30 site issues every day, and "it's still propagating" is one of the phrases we see most, so we wrote the full fix down so you can run it yourself. Most providers give you a vague "wait 24 to 48 hours" and leave you refreshing. A host like Hostaccent treats a stuck domain as a diagnosis, not a waiting game, and that's the approach you'll use below.
By the end you'll know what propagation actually is, how long it really takes now, how to check DNS propagation globally, and how to tell a harmless cache delay from a genuine mistake you need to fix right now.
What "Domain Not Propagating" Actually Means
When your registrar or host says a domain not propagating is why your site is down, they mean the change you made hasn't reached every network yet. DNS is a distributed system. Instead of one central address book, thousands of recursive resolvers worldwide each keep a cached copy of your records. Each cache holds the old answer until its timer runs out, so the update reaches different regions at slightly different moments.
Think of it as a phone book that's reprinted network by network, not all at once. Your new nameservers might already be live in London and still stale in São Paulo. That's exactly why a site can load on mobile data but not home Wi-Fi: two different resolvers, two different cache states.
The record that controls this timer is TTL (Time To Live), measured in seconds. When a resolver fetches your record, it's allowed to reuse that cached answer for the length of the TTL before checking again. Cloudflare's primer on how DNS resolution actually works is a solid refresher if you want the full chain from browser to root server.
There's an important distinction hiding in the phrase people type into Google. A DNS domain not propagating is not the same as a domain that's broken. Broken means a wrong record, a missing record, or a registrar-level lock. Propagation just means "correct change, still in transit." The fix for each is completely different, which is why guessing wastes hours.
Do I actually need to do anything, or just wait?
Most of the time, waiting is the correct move. If you set your nameservers correctly and it's been under a few hours, you're watching a normal process. The only reason to act is to confirm you didn't make a mistake, because a genuine typo won't fix itself no matter how long you wait. The rest of this guide is how you tell those two situations apart in about five minutes.
How Long Does DNS Propagation Really Take?
Here's the honest version the old documentation won't tell you: how long does DNS propagation take in 2026 depends almost entirely on one number, your record's TTL, and the famous "24 to 48 hours" is a conservative ceiling from the early 2000s, not a real average. Today most changes are visible within 1 to 4 hours, and often much faster.
That 48-hour myth has a real origin. Two decades ago, registrars set default TTLs of 86,400 seconds (a full 24 hours), and some TLD registries refreshed their zone files only every 12 hours. Stack those together and a nameserver change genuinely could take a day and a half. Modern infrastructure is different. Major registries now update within minutes, and the common default TTL in 2026 is 3,600 seconds (one hour), sometimes 300 seconds.
So the practical math is simple. With a 3,600-second TTL, the maximum a resolver holds the stale answer is one hour. Drop the TTL to 300 seconds ahead of time and the change becomes visible in about five minutes. The RFC that first defined this caching behaviour, the original DNS specification (RFC 1034), still governs how every resolver on the planet treats TTL today.
Two things stretch the timeline beyond your TTL, and you can't control either. Some ISPs ignore low TTLs and refresh their caches on their own schedule, sometimes every two or three days. And nameserver changes (as opposed to editing a single A record) involve the higher-level registry, so they lean toward the slow end.
Pro Tip: Lower your record TTL to 300 seconds a full 48 hours before a planned migration. By the time you actually switch, the old low TTL has already propagated everywhere, so the real change flips in minutes instead of hours. This one trick removes most "why isn't it live yet" panic.
If you registered a brand-new domain rather than changing an existing one, factor in registry activation and any registrant email verification, which can add its own short delay on top of propagation.
Why Your Domain Isn't Propagating: Causes Ranked by Frequency
In real incidents, "propagation" is the symptom people report, but the actual cause is usually one of five things, and they're not equally likely. Here they are ranked by how often they turn out to be the real problem, based on the domain and migration cases that reach us.
1. Nameservers set wrong or not saved at the registrar (most common). You updated the nameservers, but a typo slipped in, only two of the four were saved, or you edited DNS at your host while the domain still points its nameservers somewhere else. Editing records at a provider your domain doesn't delegate to changes nothing. This is the single biggest false alarm.
Across the 4,000+ sites Hostaccent has migrated since 2012, the most common cause we log for a domain that won't resolve is a nameserver mismatch at the registrar, not slow propagation. The change was never actually pointing where the owner thought it was.
2. Local and ISP cache. Your own computer and router still hold the old answer. This is why it works on cellular but not your desk. A quick DNS flush usually clears the local half.
3. DNSSEC mismatch. This one is nasty because it looks exactly like a propagation delay but never resolves on its own. If DNSSEC was enabled at your old DNS provider and you switched nameservers without removing the DS record at the registrar, strict resolvers will refuse to answer while lenient ones still work. The result: the site loads for some people for days and fails for others. Cloudflare's explainer on how DNSSEC signing works covers why the signature has to match on both ends.
Insider Insight: In the stubborn "still not propagating after 72 hours" cases, DNSSEC is the culprit far more often than people expect. If half the world sees your site and half doesn't, stop waiting and check your registrar for a leftover DS/DNSSEC record from the old host. Delete it, and the "propagation problem" clears within a normal TTL window.
4. Wrong or leftover records at the new DNS host. The nameservers are right, but the A record points at an old IP, or a stray record from a previous setup is winning. Understanding the difference between recursive and authoritative nameservers helps here: you must edit records at whoever is authoritative, which is wherever your nameservers point.
5. Registry or transfer lag on a brand-new or just-transferred domain. Genuinely just needs time, plus any pending verification.
Step-by-Step: How to Fix a Domain That Won't Propagate
Don't randomly change things. Run this in order. We call it the 4-Point Propagation Check, and it's the same triage our engineers run before touching anything, because it separates "just wait" from "real bug" in a few minutes.
Point 1 — Confirm what the world actually sees. Open a global checker like whatsmydns.net and look up your domain's A record and NS record. Green ticks in most regions means propagation is working and you should wait. A uniform red everywhere means the change likely never took.
Point 2 — Verify the record at the source with a direct query. On any terminal:
bash## check the nameservers the registry hands out dig NS yourdomain.com +short ## check the A record from a public resolver dig @1.1.1.1 A yourdomain.com +short
Windows users can run nslookup -type=ns yourdomain.com 1.1.1.1. If the nameservers that come back aren't the ones you set, the problem is at your registrar, not propagation. Go fix the nameservers there and re-save all of them.
Point 3 — Clear your own cache so you stop chasing a ghost. Your local machine lies to you constantly during this.
bash## macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ## Windows ipconfig /flushdns ## Linux (systemd) sudo resolvectl flush-caches
Also flush your browser cache and try an incognito window or a different network. If it works elsewhere, your change is fine and only local cache was fooling you.
Point 4 — Check DNSSEC. In your registrar's control panel, look for a DNSSEC or DS record section. If DNSSEC shows as enabled but you moved DNS providers, disable it (or update the DS record to match the new provider). This is the fix for the "some people, not others, for days" pattern.
Live site and no time to experiment? Our engineers fix this exact class of DNS and nameserver problem for a small one-time fee, and you'll see the exact quote before anyone touches your zone. Hosted with Hostaccent? Then issues like this are simply covered by support, free. Have an engineer fix it.
Once nameservers are correct, records point at the right IP, DNSSEC matches, and your local cache is flushed, you're done making changes. Everything from here is confirmation.
How to Confirm It's Fixed (and Stop It Happening Again)
To confirm the change is truly live, you need to check DNS propagation globally, not just from your own machine. Run your domain through a multi-location checker and watch for green across every continent, then query two independent public resolvers (1.1.1.1 and 8.8.8.8) with dig and confirm they both return the new record. When those three agree, propagation is genuinely complete, whatever your browser still shows.
In our support queue we handle 20-30 site issues a day, and when "it's still propagating" comes in, roughly nine times out of ten the DNS has actually finished and something else is the real problem, a caching plugin, an SSL certificate that hasn't reissued for the new IP, or an origin server that's genuinely down. If your SSL throws warnings right after a move, that's normal for a short window while the certificate reissues against the new record.
Prevention is mostly about sequencing:
- Lower your TTL to 300 seconds 48 hours before you migrate, then raise it back afterward.
- Never point your nameservers and rebuild your DNS records on the same rushed afternoon. Recreate the records at the new host first, confirm them, then switch nameservers.
- Keep the old hosting active for a few days after the switch so early visitors on stale cache still land somewhere real.
- If you use DNSSEC, disable it before moving DNS, then re-enable it once you're settled on the new provider.
A clean migration also protects your email. If MX records don't carry over correctly, mail silently breaks, which is its own headache covered in WordPress Emails Going to Spam? Here's the Actual Fix. And once the domain resolves everywhere, if the site itself feels sluggish, that's a hosting question, not a DNS one. Our guides on how to fix high TTFB in WordPress and diagnosing a slow WordPress site pick up where propagation leaves off, and Core Web Vitals failing because of hosting is worth a read if speed scores drop after a move.
Your Next Step: Two Clean Ways Out of a Stuck Domain
Now that you can tell a domain not propagating from a real DNS mistake, here are your two paths. If you fixed it: great, keep that TTL habit for next time. Also worth saying plainly: on a well-run host, this class of problem is support's job, not yours. That's how Hostaccent works: a UK-registered host operating since 2012 (incorporated 2018) with 10,000+ sites launched, a 99.9% uptime guarantee, and in-house engineers who handle the DNS side for you. You can start on the Economy plan at $1.99/mo with NVMe SSD storage and free SSL, or if you're still choosing a name, register your domain with a .com at $13.99/yr that stays $13.99 at renewal. One honest caveat: Economy is sized for a single site, so if you're running several projects, Standard fits better.
If you're still stuck: open a ticket and our engineers will fix it, with the exact quote shown before any work starts. Have an engineer look at it.
Frequently Asked Questions About DNS Propagation
How long does DNS propagation take in 2026?
How long does DNS propagation take now depends on your record's TTL, not the old "48 hours" rule. With the common 2026 default of 3,600 seconds, most changes go live within one hour, and typical real-world propagation finishes in 1 to 4 hours. Full worldwide consistency can take up to 48 hours in rare cases because some ISPs cache records on their own schedule and ignore low TTLs entirely.
Why is my domain not propagating after 48 hours?
If it's genuinely past 48 hours, you're not looking at propagation anymore, you're looking at a misconfiguration. The two usual causes are nameservers saved incorrectly at your registrar (a typo, or only some of the four entered) and a DNSSEC mismatch left over from your old DNS provider. Query your nameservers directly with dig NS yourdomain.com to confirm they match what you set, then check for a stray DS record.
What does "DNS domain not propagating" actually mean?
A DNS domain not propagating means your record change is correct but hasn't reached every network yet, because resolvers worldwide hold cached copies of the old answer until their TTL expires. It does not mean your domain is broken. Broken means a wrong or missing record; propagating means the right change is still in transit. Telling the two apart is the whole point of a global propagation check.
Why is my nameserver change not working?
The most common reason a nameserver change not working turns out to be an edit that never actually saved, or nameservers pointing to a provider where you didn't build the DNS records. Confirm the registry is handing out your new nameservers with dig NS yourdomain.com +short. If it returns the old ones, re-enter all of them at your registrar. If it returns the new ones but the site still fails, the issue is your records or DNSSEC, not the nameservers.
Will my email go down while my domain propagates?
It can, if your MX records don't carry over cleanly during the switch. Mail follows the same propagation rules as your website, so during the window some servers route to the old host and some to the new one. To avoid lost email, recreate your MX and any SPF, DKIM, and DMARC records at the new DNS host before you change nameservers, and keep the old mailboxes live for a few days as a safety net.
Do I need to buy new hosting to fix a propagation problem?
No, and be wary of anyone who says you do. A propagation issue is a DNS configuration matter, not a hosting-quality one, and you can fix it yourself with the checks in this guide. Where hosting matters is the aftermath: on a managed host like Hostaccent, a stuck domain is support's job, not yours, so you never troubleshoot dig output at midnight. But the fix itself never requires a new plan.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.