What this symptom usually tells you
An old site appearing after a move means at least one public path still reaches the previous origin. The most common evidence is an A, AAAA or CNAME record that still identifies the old host, but an old CDN configuration or a cached pre-migration answer can produce the same visible symptom for only part of the audience.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the DNS resolution and delegation diagnosis rather than as a standalone health score.
- Check A/AAAA — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
- Check TTL — Compare independent resolvers or regional probes together with TTL. Different answers are evidence of cache/authority differences, not a reason to claim a fixed global propagation time.
- Compare authoritative and regional probes — Query the authoritative servers directly and compare their answers. This separates a stale recursive cache from inconsistent source DNS data.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for check A/AAAA, check TTL, compare authoritative and regional probes and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Compare every address record for the root and www with the new host’s documented targets. Check AAAA even when the A record is correct. If authoritative DNS already has the new destination, do not keep changing it; compare TTLs and resolver answers instead. Remove the old record only after confirming the new host serves the intended hostname.
How to confirm this specific repair
Authoritative DNS and independent resolvers should ultimately return the new endpoint, and HTTP/HTTPS should finish on the new application for both root and www. If an old server remains reachable by IP, that alone is not a DNS failure as long as the domain no longer points to it.
A common wrong turn
A CDN IP is not necessarily the origin host, so do not replace a valid proxy target with an origin IP simply to make addresses “match.” Also check for an overlooked AAAA record before blaming propagation.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed DNS resolution and delegation result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.