Website or Email Failed After a Cloudflare Nameserver Change: What to Do
What should a small business do if its website or email fails after changing nameservers to Cloudflare?
If a service fails after the nameserver change, identify whether it affects the root website, www, email or another named service. Record the symptom, then compare that service’s intended DNS entry, proxy status and relevant DNSSEC state with the Cloudflare zone and saved pre-change configuration. Ask the responsible provider to confirm the required value. Correct a verified discrepancy rather than changing unrelated records, and consider restoration only with known prior configuration, access and approval.
Classify the failure before editing DNS
Greatmail states that an improper DNS migration can lead to website downtime and email failures. Classify the failure as the root website, www, email or another named service, then record the affected hostname and observed result. Avoid changing unrelated records while the affected service and required configuration remain unconfirmed.
Sources: Switching DNS Providers? Don’t Break Your Email—Follow This Checklist - Greatmail Blog.
- Name the failed service first.
- Record the affected hostname and observed result.
- Avoid broad speculative DNS edits.
Check website hostnames and proxy status separately
Cloudflare warns that activation without correct DNS records can result in DNS_PROBE_FINISHED_NXDOMAIN errors for visitors. Compare the affected root domain or www entry independently with the Cloudflare zone, its planned proxy status and the saved pre-change configuration. If a hostname resolves but fails only while proxied, ask the website host or responsible technical owner to confirm origin compatibility before changing proxy status. Treat any proxy-status change as a controlled diagnostic action and document the result.
Sources: Change your nameservers (Full setup) · Cloudflare DNS docs.
- Check root and www as independent hostnames.
- Compare DNS values and proxy status with the migration plan.
- Ask the website host to confirm unclear settings.
Route email failures to the email configuration owner
Greatmail warns that DNS changes can disrupt email services when critical email records are not configured correctly. Preserve the observed email failure and ask the email provider or technical owner to confirm the required configuration. Keep email-related entries DNS-only and do not guess at replacements because there is no universal email record set for every provider.
Sources: Switching DNS Providers? Don’t Break Your Email—Follow This Checklist - Greatmail Blog.
- Preserve email errors and test observations.
- Contact the email configuration owner.
- Do not guess at replacement email entries or proxy them.
Check DNSSEC only against the planned transition
If failures began during a planned DNSSEC transition or DNS responses indicate a validation problem, compare the current Cloudflare and registrar state with the documented migration plan. Follow Cloudflare’s and the registrar’s current DNSSEC troubleshooting instructions, and ask their support channels to confirm any unclear required value. Do not repeatedly toggle DNSSEC or nameservers while the discrepancy remains unconfirmed.
- Compare the current state with the migration plan.
- Use Cloudflare’s and the registrar’s current DNSSEC instructions.
- Avoid repeated delegation or DNSSEC changes without a confirmed cause.
Use saved evidence before attempting recovery
Alpine Root reports that recovering a mail server required tracing WHOIS information, a related client domain and old nameservers that still held the original zone data. Use saved previous nameservers, zone captures, provider contacts and account access before attempting recovery rather than reconstructing an entry from memory. Document what has been confirmed, what remains unknown and who owns the next action.
Sources: Website Migration Checklist: Email & DNS Guide.
- Use saved nameservers and zone captures.
- Keep provider contacts and account access available.
- Build recovery from confirmed information.
Choose correction, escalation or restoration based on evidence
In an Alpine Root recovery case, the former provider had already purged its old zone after the nameserver change. Correct a Cloudflare entry only when a discrepancy is confirmed, and escalate when the required value remains unknown. Consider restoration only when the former configuration is known, relevant access exists and the responsible technical owner approves the action. Do not assume the former provider can recover the old zone, so base the decision on evidence retained before the handover.
Sources: Website Migration Checklist: Email & DNS Guide.
- Correct only confirmed discrepancies.
- Escalate unknown requirements to the responsible provider.
- Restore only with evidence, access and approval.
Service-based Cloudflare DNS incident decision tree
Use this decision tree after a nameserver handover. It directs each failure to the relevant service evidence and provider instead of encouraging broad DNS edits.
| Observed condition | Evidence to compare | Responsible owner | Next action |
|---|---|---|---|
| Root website or www returns a DNS error | Affected hostname, Cloudflare entry and saved configuration | Website host or technical owner | Confirm the intended DNS value and correct only a verified discrepancy. |
| Website resolves but fails only while proxied | Planned proxy status, origin details and provider confirmation | Website host or technical owner | Confirm origin compatibility before a controlled proxy-status test. |
| Email fails | Observed email result, Cloudflare entries and saved email information | Email provider or configuration owner | Confirm the exact required values; keep email-related records DNS-only. |
| DNSSEC validation appears relevant | Migration plan, Cloudflare DNSSEC state and registrar state | Cloudflare and registrar support | Follow current troubleshooting instructions and correct only a confirmed mismatch. |
| Another named service fails | Service name, intended entry, proxy status and provider information | Responsible service provider | Confirm the service requirement before changing DNS. |
| Former configuration is known and approved | Known former configuration, access and technical-owner approval | Responsible technical owner | Consider controlled restoration only with that evidence and approval. |
A correction requires a confirmed discrepancy. Restoration requires known former configuration, relevant access and approval from the responsible technical owner.
Related guidance
What follow-up questions matter most?
- What should I check first after a service failure?
- Start by naming the failed service: root website, www, email or another domain-dependent platform. Record the observed result, then compare that service’s intended entry with the Cloudflare zone and saved pre-change configuration.
- What if only a proxied website hostname fails?
- If DNS resolves but a proxied website fails, compare its proxy status and intended origin with the provider-confirmed plan. Temporarily changing status should be a controlled diagnostic action approved by the responsible technical owner, not a speculative fix.
- Who should confirm a failed email configuration?
- Contact the email provider or technical owner responsible for the service and ask for the exact required value. Preserve observed errors and test results instead of guessing at replacement records.
- What should I do if DNSSEC appears to be involved?
- Review the current Cloudflare and registrar DNSSEC status against the documented transition plan. Follow Cloudflare’s current troubleshooting instructions and avoid repeatedly changing nameservers or DNSSEC values without a confirmed discrepancy.
- When should I consider restoring the old setup?
- Consider restoration only when the former configuration is known, necessary access exists and the responsible technical owner approves the action. Old provider zone data may no longer be available.
What steps does this workflow follow?
Triage a post-change Cloudflare DNS incident
- Classify the affected service: Identify whether the failure affects the root website, www, email or another named service. Record the hostname or service name and the observed result.
- Compare evidence before editing: Compare the intended entry, proxy status and relevant DNSSEC state with the Cloudflare zone, migration plan and saved pre-change configuration.
- Choose the responsible owner: Send website values to the website host, email values to the email provider, third-party values to that service provider, and DNSSEC questions through Cloudflare’s and the registrar’s current procedures.
- Correct, escalate or restore: Correct only a confirmed discrepancy. Escalate unknown requirements to the responsible provider, and consider restoration only when the former configuration is known, access is available and the responsible technical owner approves it.