DNS Not Propagating After a Domain Change? How to Fix It

1. Why Is My DNS Not Propagating?

Quick Answer: DNS propagation is not a broadcast. Your new record is live the moment it is saved at the right DNS host, but internet providers and devices keep the old answer until its cache timer (TTL) runs out. “Not propagating” usually means an old cache, or a record edited at a DNS host your domain no longer uses.

Think of DNS as the internet’s phone book. When someone types your domain, their internet provider asks your DNS host for the address and then saves that answer for a set time. Google’s DNS basics guide for Workspace admins puts it simply: a record’s current TTL decides how long any change you make now takes to go into effect.

So DNS propagation is really thousands of saved copies expiring one by one. That explains the mixed results:

• Your phone on mobile data may ask a provider whose saved copy has expired, so it shows the new site.
• Your office Wi-Fi router may still hold the old answer, so it shows the old site.
• Your browser keeps its own short cache on top of that.

The real problem cases are different. If a public lookup still shows the old value many hours later, the change was likely never applied where it counts.

2. What Stops DNS Changes From Showing? Causes Ranked by Likelihood

Quick Answer: The most common cause is editing records at the old DNS host after the nameservers were already moved elsewhere. Next comes a long TTL on the old record, then a nameserver change that was never saved at the registrar, then local caching, then typos such as a wrong IP or a missing www record.

When Malaysian business owners bring us a “stuck” DNS change, the cause is almost always one of five things.

The top cause catches many people out. Once your domain uses a new provider’s nameservers, the old provider’s DNS panel is ignored, even though it still lets you save changes.

If the domain shows a holding page from the registrar instead of your site, the records were never pointed at all; our guide to a domain showing a parked page covers that case.

3. How to Check DNS Propagation Properly

Quick Answer: Use Google Admin Toolbox Dig to look up the NS record first, then the A record. The NS result tells you which DNS host is in charge; the A result shows the address public DNS returns. If both show your new values, the change has propagated and any remaining issue is a local cache.

Don’t judge DNS propagation by refreshing your own browser. Run these checks in order:

1. Look up the nameservers. Open Google Admin Toolbox Dig, type your domain and choose the NS record type. Note the nameserver names shown.
2. Compare with your DNS host. Log in to the provider those nameservers belong to. That is the only panel where your edits count.
3. Look up the A record. Switch to the A record type. The IP shown should match the one your new host gave you. Repeat for www (often a CNAME).
4. Check the registry record. For .my domains, use the WHOIS lookup on MYNIC, the official .my registry, to confirm the nameservers and expiry date it holds.
5. Test off your network. Load the site on mobile data, with Wi-Fi turned off, in a private browser window.

If Google Search Console starts flagging host problems during this period, our guide to the DNS resolution error in Search Console explains what Googlebot is seeing.

4. How to Fix DNS That Is Not Propagating, Step by Step

Quick Answer: Make the change at the DNS host your nameservers point to, confirm the nameservers are saved at the registrar, correct any wrong or duplicate records, then flush Google Public DNS for your domain. Clear your own device cache last. Avoid changing records again while you wait, because each edit restarts the clock.

Work through this order. Each step removes one cause from the table above.

1. Edit at the right DNS host. Using the NS lookup, log in to the provider in charge and make your A, CNAME or MX change there. Leave the old provider’s panel alone.
2. Re-save the nameservers at the registrar. If the NS lookup still shows old nameservers, the change did not stick. Re-enter the new ones exactly, with no spaces or typos. Some .my registrars ask you to confirm by email; check the inbox listed on the account.
3. Remove conflicting records. Two A records for the same name, or an old AAAA (IPv6) record still pointing to the previous server, can send some visitors to the old site.
4. Add the www record. Create a CNAME for www pointing to your root domain, or an A record to the same IP, so both versions load.
5. Flush Google’s cache. Use Google Public DNS’s Flush Cache page. Google advises flushing the main domain first if the registrar or DNS hosting changed recently, then subdomains such as www.
6. Clear local caches. Restart the office router, run ipconfig /flushdns on Windows, and close and reopen the browser.
7. Re-check and wait. Run the NS and A lookups again. If public results are correct, wait for remaining caches to expire rather than editing again.

Once DNS propagation finishes, browsers may show security warnings if the new server has no certificate yet. See our guides to the SSL protocol error, SSL certificate “not private” warnings and mixed content warnings after HTTPS. Behind a proxy and seeing a timeout page? Read our fix for Cloudflare error 522.

5. How Long Does DNS Propagation Take?

Quick Answer: A record change at the right DNS host takes up to the old record’s TTL: one hour if the TTL was 3,600 seconds, a full day if it was 86,400. Nameserver changes take longer because the registry’s own records are cached too. Google’s crawler documentation allows up to 72 hours for DNS changes worldwide.

