Why Your Domain Isn't Pointing to Your Site: DNS Propagation Fixes

You updated the nameservers or changed an A record hours ago, and the domain still loads the old site, a parking page, or a blunt "this site can't be reached." Every help thread says the same unsatisfying thing: wait for propagation. So you wait, refresh, and nothing changes — because "propagation" is usually the wrong diagnosis, and waiting rarely fixes it.

The takeaway up front: DNS doesn't "spread" across the internet; it expires out of caches. A domain not pointing to the right site is almost always one specific, findable thing — a record edited at the wrong provider, a long TTL holding the old answer in a resolver, or a stale cache on your own machine. This guide shows you how to prove which one it is in minutes, then fix that layer instead of staring at a loading spinner.

What "propagation" actually is

There is no master DNS server that pushes your change outward. Instead, thousands of independent resolvers (your ISP's, Google's 8.8.8.8, Cloudflare's 1.1.1.1, your router, your browser) each cache a record for as long as its TTL (time to live) allows — a number of seconds attached to every record, say 3600 for one hour or 86400 for a full day.

When you change a record, the authoritative server updates instantly. But every resolver that already fetched the old value keeps serving it until its cached copy ages out. "Propagation" is just the staggered expiry of those cached copies — not a transmission. You can't speed up the internet, but you can find out whether you're genuinely waiting on TTL or chasing a problem no waiting will solve.

First, prove the authoritative answer is correct

Before blaming propagation, confirm the change is live at the source. The authoritative server is the one your nameservers delegate to; query it directly and you bypass every cache between you and the truth. Use dig on macOS or Linux, or nslookup on Windows.

dig @1.1.1.1 example.com A +short

# What your domain's authoritative nameserver returns (the source of truth):
dig example.com NS +short          # find the nameservers first
dig @ns1.yourhost.example example.com A +short

Read the result like this:

• Authoritative returns the NEW value, public resolvers return the OLD one. Real, normal propagation — the change is correct, caches just haven't expired. Skip to the TTL section.
• Authoritative STILL returns the old value. Not propagation at all — your edit never took effect at the source: wrong provider, wrong record, or unsaved change. Fix it; no waiting helps.
• Authoritative returns nothing / SERVFAIL. The delegation is broken, often a nameserver change that hasn't completed at the registrar. Check nameservers next.

This single check splits every "DNS not propagating" case into real wait versus broken config — and most stuck domains are the second kind.

The usual real cause: you edited DNS in the wrong place

A domain has two layers people constantly conflate. The registrar is where you bought the name and where the nameservers are set. The DNS host is whoever those nameservers point to — and that's the only place your A, CNAME, MX, and TXT records actually take effect.

The classic case of a nameserver change not working: you point the registrar's nameservers at a new host, then edit the A record back at the registrar's DNS panel — which is no longer authoritative. Or the reverse: you set records carefully at your hosting DNS, but the registrar's nameservers still point elsewhere, so the world never reads them.

To untangle it:

1. Find the live nameservers with dig example.com NS +short (or nslookup -type=ns example.com). Whatever comes back is in charge of your DNS right now.
2. Edit records only at that provider. If dig shows ns1.somehost.com but you've been editing at your registrar, you've been editing a panel nobody reads — move your changes there.
3. If you meant to switch hosts, confirm the registrar's nameservers match the new host's exactly, and recreate your records at the new host before the switch completes — so there's never a window with no records.

This is also where people lose email: switch DNS hosts and forget to recreate MX (and any SPF/DKIM TXT records), and mail breaks even though the website looks fine. Cutting DNS over carefully is the riskiest step of any move — the same discipline in our guide to migrating a website without downtime.

When it's genuinely TTL: shorten the wait next time

If your authoritative server returns the new value and only downstream caches lag, you've confirmed a true TTL wait. There's no button to flush the whole internet, but two things help.

• Lower the TTL before a planned change. Drop the record's TTL to 300 seconds (five minutes) a day or two ahead of a migration. Resolvers then re-fetch every five minutes, so when you flip the value the old answer ages out fast. Raise it back afterward to reduce lookup load. This is the single most effective tactic — but it only works as preparation, never retroactively.
• For an unplanned change, wait out the old TTL. Whatever the record's TTL was before you edited it is the worst case a resolver can keep serving the stale value — an 86400 TTL means up to 24 hours in the slowest caches. Knowing the prior TTL turns an open-ended "how long?" into a concrete ceiling. A global "DNS checker" site queries resolvers in many regions at once, so you can watch the new value roll out instead of guessing.

When the world is fine but your machine isn't

Sometimes every public checker shows the correct record and the site loads for everyone else — but not for you. That's local caching, the easiest layer to fix because you control it entirely: flush the DNS cache, restart the browser, and rule out your router.

• Flush the OS DNS cache. Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux varies (e.g. resolvectl flush-caches).
• Restart the browser, or test in a private window. Browsers keep an internal DNS cache that can outlive an OS flush.
• Bypass your router and ISP by temporarily setting your device's DNS to 1.1.1.1 or 8.8.8.8. Home routers and some ISPs cache aggressively and ignore short TTLs.
• Check your hosts file. A leftover line pinning the domain to an old IP (common after local development) overrides DNS entirely. It lives at C:\Windows\System32\drivers\etc\hosts or /etc/hosts.

If flushing your own caches makes the new site appear, the DNS change was never the problem — your machine was just holding an old answer.

FAQ

How long does DNS propagation take?

At most, as long as the record's previous TTL: a one-hour TTL means roughly an hour for nearly all resolvers, a 24-hour TTL up to a day in the slowest caches. Most users see the change far sooner. There's no fixed "48 hours" rule — that figure is a conservative cushion, not a requirement.

Why does my domain work for some people but not others?

Each resolver caches independently and expires on its own clock. A visitor whose resolver already dropped the old record sees the new site; one whose resolver still holds it sees the old one. It evens out as caches age past the TTL. If you specifically are stuck while public checkers look correct, it's your local or ISP cache, not real propagation.

Can I force DNS to update faster?

You can't flush every resolver on the internet, so a change already made has to wait out the old TTL. What you can do is prepare: lower the TTL before a planned change so caches turn over quickly. Locally, flush your own OS, browser, and router caches to see the new value right away on your machine.

I changed my nameservers and the site still won't load. What's wrong?

Run dig example.com NS +short and confirm the live nameservers match the new host. If they don't, the registrar change hasn't completed or wasn't saved. If they do but the site still fails, your A/CNAME records probably weren't recreated at the new host — the nameservers point to a DNS host that has no record for the name yet. Recreate them there.

Next step

Stop refreshing and start diagnosing. Query the authoritative nameserver to learn whether you're in a real TTL wait or editing the wrong panel, confirm the live nameservers match the host you intend, and recreate every record — A, CNAME, and MX — at the provider those nameservers point to. Get those three right and "propagation" stops being a mystery and becomes a countdown with a known ceiling. Want DNS and nameservers handled clearly instead of guessed at? Point your domain with confidence on Just-Server.