Where do I actually change the nameservers — in Cloudflare or at my registrar?

At your registrar, always. This is the single step that traps the most people. Cloudflare does not host your registration; it wants to become your DNS host, and the only way to hand it that job is to go to wherever you bought the domain (GoDaddy, Namecheap, Gabia, Google Domains, wherever) and replace the domain's nameserver records with the two Cloudflare assigned you. There is no 'point my nameservers here' button inside Cloudflare, because the authority to change NS lives with the registrar, not the DNS host. If you've been hunting for that setting in the Cloudflare dashboard, that's why you can't find it — you're looking in the wrong building.

Cloudflare still says 'Pending Nameserver Update' hours after I changed them. Did it fail?

Probably not — Cloudflare re-checks your domain's delegation on its own schedule and flips you to Active once it sees both of its nameservers answering for you. That's usually minutes but can take up to 24 hours, especially if the old nameservers had a long TTL on the delegation. Two things actually stall it rather than just slow it: you only replaced one of the two nameservers (or left an old one behind), or you entered the wrong assigned pair. Cloudflare gives each zone a specific pair — not a generic one from a tutorial — so re-open your dashboard, copy the exact two `*.ns.cloudflare.com` names it shows for this domain, and make sure those two, and only those two, are set at the registrar.

I moved to Cloudflare and now the whole domain throws SERVFAIL / won't resolve at all. What happened?

This is almost always leftover DNSSEC. If your previous DNS provider signed the zone, your registrar is still publishing a DS record that tells the world 'this domain is signed by that old provider's key.' The moment you delegate to Cloudflare, Cloudflare answers with different (or unsigned) data, the signatures no longer match the DS record, and every validating resolver refuses the answer — that's SERVFAIL, and it looks like the domain evaporated. The fix is to remove the old DS record at your registrar (turn DNSSEC off for the domain), wait for that removal to propagate, then either leave it off or re-enable DNSSEC inside Cloudflare and add the *new* DS record Cloudflare generates. Order matters: clear the old DS before, or as part of, the cutover — not after people are already seeing errors.

After the switch, some things work but email (or a subdomain) is gone. Why?

Because delegating to Cloudflare makes Cloudflare authoritative for your entire zone, and Cloudflare only serves the records it has. Its import scan when you add a site is best-effort — it catches common records but can miss MX, TXT (SPF/DKIM/DMARC), and records on hosts it didn't think to query. Anything it didn't import simply stops existing the instant the nameservers flip. The habit that prevents a bad afternoon: before you change the nameservers, screenshot or export your old zone, then compare it against Cloudflare's DNS tab and re-add anything missing — MX and the email TXT records first, since those fail silently.

Cloudflare Nameservers Not Updating? 4-Step Fix

Problem

You added your domain to Cloudflare, and now something is off. Maybe the dashboard has said “Pending Nameserver Update” for hours and won’t go Active. Maybe you can’t even find where to point your nameservers at Cloudflare. Or — the bad one — you changed the nameservers, and now the whole domain throws SERVFAIL or stops resolving entirely. The domain exists; you can see the zone sitting in your Cloudflare account. What’s broken is the handoff between three parties who all have to agree on one fact: who answers DNS for this name. Cloudflare makes this confusing in a very specific way, because the change it needs from you doesn’t happen in Cloudflare at all.

Symptoms

Cloudflare shows “Pending Nameserver Update” and never flips to Active.
You can’t find a “set my nameservers to Cloudflare” option inside the Cloudflare dashboard.
You changed the nameservers and, hours later, nothing happened — Cloudflare still waits.
The domain now returns SERVFAIL, or simply won’t resolve, right after the switch.
The site loads, but email stopped — or a subdomain that used to work is gone.
You see a redirect loop or an SSL error only after turning on Cloudflare’s proxy (the orange cloud).

The One Thing Everyone Gets Backwards

A domain connecting is three layers stacked on each other, and moving to Cloudflare is really just moving who owns the middle layer. Get the layers straight and every symptom above sorts itself into one of them.

Layer 1 — the registrar (who owns the name). This is wherever you bought the domain. Its job in this whole exercise is one thing: pointing the domain’s nameserver (NS) records at whoever will answer DNS. Cloudflare is not your registrar (unless you also transferred the registration to Cloudflare Registrar, which is a separate thing). So the nameserver change happens here, at the registrar — not in Cloudflare. This is the step that traps nearly everyone: they add the site to Cloudflare, then wait for Cloudflare to “take over,” never realizing Cloudflare is waiting for them to go back to the registrar and flip the NS.

