DNS Propagation Explained: Why Your New Site or Email Isn’t Showing Yet

DNS propagation is often blamed when a website or email service behaves differently after a DNS change. However, waiting will help only when a resolver has cached an old answer. It will not fix an incorrect authoritative record, broken nameserver delegation, invalid DNSSEC configuration, or a server that is not ready for the domain.

This guide explains where DNS delays occur, how TTL affects common record changes, and how to distinguish normal caching from a configuration problem. The goal is to help you decide what to test, when to wait, and which system needs attention.

What DNS propagation really means

DNS propagation is not a process in which a new record is copied across the internet. The term describes the period during which recursive resolvers and local caches may return different answers after a DNS change.

Suppose example.com moves from 192.0.2.10 to 198.51.100.20. The authoritative nameserver may already return 198.51.100.20, while an ISP resolver still has 192.0.2.10 cached. Users of that ISP may reach the old hosting account, while users whose resolvers request a fresh answer reach the new one.

There is no universal propagation percentage or global countdown. Each cached answer has its own remaining lifetime.

Observed symptom	Likely layer	What it may mean	Can waiting help?
Old website still loads	Recursive or local cache	The old address may still be cached	Yes
New record is missing	Authoritative DNS or negative cache	The record may be unpublished or cached as absent	Sometimes
Different networks get different answers	Recursive resolvers	Caches are expiring independently	Yes
DNS is correct, but the server returns an error	Hosting, CDN, or application	DNS already points to the destination	No
Email reaches the old provider	MX-related cache	Some senders may still use old routing data	Yes, if authoritative MX is correct

The first question should always be whether the authoritative nameserver returns the intended value. If it does, caching may explain differences elsewhere. If it does not, waiting will not publish the missing or incorrect record.

Understanding how web hosting works can also help separate DNS resolution from problems on the server receiving the request.

Where an old DNS answer can remain cached

A DNS lookup can involve several layers. Your browser or application relies on the device’s DNS facilities, which may have a local answer. The device typically forwards unresolved queries to a recursive resolver operated by an ISP, employer, VPN provider, or public service such as Google Public DNS, Cloudflare, or Quad9.

If the recursive resolver has a valid cached answer, it can return that answer without contacting the authoritative nameserver. Otherwise, it follows the domain’s delegation from the DNS root to the relevant top-level domain and then to the authoritative service.

Possible sources of stale information include:

• Browser or application: May retain DNS-related state, cached pages, or redirects.
• Operating system: May cache DNS answers locally.
• Router or local network: May provide or forward DNS resolution for connected devices.
• Corporate network or VPN: May apply its own resolver and DNS policies.
• Recursive resolver: May return an older answer while the cached entry remains valid.
• Authoritative DNS: Publishes the source records and must contain the intended value.
• CDN or application cache: May serve old content even after DNS resolves correctly.

The practical task is to determine whether the old information is a DNS answer or content returned after DNS resolution has completed.

Why two visitors can reach different websites

Two visitors can request the same hostname seconds apart and reach different servers. One resolver may have just refreshed its cache, while another can still reuse its previous answer until that entry expires.

Physical location is not the only factor. A phone on mobile data, a laptop on office Wi-Fi, a home connection, and a device connected through a VPN can all use different recursive resolvers.

Compare the result from your normal resolver with independent services such as Google Public DNS, Cloudflare, and Quad9. Disagreement does not automatically mean a resolver is broken; the services may have cached the record at different times.

Why clearing one device does not update other networks

Clearing a browser cache or flushing the operating system’s DNS cache affects only that device. It cannot remove an answer cached by an ISP, company network, VPN, or public recursive resolver.

Use the scope of the problem to narrow the cause:

• If one browser is affected, inspect browser and application caching.
• If one device is affected across multiple browsers, inspect its local DNS state.
• If several devices on one network are affected, test that network’s resolver.
• If independent resolvers return old and new DNS values, caching remains plausible.
• If DNS answers agree but an old page remains, investigate the CDN, web server, or application cache.

