How long does DNS propagation take? Diagnose it in five steps
Usually minutes for a brand-new record, and up to the old record's TTL for a changed one, which is commonly an hour and occasionally a day or more. Nothing actually spreads across the internet: resolvers keep cached answers until they expire. So the first job when a change "isn't working" is to check the record at its source. If it's wrong there, no amount of waiting fixes it.
What "propagation" really is
When you save a record, the authoritative nameservers for your domain start serving the new value almost at once. Everyone else gets their answer from a resolver, and resolvers cache what they've already looked up for as long as the record's TTL (time to live) allows. RFC 1034 defines that limit: a cached record may be kept until its TTL runs out, then must be fetched again. Propagation is just the old cached answers expiring, at different moments, in resolvers all over the world.
There's one more cache to know about. If someone looked up your new name before you created it, their resolver may have cached "this name doesn't exist". RFC 2308 sets how long that negative answer is kept: the lesser of the SOA record's minimum field and the SOA record's own TTL. That's why testing a name before adding it can make it seem slow to appear.
Diagnose it in five steps
- Find your real DNS host. Run
dig example.com NS +short(ornslookup -type=NS example.comon Windows). Records only count at the provider those nameservers belong to. - Ask the authoritative server directly. Run
dig @ns1.yourdnshost.com www.example.comwith one of the nameservers from step 1. This skips every cache. If the answer is wrong or missing here, the record is wrong: fix it, and stop waiting. - Ask a public resolver. Run
dig @1.1.1.1 www.example.comanddig @8.8.8.8 www.example.com. If they show the old value, look at the TTL number in the answer: that's how many seconds until they drop it. - Clear your own caches. Browsers and operating systems cache too. On Windows run
ipconfig /flushdns; on macOS,sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Then try a private window. - Try a different network. A phone on mobile data uses a different resolver from your home wifi. If the site works there, the record is fine and your home resolver is still holding the old answer.
Slow or wrong? How to tell
| Symptom | Likely cause |
|---|---|
| Authoritative server shows the old value or nothing | The record wasn't saved, is at the wrong DNS host, or the name field is wrong |
| Authoritative is right, public resolvers show old value | Normal caching; wait out the TTL shown |
| Works on mobile data, not on wifi | Your home or office resolver is still caching |
Name shows as www.example.com.example.com | The DNS panel added the domain for you; enter just www |
| Right address, but a certificate warning | DNS is done; the host is still issuing the HTTPS certificate |
| Nothing changes after several days | A mistake, not propagation: recheck step 2 |
Make the next change faster
- A day or two before a planned change, lower the TTL on the record you'll change to 300 seconds (five minutes).
- Wait at least as long as the old TTL, so caches pick up the short one.
- Make the change. Most resolvers will see it within about five minutes.
- Once everything works, raise the TTL again, to an hour or more, to reduce lookups.
This doesn't help with a change you've already made under a long TTL: the old value is cached with its old expiry. The "up to 48 hours" you'll often read comes from long TTLs common in the past, and from nameserver changes, whose records at the registry level often have longer TTLs than ordinary records.
Mistakes that look like propagation
- Two records for the same name, such as an old A record left beside a new CNAME.
- A typo in the target, often a missing or extra character in a long verification value.
- A trailing dot in the wrong place, or a value pasted with spaces.
- A proxy setting at the DNS host that answers with its own addresses instead of your record.
- Changing records at the registrar while the nameservers point to another DNS host. The how DNS works explainer covers why.
With an Anticode custom domain
When you connect a domain in Anticode, the Domains section shows the records to add and a status. It reads Waiting for DNS until the records are found, and Live once ownership is verified and the certificate is issued; Check again re-checks on demand. If it stays waiting, run step 2 above against your DNS host before anything else. The full setup is in how to connect a custom domain. Anticode can't change records at your DNS host or shorten another resolver's cache; those sit with your DNS provider.
Questions people ask
Can I speed up propagation after making a change?
Not for other people's resolvers. You can clear your own caches, and some public resolvers offer a page to purge a cached name, but the rest expire on their own schedule.
What TTL should I use?
An hour is a reasonable everyday value. Drop to five minutes before a planned change, then raise it again afterwards.
Why does a propagation checker show mixed results?
Each location queries a different resolver with a different cache. Mixed results with the correct value at your authoritative server mean you're simply waiting.