What is DNS propagation
After a DNS record change, servers around the world cache the old value until the TTL expires. This is called DNS propagation — it can take anywhere from 5 minutes to 48 hours.
The term is a bit misleading: nothing is actually actively "propagating" anywhere. Your authoritative server returns the new value as soon as the record is saved. The delay only happens where some other resolver — at an ISP, in a browser, in an operating system — has already cached the old answer and keeps faithfully serving it to repeated queries until the TTL of the record that was set BEFORE the change runs out.
Checking via the command line
# Check the A record
dig yourdomain.com A
# Check via Google DNS
dig @8.8.8.8 yourdomain.com A
# Check via Cloudflare DNS
dig @1.1.1.1 yourdomain.com A
# Quick answer without cache
nslookup yourdomain.com 8.8.8.8
# Full resolution path from the root servers down
dig +trace yourdomain.com AThat last command is useful when it's unclear exactly where the chain is breaking: it shows which servers the resolver queried in sequence — from the root, through the top-level zone's server, down to your domain's authoritative NS — and at which step the answer diverged from what was expected.
Online tools
| Tool | Use |
|---|---|
| whatsmydns.net | Checks from 20+ locations worldwide |
| dnschecker.org | Global check of all record types |
| mxtoolbox.com | MX, SPF, DKIM, blacklist checks |
| intodns.com | Full DNS zone analysis |
The difference between these services and a local dig is that they query resolvers in dozens of countries at once and show you a map of actual propagation, rather than a single answer from the server nearest to you. That's handy for figuring out whether a change has propagated globally, or the delay is limited to your own provider.
How to speed up a DNS update
- Clear the browser's DNS cache:
ipconfig /flushdns(Windows),sudo dscacheutil -flushcache(macOS) - Clear the cache on Linux:
systemd-resolve --flush-caches - Check via mobile internet (a different DNS resolver)
One separate trap is negative caching. If a domain didn't exist before and a resolver already got an NXDOMAIN answer, that negative result gets cached too — per RFC 2308, for a period set by the minimum field in the zone's SOA record. A record you just created may be invisible for exactly this reason, not because of its own regular TTL.
Common Messages When Checking DNS
| Message | Meaning | Action |
|---|---|---|
| ;; connection timed out; no servers could be reached (dig) | The resolver is unreachable, or the wrong DNS server IP was given | Check that 8.8.8.8 responds at all, try a different resolver |
| ** server can't find yourdomain.com: NXDOMAIN (nslookup) | The name doesn't exist in the zone yet, or it has a typo | Check the exact spelling of the name and that the record exists in the panel |
| ;; ANSWER: 0 in dig's output | The requested record type doesn't exist for that name — for example, AAAA when there's no IPv6 | That's normal if a record of that type was genuinely never created |
| Chrome: DNS_PROBE_FINISHED_NXDOMAIN | Either the record hasn't propagated yet, or the domain isn't delegated | Check dig NS at both the registrar and the host |
In dig's output, three sections cover different things: ANSWER is the actual requested records, AUTHORITY is which servers are considered authoritative for that zone, and ADDITIONAL is supporting records such as the IPs of those servers. If ANSWER is empty but AUTHORITY is filled with an SOA record, that means the zone exists but this specific record doesn't — it's an NXDOMAIN for that record type, not for the domain as a whole.
How Long to Actually Wait, by Change Type
| What changed | Typical time | What it depends on |
|---|---|---|
| A/AAAA record with a 3600 TTL | up to 1 hour plus resolver caching | the record's old TTL before the change |
| NS delegation (changing name servers) | 2 to 48 hours | the NS record's TTL in the parent zone, usually 1–2 days |
| MX record | up to a few hours | the record's TTL and caching by sending mail servers |
| Registering a new domain | 15 minutes to a few hours | how fast the zone registry publishes it |
When Propagation Isn't the Issue
- Changes were made in the wrong zone — the domain is on external NS, but the edit happened in a different panel
- The browser or OS is holding its own DNS cache longer than the record's TTL — flushing the cache fixes it instantly, propagation has nothing to do with it
- A CDN or proxy, such as Cloudflare in Proxied mode, is returning its own IP instead of yours — that's expected behavior, not a propagation delay
- There's a typo in the record itself — no amount of waiting will make the correct answer appear, the configuration needs to be checked again, see checking a DNS zone with dig
Frequently asked questions
If you forgot to lower TTL before a DNS change, can anything speed things up after the fact?
Lowering TTL after the change is possible, but it will not help immediately: resolvers that already cached the old record with its old lifetime keep serving it until that lifetime runs out. The new, shorter TTL only applies to lookups cached after the change, so a real speedup shows up starting with the next refresh cycle rather than right away.
If a tool like whatsmydns.net shows the updated result, does that guarantee your own ISP sees the same thing?
No, such a tool queries many resolvers around the world, but not necessarily the exact one your ISP uses at that moment. A local resolver may have cached the old answer earlier and will keep serving it until its own TTL expires, regardless of external checks, so final confirmation still comes from a device connected through that specific provider.
Can propagation delay cause lost email, or does it only affect web traffic?
The delay affects any service that relies on a DNS record, including mail: if the MX record changed but the sending server still remembers the old value, a message will try the previous address and either get delayed or bounce back with a delivery error. Changing an MX record deserves the same careful planning as changing a site's A record.
Is it risky to change DNS records during business hours, or should it always happen at night?
The time of day itself does not matter much; what matters more is lowering TTL in advance and not changing several related settings at once, such as NS delegation together with the site's address. A nighttime window makes sense not because of anything DNS-specific but because fewer visitors notice if something goes wrong while the issue gets diagnosed and fixed.