What controls DNS propagation time

The useful timing question is not simply how long propagation takes. Ask what was cached before the change, what TTL applied at that time, and whether you changed a record, created a new name, or replaced the domain’s nameservers.

TTL influences refresh timing

TTL, or time to live, tells a recursive resolver how long it may cache a DNS answer before refreshing it. A TTL of 3600 seconds permits approximately one hour of caching. It does not guarantee that every resolver will switch exactly one hour after an edit.

During a migration, the old TTL is usually the important value. If an A record had a 24-hour TTL, lowering it to 300 seconds immediately before changing the IP does not shorten copies already cached under the 24-hour value. For a planned cutover, lower the TTL at least one old-TTL period before changing the destination.

Very low TTLs increase query frequency and are not an absolute freshness guarantee. Resolver software may apply cache policies, and RFC 8767 describes circumstances in which a resolver may serve stale data when authoritative servers are temporarily unreachable.

What changed	Main timing factor	What users may observe	Keep the old service active?
A or AAAA	Previous record TTL	Some visitors reach the old address	Yes
CNAME	CNAME TTL and downstream record TTLs	Users follow different alias paths	Yes
MX	Previous MX TTL	Some senders use the former mail system	Yes
Nameservers	Parent delegation and resolver caches	Resolvers query different DNS providers	Yes
TXT record	Previous TXT TTL	Verification or authentication results differ	Where applicable
Newly created record	Negative-cache lifetime	Some resolvers still report no record	Not applicable

Nameserver changes are often assigned an operational window of up to 24–48 hours, but that range is not a DNS guarantee. Actual behavior depends on cached delegation data, authoritative availability, and whether both DNS providers serve a complete zone.

Negative caching can delay a new record

A newly created hostname can be correct on the authoritative nameserver while some users still receive an absent-name or absent-record response. This happens when a resolver queried the name before it existed and cached the negative answer.

NXDOMAIN means the queried name does not exist. DNS can also return a negative answer when the name exists but has no record of the requested type. Under RFC 2308, the negative-cache lifetime is derived from the zone’s SOA data, generally using the lower of the SOA record’s TTL and its MINIMUM field.

Publishing the record does not recall negative answers already held by resolvers. Those resolvers may continue returning the cached absence until its lifetime expires.

Why a website can remain broken after DNS updates

A correct A, AAAA, or CNAME result proves only that the hostname resolves to the intended destination. It does not prove that the destination has the correct virtual host, certificate, files, database, redirects, or application settings.

Symptom	Can DNS be correct?	Likely layer	Evidence to collect
Old site content	Yes	Server, CDN, or application cache	Response headers and origin address
Default server page	Yes	Virtual host or site mapping	Destination IP and requested hostname
Wrong certificate	Yes	TLS, CDN, or site mapping	Certificate names, issuer, and hostname
404 response	Yes	Web server or application	Requested URL and server logs
500 response	Yes	Application, PHP, or server	Error logs and application logs
Redirect loop	Yes	Application, CDN, or web server	Full redirect chain
IPv4 and IPv6 behave differently	Yes	DNS or origin configuration	Separate A and AAAA results
Stale page from a CDN	Yes	CDN cache	Cache headers and direct-origin test

Once independent DNS lookups return the intended destination, waiting for DNS caches will not fix a certificate mismatch, HTTP 500 response, redirect loop, or incorrect server mapping.

Check A and AAAA separately

An A record provides an IPv4 address, while an AAAA record provides IPv6. If a domain has a new A record but an old AAAA record, IPv6-capable visitors may still reach the former server.

That split can resemble regional propagation. Verify both record types and confirm that every published address is meant to serve the site. Do not remove AAAA as a generic troubleshooting step; update or remove it only when the published IPv6 destination is incorrect or unsupported.

Test the apex domain, such as example.com, separately from www.example.com. Updating one does not update the other, and a redirect can obscure which hostname is misconfigured.

Account for WordPress migration risks

