What this symptom usually tells you
Start by identifying exactly which record was edited. An A-record change can move only IPv4 traffic, while an AAAA record can keep IPv6 visitors on another server. A CNAME change can affect only one hostname. If the nameservers did not change, the failure is usually narrower than a full DNS-zone migration.
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.
- Compare A/AAAA before and after — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
- Check authoritative nameservers — Compare the delegated nameservers with the servers that actually answer authoritatively; a record edited in a non-authoritative zone has no effect.
- Verify root and www separately — Verify verify root and www separately from the public Internet and compare it with the value the responsible provider says should be live.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for compare A/AAAA before and after, check authoritative nameservers, verify root and www separately 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 the current authoritative A, AAAA and CNAME answers with the destination supplied by the hosting platform. Restore or correct only the record that is wrong. Keep working MX and mail-authentication records untouched. If the new web host does not support IPv6, remove a stale AAAA only after confirming it is no longer required.
How to confirm this specific repair
Query the authoritative nameservers first, then compare public resolvers after the prior TTL has had time to expire. Test both the root domain and www over HTTP and HTTPS. A successful repair means both intended hostnames reach the new application and no address family still routes to the previous server.
A common wrong turn
Do not change nameservers merely because one A or CNAME record is wrong. That broad change can turn a website-only incident into an email outage. Also avoid treating a cached resolver answer as proof that the authoritative record is still incorrect.
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.