Why Is My DNS Not Propagating? 7 Causes and Fixes

You made a DNS change hours ago. Or yesterday. The change still isn't showing up — or it's showing up on some machines but not others, in some countries but not yours, in some browsers but not all. What's going wrong?

DNS propagation issues are frustrating because they look identical whether something is genuinely wrong or whether you just need to wait a bit longer. Here are the seven most common causes and what to do about each one.

1. You Haven't Waited Long Enough (Check the TTL)

The most common cause of apparent "stuck" propagation is simply that the TTL hasn't expired yet. Every DNS record has a TTL (Time To Live) value — the number of seconds resolvers are allowed to cache the record before fetching a fresh copy.

If your record had a TTL of 86400 (24 hours) before you changed it, resolvers that cached the old record moments before you made the change can legitimately serve the stale version for up to 24 hours.

What to check: Query the major public resolvers directly using our DNS Checker or with dig:

dig @8.8.8.8 yourdomain.com A

Look at the TTL in the response. If it's a large number (3600, 86400), that resolver cached the record recently and the full TTL must expire before it fetches the new value.

Fix: Wait. The maximum wait time is the TTL value that was on the record before you changed it. If you lowered the TTL before changing (best practice), the wait is much shorter.

Prevention: Before future DNS changes, lower the TTL to 300 (5 minutes) at least 24 hours before making the actual change. This dramatically reduces propagation time.

2. The Change Wasn't Saved Correctly at the Authoritative Nameserver

This is the most important thing to check first: did the change actually take effect at your DNS provider? A common scenario is making a change in a DNS control panel, navigating away, and not noticing that the change wasn't saved — or that the provider required a separate confirmation step.

What to check: Query your authoritative nameserver directly, bypassing all caching:

# First, find your authoritative nameservers
dig yourdomain.com NS

# Then query one of them directly
dig @ns1.yourprovider.com yourdomain.com A

If the authoritative nameserver still returns the old value, no resolver in the world will ever propagate the new value — because there is no new value to propagate. The problem is at the source.

Fix: Go back into your DNS provider's control panel and verify the record was actually saved. Look for the value you set, the correct record type, and the correct name. Make the change again if needed.

3. You Changed the Wrong Record or Subdomain

DNS zones can contain many records for many subdomains, and it's easy to update the wrong one. Common mistakes:

• Updated www.example.com but the site uses the root example.com (or vice versa)
• Updated an A record but the subdomain uses a CNAME, which points elsewhere
• Updated the record at the wrong domain (you manage several)
• Created a new record instead of editing the existing one — now there are two conflicting records

What to check: Use our DNS Checker to look up the exact hostname you're having trouble with. Check both example.com and www.example.com separately, since they can have different records.

Fix: Log into your DNS provider and review the full zone. Check for duplicate records, stale records pointing at the wrong place, or records you meant to change but didn't.

4. Your Local DNS Cache Still Has the Old Record

Even if all the major public resolvers have your new record, your own machine might still be returning the old result. Operating systems and browsers cache DNS responses independently based on the record's TTL.

What to check: Use an online tool or a different network (phone on mobile data, a colleague's machine) to verify what those systems see. If they see the new record but your machine doesn't, it's a local cache issue.

Fix — Windows:

ipconfig /flushdns

Fix — macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Fix — Chrome browser cache: Visit chrome://net-internals/#dns and click Clear host cache.

After flushing, test in an incognito/private window to avoid any remaining browser cache.

5. Your ISP's Resolver Is Violating TTL (TTL Non-Compliance)

Some ISP DNS resolvers cache records for longer than the TTL specifies. This is technically a violation of the DNS standard, but it happens, particularly with older or poorly maintained resolver infrastructure. If your record had a TTL of 300 but your ISP resolver is caching it for an hour, there's nothing you can do except wait or use a different resolver.

What to check: Test using a different DNS resolver to see if the issue is specific to your ISP's resolver. You can temporarily change your DNS settings to use Google (8.8.8.8 / 8.8.4.4) or Cloudflare (1.1.1.1 / 1.0.0.1) on your device or router.

Fix: Switch to a public resolver like Google or Cloudflare, or wait for the ISP's non-compliant cache to expire naturally. The ISP cache will eventually refresh.

6. NXDOMAIN Caching (Negative TTL)

This catches people off guard when creating new DNS records. When you visit a domain that has no records, the resolver receives an NXDOMAIN (non-existent domain) response and caches that negative result — for a duration set by the SOA record's minimum TTL value.

If you tested the domain before adding the record, some resolvers may have cached the NXDOMAIN response. Those resolvers will continue returning "no such domain" until the negative cache expires, even though the record now exists.

What to check: Use our DNS Checker to see whether any resolvers are returning NXDOMAIN for your domain after adding the new record.

Fix: Wait for the negative TTL to expire. You can check the SOA record to see how long this is:

dig yourdomain.com SOA

The last number in the SOA data is the minimum TTL (negative caching duration).

7. Nameserver Change Hasn't Propagated Yet

Changing the A record or MX record at your current DNS provider is different from changing which provider manages your DNS (the NS records). If you recently migrated to a new DNS provider and changed your nameservers at the registrar, that change — not just the individual records — needs to propagate.

Nameserver changes propagate through the root DNS servers and TLD registries. This typically takes 24–48 hours because the registrar updates the TLD zone, the root servers learn about the change, and resolvers gradually pick up the new NS records and start querying the new authoritative nameservers.

What to check: Check what nameservers different resolvers currently see for your domain:

# Use DNS Checker and select NS as the record type
# Or from command line:
dig @8.8.8.8 yourdomain.com NS
dig @1.1.1.1 yourdomain.com NS

If different resolvers return different nameservers, the NS change is still propagating. Resolvers that still have the old nameservers are querying the old DNS provider and will get the old records regardless of what you've set up at the new provider.

Fix: Wait for the NS change to propagate. Keep the old DNS provider's records in place during the transition — don't delete anything at the old provider until you've confirmed the NS change has fully propagated and the new provider's records are being served everywhere.

Quick Diagnostic Checklist

1. Check the authoritative nameserver directly — is the new record actually saved there?
2. Check the major public resolvers with DNS Checker — what do Google, Cloudflare, Quad9, and OpenDNS return?
3. Flush your local DNS cache and test in incognito
4. Verify you changed the right record (exact hostname and record type)
5. Check for duplicate records in your DNS control panel
6. Note the TTL — are you within the cache window of the old record?
7. If you changed nameservers, check NS propagation separately