A WordPress cutover is complete only when DNS and the application both point to a prepared environment. The destination needs current files and database content, correct WordPress Address and Site Address values, SSL coverage for every public hostname, and compatible redirect rules. Application and CDN caches may need purging after the final synchronization.

For WordPress migrations, SiteValley shared hosting starts at $30 per year for the Newbie plan. All listed shared plans include cPanel, free SSL, Free DNS Anycast, daily backups with 60 recovery points, and one-click CMS deployment.

Sites accepting orders, registrations, comments, or form submissions require extra care. During a split-traffic period, the old and new copies may both receive database writes. Data submitted to the old server after the final database copy will not automatically appear on the new server.

Prepare and test the destination first, take a final backup, control or synchronize writes during the cutover, and keep the old origin available until traffic has converged. A phased website migration checklist can help coordinate DNS, application testing, backups, and rollback planning.

Why email DNS changes need separate checks

An email cutover has two jobs: routing new messages to the intended system and ensuring that the system is ready to receive them. Changing MX records handles routing only. It does not create mailboxes, copy old messages, recreate users, or transfer passwords and client settings.

MX changes do not move mailbox data

MX records tell sending mail systems where to attempt delivery. During a transition, some senders may still use a cached MX record and deliver to the former provider. If users check only the new inboxes, successfully delivered messages on the old system can appear to be missing.

MX priority does not divide traffic between providers. Lower numbers indicate preferred destinations; higher-numbered targets normally act as fallbacks when delivery to a preferred destination cannot be completed.

SMTP senders commonly queue messages after temporary 4xx failures and retry later. Retry schedules and queue lifetimes vary, so no fixed delivery time can be guaranteed.

Validate authentication records independently

SPF, DKIM, and DMARC are separate DNS mechanisms. Correct incoming routing does not prove that outgoing mail is authenticated.

Record	Purpose	Common failure symptom	Verification evidence
MX	Routes incoming mail	Mail reaches the old system or delivery fails	MX lookup shows intended targets and priorities
SPF	Authorizes sending infrastructure	SPF fails or mail is filtered	Received headers show spf=pass
DKIM	Verifies a sender-added signature	DKIM fails or is absent	Headers show dkim=pass for the domain
DMARC	Applies policy using aligned SPF or DKIM	DMARC fails and policy affects handling	Headers show dmarc=pass

During an email migration:

• Keep the old mailboxes accessible while cached MX answers may remain.
• Create all users and required mailboxes at the destination before changing MX.
• Test inbound delivery from an unrelated external mail service.
• Send outbound messages and inspect their headers for SPF, DKIM, and DMARC results.
• Validate every active DKIM selector rather than checking only the domain’s MX record.

If mail is missing, check both systems first. If mail arrives but fails authentication or enters spam, investigate the relevant SPF, DKIM, or DMARC configuration instead of waiting for MX caches.

Nameserver changes, DNSSEC, and CNAME chains

Some failures resemble slow propagation but are structural. Nameserver changes replace the service authoritative for the entire zone, DNSSEC can cause validating resolvers to reject otherwise visible answers, and CNAME chains introduce multiple cacheable records.

A nameserver switch changes the delegation

Changing an A record edits data inside the current zone. Changing nameservers at the registrar updates the parent-zone delegation so resolvers are directed to a different authoritative service.

The new DNS provider must contain a complete zone before the switch. When a nameserver is inside the domain it serves, such as ns1.example.com for example.com, the parent may also require a glue record containing the nameserver’s IP address.

Keep the old DNS zone operational and serving equivalent records during the transition. Resolvers with cached delegation data may continue querying the previous nameservers.

DNSSEC can turn a migration into SERVFAIL

DNSSEC establishes a chain of trust between the parent and child zones. The parent publishes a DS record identifying the key expected from the child, while the authoritative service publishes the corresponding DNSKEY records and signatures.

If a migration leaves the former provider’s DS record at the registrar while the new provider uses different keys, validating resolvers can reject the response and return SERVFAIL. A non-validating query may still display the intended A record, which can make the failure confusing.

