Why isn't my domain working yet? DNS propagation, explained
By Domain Yoga · Last updated July 20, 2026
You bought the domain, or you changed a DNS record, and now you’re refreshing a blank page wondering what you broke. Almost always: nothing. DNS changes aren’t instant. The internet caches DNS records, so after you point a domain or edit a record it takes a while before everyone sees the new answer — usually minutes to a few hours, occasionally up to 24–48 hours. That gap is normal and expected, not a sign you did something wrong. Here’s why it happens, and a calm checklist to work through while it settles. (If terms like record, nameserver, or zone are a blur, our domain glossary defines them in one place.)
Why does a DNS change take time to work?
When your browser needs to turn yourname.com into a server address, it doesn’t ask the authoritative source every time. It asks a resolver — run by your internet provider or a public service — which keeps a copy of the answer for a set period so the next lookup is instant. That copy is a cache; the set period is the record’s TTL (time-to-live), measured in seconds.
Here’s the part that trips people up: the TTL that matters is the one in place before you made the change. If a record’s TTL was set to 24 hours, a resolver that fetched it an hour ago will keep serving the old answer for another 23 — no matter how quickly you clicked save. It’s doing exactly what the previous TTL told it to. The new value is live at the source immediately, but caches around the world expire on their own schedules. That staggered expiry is what people mean by “propagation,” even though nothing is really travelling — old answers are simply timing out.
One more distinction worth knowing. Editing a record inside an existing DNS zone — changing an A record’s value, say — tends to settle relatively quickly. Changing your nameservers at the registrar, which moves the entire zone to a different DNS provider, propagates more slowly, because it depends on records held higher up at the TLD that often carry longer TTLs of their own. If you just switched nameservers, budget for the slower end of the range.
What should I check when a domain won’t load?
Most “it’s still not working” moments turn out to be one of the first two items below. Work through them in order.
Confirm the record is actually correct. Before blaming propagation, re-read what you typed. Is it the right type — an A record pointing at an IP address, or a CNAME pointing at a hostname? Is the value exactly what your host gave you, with no stray space or missing dot? A wrong record never “propagates” into a right one, so this is always the first check. Our first-hour checklist for a new domain and the domain glossary both cover what each record type is for.
Confirm you edited DNS in the right place. A domain’s DNS can be managed in more than one spot — the registrar where you bought it, a separate host, or a CDN in front. A very common cause of “nothing changed” is editing a zone that isn’t the live one — you update records at the registrar while your nameservers actually point at Cloudflare, so your edits sit where no one reads them. Find out which service holds the authoritative zone and edit there. (Where DNS lives varies by registrar; our guide to registrars for indie hackers notes who hands off DNS to whom.)
Rule out your own cache first. Before assuming the whole internet is behind, check whether it’s just you. Your operating system and browser keep their own DNS caches. Flush them, then test from a second network — your phone on mobile data is perfect, since it uses a different resolver entirely. (An incognito window rules out stale page and cookie caching, but not the DNS cache — that lives at the OS level, so flush it or switch networks.) If the site loads on your phone but not your laptop, the change has propagated fine and you’re only waiting on your own machine.
Look up what the world actually resolves. Instead of guessing, ask. A DNS lookup with dig or nslookup, or any online “DNS checker” that queries from multiple locations, shows the real answer being served right now. This separates the two situations that look identical from a blank tab: not propagated yet (checkers show the new value in some places, the old in others) versus wrong record (every checker agrees, on something you didn’t intend).
Check HTTPS and the certificate. If the site loads but shows a security warning, DNS is working — the TLS certificate just may not be issued yet. Many hosts auto-provision one once DNS resolves, so it often clears within minutes of the record going live. Note one sharp edge: on .dev and .app domains the browser forces HTTPS, so a missing certificate means nothing loads at all rather than a warning you can click past. If you’re on one of those, see .dev and .app domains for developers for what to expect.
Confirm the domain is active. Last, the unglamorous cause. A domain that has expired, or that a registrar has suspended or locked out of service, won’t resolve no matter how correct your records are. Log into the registrar and check the domain’s status and renewal date before you spend another hour on DNS that was never the problem.
When should I actually worry?
The honest threshold is simple. If it’s been well past 48 hours and a DNS checker still shows the old record — or a blank one — from multiple locations, this is no longer propagation. Caches have long since expired; something is misconfigured. Go back to the top of the checklist: re-read the record for the right type and value, and confirm you’re editing the zone your nameservers actually point at. Nine times out of ten the answer is hiding in one of those two places.
Until then, the best thing you can do is nothing. Make one correct change, verify it with a lookup, and let the TTL run its course rather than “fixing” a record that was right all along. And if the name itself still isn’t settled, Domain Yoga generates brandable, availability-checked options in seconds — so the only thing left to wait on is a cache.