The wait depends on the TTL set before your change. Google’s guide to DNS and network errors for its crawlers notes changes can take up to 72 hours to spread.

In our experience, the realistic spread looks like this:

If a nameserver change has not shown on public lookups after 72 hours, stop waiting. Something is wrong at the registrar or DNS host.

6. What Else Breaks After a Domain Change?

Quick Answer: When you move to a new DNS host, only the records you copy across come with you. Email (MX), email security (SPF, DKIM, DMARC) and verification TXT records for Google and Meta are the ones most often left behind. Missing them stops email, ad tracking and Search Console access, even after the website itself works.

A new DNS host starts with an empty zone. These are the records we most often find missing:

Where to go next for each symptom:

• Email stopped. Re-add your MX records; see our guide to a business email not receiving messages.
• Someone sending as you. Missing DMARC invites abuse; read how to stop business email spoofing.
• Search Console locked. Restore the TXT record; see Search Console verification failed.
• Meta tracking dropped. Re-verify the domain via our guide to Meta domain verification failures; verified domains matter for Facebook ads tracking after iOS updates.
• Ads and catalogues stalled. Unreachable landing pages trigger disapprovals: check Google Shopping ads not showing and Meta catalog products getting no impressions.

7. How to Avoid DNS Propagation Problems Next Time

Quick Answer: Lower the TTL to 300 seconds at least a day before the change, export the full DNS zone before moving hosts, keep the old server running until the switch is complete, and make every change in one session. Afterwards, raise the TTL again once everything is stable.

Most DNS propagation headaches are avoidable with a little preparation:

• Lower TTL in advance. Drop it to 300 seconds 24–48 hours before the move, so the old long TTL has expired by switch day.
• Copy the whole zone. Screenshot or export every record at the old host, including TXT and MX, before you touch the nameservers.
• Keep the old site up. Visitors on stale caches still reach a working page while the change spreads.
• Batch your edits. Make all changes at once instead of drip-feeding them over days.
• Own the accounts. Keep the registrar and DNS logins under the company, with SSM details matching the domain record, not a freelancer’s personal email.
• Raise the TTL afterwards. Google’s guide suggests one hour while configuring, then 24 hours once settings are stable.

Changing the domain name itself carries bigger SEO risk; our domain name change SEO service covers redirects and rankings. Watch for redirect loops after migration, and see what to do if traffic crashed after a site migration. Rebranding? If Meta refuses your new name, read Facebook page name change rejected. Moving registrar too? Get your .my domain transfer code first.

8. When Should You Get Expert Help?

Quick Answer: Get help if public lookups still show old values after 72 hours, if you cannot log in to the registrar or DNS host, if the registrar rejects your nameservers, or if email and ads broke along with the site. These point to access or configuration problems that waiting will not solve.

Escalate in these situations:

• Locked out. The domain sits in a former vendor’s account and nobody has the login.
• Registrar errors. The registrar refuses the new nameservers, or the domain is on hold or close to expiry.
• Site completely down. Try our checklist for a website that is down and not loading, then call us.

ZenWeb is a Google Partner agency that has worked with 500+ Malaysian businesses. Our web design team manages domains, DNS and go-live for every site we build, so switch-overs happen without surprises.

9. Conclusion

DNS propagation that looks stuck is usually one of two things: an old cached answer that will expire on its own, or a change saved in a panel your domain no longer uses. Check the nameservers, confirm the A record on public DNS, fix it at the right host, flush Google’s cache and wait out the old TTL. Then check email and verification records before calling the job done. For more guides on keeping your business visible online, visit the ZenWeb home page.

10. Frequently Asked Questions

1. Can I speed up DNS propagation?

Partly. You cannot clear other providers’ caches, but you can flush Google Public DNS for your domain, clear your own router and computer caches, and lower the TTL before future changes. The old TTL still sets the upper limit for everyone else.

2. Why does my site work on mobile data but not on office Wi-Fi?

Your office network is still using a cached copy of the old DNS answer. The mobile network’s copy has already expired. Restart the router and flush your computer’s DNS cache, or simply wait for the old TTL to run out.

3. Is 48 hours normal for DNS propagation?

For a nameserver change, yes, it can be. For a simple A record change at the correct DNS host, 48 hours is too long unless the old TTL was very high. Check that you edited the record at the provider your nameservers point to.

4. Will DNS propagation affect my Google rankings?

A normal propagation window of a few hours rarely affects rankings. Problems start if the site is unreachable for days, or if the domain name itself changed without proper redirects. Keep the old server online until the change has fully spread.