Persistent SERVFAIL after a nameserver change requires checking the registrar’s DS data, the new provider’s signing configuration, and authoritative availability. Waiting cannot make mismatched keys agree.

Result or symptom	Likely layer	Can waiting help?	Evidence to collect
NXDOMAIN	Name existence or negative cache	Sometimes	Hostname, record type, resolver, and authoritative result
SERVFAIL	DNSSEC or authoritative failure	Usually not if persistent	DNSSEC status and direct authoritative results
Timeout	Network or authoritative server	Possibly if transient	Nameserver, timestamp, and timeout output
REFUSED	Authoritative policy or configuration	No	Query, nameserver, and returned response
Correct DNS with TLS failure	Certificate, CDN, or web server	No	Certificate error and hostname
Correct DNS with HTTP failure	Web server or application	No	Status code, URL, and response headers

Trace the complete CNAME chain

A CNAME can point to another hostname that has its own CNAME, A, or AAAA records. Each link can have a separate TTL and cache state. One resolver may hold an old first-stage alias while another has the new alias but an older downstream destination.

Trace the full chain rather than checking only the initial hostname. Otherwise, a stale downstream record can remain hidden behind a correct-looking CNAME.

What global DNS checkers can prove

A global DNS checker samples selected resolvers or probes. It does not query every ISP, office network, VPN, device, or application on the internet.

Checker pattern	Strongest reasonable conclusion	What it does not prove
Mostly the new value	The change is widely visible among sampled systems	Every user sees it or the destination works
Mixed old and new values	Different caches may contain different valid answers	Every difference is normal caching
Consistently wrong or absent	The source record or query may be incorrect	More waiting will produce the intended value

Before interpreting a green result, confirm the expected answer directly from the authoritative nameserver. Agreement is useful only when the returned value is correct.

Check the exact hostname and record type. Query the apex and www separately, test A and AAAA independently, and follow CNAME chains. For email, inspect the MX record and resolve its target hostnames as needed.

Changing your device from an ISP resolver to Cloudflare or Google Public DNS may reveal a newer answer, but it does not clear the ISP’s cache or update other networks.

When to wait and when to troubleshoot

Waiting is reasonable when the authoritative nameserver returns the intended value, the old response remains within its previous TTL, and recursive resolvers return a changing mix of the expected old and new values.

Evidence	Decision
Authoritative DNS is correct, but some resolvers return the old value within its old TTL	Wait: caching remains credible
Authoritative DNS returns a wrong or missing value	Fix DNS configuration: waiting will not publish the intended record
The registrar delegates to unintended nameservers	Fix delegation: confirm the nameservers at the registrar
Persistent SERVFAIL follows a nameserver change	Inspect DNSSEC and authoritative availability
Authoritative and recursive answers are correct, but the website or mailbox fails	Inspect the destination service

A useful support request should include:

• The exact hostname, such as www.example.com.
• The record type being investigated.
• The expected value and observed value.
• The date, time, and timezone of the change.
• A result queried directly from an authoritative nameserver.
• Results from at least two independent recursive resolvers.
• The exact DNS, browser, TLS, HTTP, or mail error.

Do not include account passwords, control-panel credentials, or mailbox passwords. Clear evidence allows the DNS provider, registrar, or web hosting provider to reproduce the issue and identify the responsible layer.

Conclusion

DNS propagation is best understood as cache expiration, not a global synchronization event. The decisive test is whether the authoritative nameserver publishes the intended record. If it does and some resolvers still return the previous answer within its former TTL, waiting may be appropriate.

If the authoritative record is wrong, delegation points elsewhere, DNSSEC returns persistent SERVFAIL, or the destination produces a certificate, HTTP, WordPress, or mailbox error, more waiting will not solve the problem. Test the source record first, compare recursive resolvers second, and then verify the destination service. That sequence turns a vague propagation complaint into a specific, actionable diagnosis.