DNS changes and caching
DNS changes can be correct immediately at the source while older answers remain cached elsewhere
This delay is usually caching, not data travelling between servers. Recursive DNS services remember previous answers for their time to live, or TTL. Nameserver changes also update delegation at the registry and can leave different networks seeing old and new answers for a period.
Why do different people see different results?
Cached record
A resolver may keep an old A, MX or CNAME answer until its earlier TTL expires.
Nameserver delegation
A nameserver change updates the parent registry or TLD delegation as well as the zone served by the new provider.
Local device cache
Browsers, operating systems and routers can temporarily remember a response after the wider resolver has changed.
Incomplete new zone
A genuine configuration error can resemble propagation. Missing email or verification records will not repair themselves with time.
How do I check whether the change is working?
- 1Confirm the authoritative nameservers
Check which nameservers the registry currently delegates the domain to.
- 2Query the intended record
Check the authoritative answer for the exact host and record type you changed.
- 3Compare public resolvers
Different results indicate caching. The same wrong result everywhere usually points to the source configuration.
- 4Test the actual service
Open the site over HTTPS and test incoming and outgoing email rather than relying on a single DNS checker.
How can I reduce disruption before a planned change?
| Before | Action |
|---|---|
| Record inventory | Copy the complete working zone, especially MX, SPF, DKIM and verification records |
| Lower TTL | Reduce relevant TTL values in advance where the current DNS provider permits it |
| Prepare new service | Configure the destination website, certificate and mail handling before switching traffic |
| Keep old service | Leave it available while caches may still direct visitors or mail there |
DNS timing questions
How long does propagation take?
It depends on the previous TTL, resolver behaviour and whether nameserver delegation changed. Check the authoritative answer and the old TTL instead of relying on one universal time estimate.
Will clearing my browser cache help?
It may remove a local copy but cannot clear a record held by your network resolver. Testing through another resolver or connection helps separate the two.
Can email arrive at both old and new servers?
During an MX change, different senders may temporarily use different cached answers. Keep both services able to accept mail during the transition where possible.
Check the source first
Confirm nameservers and the authoritative record
Once the source is correct, cached answers can expire naturally. If the source is wrong, update it rather than waiting.