Layer 2 — the nameserver (who answers). When you add a site, Cloudflare assigns your zone a specific pair of nameservers — two hostnames ending in .ns.cloudflare.com, unique to your account. Your job is to go to the registrar and replace all existing nameservers with exactly those two. Not a generic pair copied from a blog post — the two Cloudflare shows for this domain. Until both of them are the authoritative NS for your domain, Cloudflare isn’t answering, and it keeps the zone in “Pending.”

Layer 3 — the DNS records (what the answer says). Once Cloudflare is authoritative, the records inside Cloudflare’s DNS tab are the actual answers the world gets. And here’s the catch that eats email: Cloudflare now answers for your entire zone, so it serves only the records it holds. Whatever its import scan missed doesn’t exist anymore.

The mental model: adding the site to Cloudflare is you preparing a new nameserver. Changing the NS at the registrar is you appointing it. People do the first and skip or fumble the second, then stare at a dashboard that is, correctly, still waiting.

Top 3 Causes

The nameserver change wasn’t made (or wasn’t made correctly) at the registrar. You added the site to Cloudflare but either never changed the NS, changed it in the wrong place, replaced only one of the two, left an old nameserver behind, or entered the wrong assigned pair. The tell: Cloudflare stays “Pending Nameserver Update,” and a live NS lookup shows anything other than exactly Cloudflare’s two assigned names.
Leftover DNSSEC from the old provider → SERVFAIL. Your previous DNS host signed the zone, and the registrar still publishes a DS record for that old key. After delegation moves to Cloudflare, the signatures stop matching the DS record and validating resolvers refuse every answer. The tell: the domain was fine until the NS flipped, then went to SERVFAIL for everyone on a validating resolver — not a slow failure, an instant one.
Records the import missed vanished at cutover. Cloudflare became authoritative for the whole zone and only serves what it imported. MX and the email TXT records (SPF/DKIM/DMARC) are the usual casualties. The tell: the website resolves, but mail bounces or a specific subdomain returns NXDOMAIN that worked an hour ago.

One note on values: Cloudflare’s assigned nameservers are unique to your account, and the DS record values are generated per zone. Read both from your dashboard — never copy a specific *.ns.cloudflare.com pair or a DS record from a tutorial. The layers below tell you where each value goes; Cloudflare tells you what it is.

Diagnose with DechoNet

DNS Lookup reads your domain’s current NS records and its A/MX/TXT answers. Check the NS first: if it isn’t exactly Cloudflare’s two assigned names, the registrar change is your problem, not Cloudflare. If it is Cloudflare but a SERVFAIL persists, you’re looking at the DNSSEC trap.
DNS Propagation Check queries resolvers worldwide at once. Right after a nameserver change they’ll disagree for a while — that’s normal propagation. If they all now show Cloudflare’s nameservers, the delegation is done and you’re only waiting on Cloudflare to re-poll.
SSL Check confirms the certificate once you turn on the orange-cloud proxy, so you can tell an actual TLS problem from a half-finished SSL mode.

Resolution Checklist

In Cloudflare, open the domain’s Overview and copy the two assigned nameservers it shows for this zone (both end in .ns.cloudflare.com).
At your registrar — not in Cloudflare — replace all existing nameservers with exactly those two, removing any old ones.
Before the switch, kill old DNSSEC: if your previous provider signed the zone, remove the DS record / turn DNSSEC off at the registrar, and give that removal time to propagate. This is what prevents the SERVFAIL.
Compare your old zone against Cloudflare’s DNS Records tab and re-add anything the import missed — MX and SPF/DKIM/DMARC TXT first, because they fail silently.
Run DNS Lookup and confirm the live NS is exactly Cloudflare’s pair; run DNS Propagation Check across resolvers before assuming anything is broken.
Once Active, if you want Cloudflare’s proxy, set the SSL/TLS mode to Full (Strict) with a valid origin certificate — and re-enable DNSSEC inside Cloudflare, adding the new DS record it generates back at the registrar.

When to Escalate

If a live NS lookup shows Cloudflare’s exact pair everywhere but the dashboard still says Pending after 24 hours, the delegation is done and the hold is on Cloudflare’s side — contact Cloudflare support rather than changing anything else.
If you hit a redirect loop or a 525 only after enabling the orange cloud, the DNS move succeeded and the problem is the proxy’s SSL mode meeting an origin that can’t complete HTTPS — fix the origin certificate and SSL mode, don’t touch the nameservers.
If the domain resolves to the right place everywhere but still won’t load, DNS is finished and the problem has moved to the origin server on that IP.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.