What this symptom usually tells you
A nameserver change delegates the whole domain to a different DNS zone. The registrar may show the new delegation correctly while the new provider has an incomplete zone. Website, email, verification and subdomain records that existed only at the old provider stop being authoritative once the delegation changes.
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 active NS — Verify check active NS from the public Internet and compare it with the value the responsible provider says should be live.
- Compare old/new records — Verify compare old/new records from the public Internet and compare it with the value the responsible provider says should be live.
- Restore A/AAAA/CNAME — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for check active NS, compare old/new records, restore A/AAAA/CNAME 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
Inventory the old zone if it is still accessible and compare it with the new authoritative zone. Recreate the required web A, AAAA, CNAME or platform-verification records first, then separately restore MX and mail-authentication records. Avoid copying obsolete records simply because they existed in the old zone.
How to confirm this specific repair
Confirm the parent delegation names the intended nameservers and query each authoritative server directly for the important records. The root and www website should resolve consistently, and the mail checks should still identify the intended provider. Resolver differences should disappear as caches age out.
A common wrong turn
Editing records at the former DNS provider no longer changes public DNS after delegation moves. Another common mistake is importing only website records and forgetting MX, DKIM selector CNAME/TXT records or service-verification entries used by mail and SaaS products.
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.