You Bought Your Domain. Why Isn't It Working Yet?

Why isn't your brand-new domain working yet?

Because a domain doesn't 'turn on' the instant you pay for it. Buying a name and making that name load your website are two separate events, and several independent systems have to agree on the answer before a stranger's browser can find you. The registry has to publish that your domain exists and who runs its DNS; your DNS host has to be told which server your site lives on; and every resolver between your visitor and that answer caches whatever it learns for a while. Any one of those links being stale, wrong, or not-yet-done produces the same symptom — a name that just doesn't work — which is exactly why people reach for 'it's still propagating' as a catch-all.

The honest split is this: a fresh domain that's genuinely mid-propagation almost always resolves within a couple of hours today, not two days. So if it's been fifteen minutes, relax and read the rest of this to understand the wait. If it's been most of a day and nothing's moved, stop waiting — that's not propagation, that's a setup you need to correct.

What is DNS propagation, really?

It's not what the word implies. 'Propagation' sounds like your new record has to physically spread across the internet, server by server, like a rumor — which is why people imagine a global relay that legitimately takes days. That mental model is wrong, and it's the reason the 48-hour myth persists. Nothing crawls outward. Authoritative DNS updates in one place, essentially instantly.

What actually takes time is caching expiring. When a resolver (your ISP's, or Google's 8.8.8.8, or Cloudflare's 1.1.1.1) looks up your domain, it's allowed to remember the answer for a set number of seconds and hand that cached copy to everyone who asks in the meantime. 'Propagation' is really just the world's caches holding an old answer until their timers run out and they ask again. Once you understand that there is no spreading — only expiring — the whole process stops being mysterious and becomes a number you can actually look up: the TTL.

How long does it actually take in 2026?

For a newly registered name that was set up correctly, usually minutes to a couple of hours — not the mythical two days. Modern TLD registries publish new delegations to their zones extremely fast (many update within minutes), and mainstream DNS hosts and public resolvers use short cache timers, so a first-time domain with no prior history has nothing stale to wait out. The '24 to 48 hours' figure is a worst-case ceiling from an older, slower internet that registrars still quote to cover themselves, not the typical experience.

The genuinely slow case isn't a brand-new domain — it's changing something on a domain that was already live. If a name has been resolving for months and you repoint it, the old answer may already be cached far and wide with a long timer, and you'll wait out whatever TTL was in effect before you made the change. That's the scenario where 'up to 48 hours' can still bite. A first purchase almost never does.

What's a TTL, and why does it decide your wait?

TTL — 'time to live' — is a number attached to every DNS record that tells resolvers how many seconds they're allowed to cache it. A TTL of 3600 means 'trust this answer for one hour before checking again.' It is the single value that governs how long any DNS change takes to be seen everywhere, and almost nobody thinks about it until they're staring at a stubborn old record.

The practical trick that senior engineers use and beginners don't: lower the TTL before you make a change, not after. If you know you're about to repoint a live domain — moving hosts, switching to a new server — drop the record's TTL to 300 (five minutes) a day ahead of time. Then when you flip the record, the whole world's cache of the old answer expires within five minutes instead of an hour or a day. Once the change has settled, you can raise the TTL back up for efficiency. You can't retroactively speed up a change you already made — the old TTL is already ticking on cached copies — which is why the lower-it-first habit matters.

Why does the site work for you but not your co-founder?

Because 'the internet can see it' isn't one switch — it's a stack of caches at different layers, each expiring on its own schedule. Your machine caches DNS answers in the browser and in the operating system. Your router may cache. Your ISP's resolver caches. Your co-founder sits behind a completely different resolver on a different network with its own timers, so the two of you are genuinely looking at different snapshots of the truth for a while. This is normal and temporary, and it's the reason 'it works on my phone but not my laptop' is such a common half-launched-domain experience.

If you specifically want to see the new answer immediately without waiting on your own caches, you can flush them: clear your OS DNS cache (an ipconfig /flushdns on Windows, or dscacheutil -flushcache on macOS), restart the browser, or just check from a device on a different network like your phone on mobile data. But don't over-read your own local cache as the state of the world — the more reliable move is to check against public resolvers directly, which we'll get to.

When is it NOT propagation — and actually broken?

This is the part the 'just wait 48 hours' advice quietly ignores, and it's where most stuck domains actually live. A long list of setup mistakes produces the exact same 'doesn't load' symptom as propagation, except these never resolve on their own — you can wait a week and the name will still be dead. If it's been several hours with zero change, assume one of these rather than blaming the clock:

• Nameservers never changed. The domain is still pointing at the registrar's default parking nameservers, not your DNS host — so every correct record you added at your host is being ignored, because nobody's asking your host. This is the number-one cause of a 'connected' domain that shows a parking page.
• The domain is on registrar HOLD. New registrations require you to verify the registrant email (ICANN mandates it), and until you click that link the registrar can set the domain to clientHold — which removes it from DNS entirely. No amount of correct records will resolve a name that's on hold. Check your inbox for that verification email.
• Wrong or missing records. The A record points at the wrong IP, the record you needed (like www, or the apex) was never added, or you put a CNAME on the root domain — which the DNS spec doesn't allow, and which needs an ALIAS/ANAME or your provider's flattening instead.
• The site works but the certificate screams. The domain resolves fine, but you get an HTTPS warning — that's not DNS, it's your host still provisioning an SSL certificate, which is a separate step that often needs DNS to be correct first before it can even start.
• DNSSEC left over from a transfer. If you moved the domain between registrars and DNSSEC was enabled at the old one, a signature mismatch can make the name fail to resolve for everyone. It looks exactly like propagation and will never clear until you fix or remove the stale DNSSEC keys.

How do you check propagation without guessing?

Stop refreshing your own browser — it's the least reliable signal you have, because it's polluted by your local caches. The right move is to ask several authoritative and public sources directly and compare their answers. On the command line, dig @1.1.1.1 yourname.com and dig @8.8.8.8 yourname.com ask Cloudflare's and Google's resolvers straight; if they already agree with your new record, you're effectively done and the rest of the world is just a TTL behind. dig +trace walks the delegation from the root down and shows you whether the TLD is even pointing at the right nameservers — the fastest way to catch the 'nameservers never changed' problem above.

If you're not living in a terminal, use a lookup tool that queries the records for you and shows the live answer rather than your cached one. ZeroTaken's DNS and WHOIS lookups do exactly this: the DNS lookup shows what your name is currently resolving to from a neutral vantage point, and the WHOIS lookup shows the registration status and nameservers on record — which together tell you instantly whether you're looking at a normal cache wait or a real misconfiguration. Seeing the correct answer come back from a resolver that isn't yours is the only proof that actually matters.

What should you do in the first hour after buying a domain?

Most propagation panic is really just steps done out of order. If you set the domain up correctly and completely up front, the 'waiting' becomes a genuine short cache delay instead of a slow discovery of something you forgot. Do this pass right after checkout and you'll skip almost every stuck-domain scenario:

• Verify the registrant email immediately — click the confirmation link the registrar sends, so the domain never trips into clientHold.
• Point the nameservers at whoever is actually hosting your DNS (your site host, Cloudflare, wherever), and confirm the registrar saved the change.
• Add the records your host told you to add — typically an A record for the apex and a CNAME for www — and double-check the IP and target for typos.
• Expect a short wait, then verify against a public resolver (dig @1.1.1.1 or a lookup tool), not just your own browser.
• If it's still dead after a few hours, run down the 'not propagation' list above instead of waiting longer — the fix is almost always a wrong nameserver or an unverified email, not time.

So how long should you actually wait before you worry?

For a fresh domain you just registered and configured correctly: give it up to a couple of hours, and check against a public resolver rather than your own cache before you decide anything is wrong. Most of the time it'll be resolving within minutes, and the only thing left lagging is your own machine's DNS cache, which a flush or a phone-on-mobile-data check clears instantly. That's the ordinary, boring, working case — and it's most cases.

But hold the 48-hour excuse to a much higher bar. If public resolvers still can't see your record after several hours, propagation is not your problem — a misconfiguration is, and waiting will not fix it. Walk the checklist: are the nameservers actually changed, is the domain verified and off hold, is the A record right, is there stale DNSSEC from a transfer? The founders who lose a launch day to 'propagation' almost never had a caching problem — they had a setup problem hiding behind a caching excuse. Check the answer directly, and you'll know within minutes which one you've got.