Why you do not need to change your nameservers
The usual way onto Cloudflare moves every DNS record you own, mail included. Here is what that instruction really asks for, and the narrower way in.
Read any guide about putting a website behind Cloudflare and it opens the same way. Sign in wherever you registered the domain, find the nameserver fields, replace what is there with the two names Cloudflare gives you, and wait. Every guide says it because it is the normal way in, and it works.
It is also the right move for most people. If you can change your domain nameservers to Cloudflare, do that instead. It costs nothing, and you will not need us. This article is about the other case, and about what that one instruction is actually asking for, which is more than it sounds like.
The title is about need, not about advice. You do not need to move your nameservers to put a website behind Cloudflare. Whether you should is a separate question, and for plenty of domains the answer is yes.
What changing your nameservers actually moves
Nameservers are not a setting on your website. They are the answer to a question asked one level above it: when something on the internet needs to know anything about your domain, who does it ask? That answer lives with your domain registration rather than inside your records, so changing it edits none of them. It changes who gets asked.
Which means the new provider has to already hold the answers. Every name under your domain that resolves today has to exist there before the change reaches people, or it stops resolving. Cloudflare scans your existing records while you set the domain up and copies back what the scan returns. What no tool can do is know what you had, because the only complete list is the one sitting at your current provider, and almost nobody reads that list until something is missing from it.
The records that hurt are never the website, because the website is the one thing you were paying attention to. It is the mail records. It is the subdomain pointing at a tool somebody set up two years ago. It is the verification string that a service checks quietly once a year and complains about long after anyone would connect the two events.
Wide is not the same as risky
This part is worth being precise about, because the sales version of this article would not be. Moving nameservers to Cloudflare is not dangerous. It is the documented, ordinary way in, and it undoes: if a record turns out to be missing, you add it at the new provider and the name answers again. Nobody should be frightened out of it, least of all by us.
The accurate word is wide. The change moves everything your domain answers, all at once, as a single operation. That is a good trade when what you want is the whole domain on a new provider. It is an awkward one when what you wanted was a single website behind a shield, because getting there now involves touching mail.
Width also decides who has to be involved. One website is a decision you can make on your own in an afternoon. A whole domain changing hands is a decision that reaches whoever depends on the mail, whoever built the subdomain, and whoever expects to hear about it beforehand rather than afterwards.
When the change is not yours to make
Three situations come up often enough to name, and in none of them is Cloudflare the problem.
- The domain is managed by somebody else. An agency, the developer who built the site, or the person who registered it years ago and still holds the only login.
- Your organisation does not allow nameserver changes. The domain belongs to the company, DNS belongs to a team that is not you, and the answer to a request to move it is going to be no.
- Mail or another live service runs on the same domain. Moving the whole zone moves those with it, and deciding not to put them through that is a legitimate answer rather than an excuse.
In each case the question is not whether Cloudflare is good at what it does. It is whether the size of the change matches the size of the problem. You have one website you would like protected, and the usual instruction asks you to move a domain to get there.
The narrow version of the same move
The same network can be reached at the size of a single name. A CNAME on the name of your website, pointing at a hostname that already lives on a Cloudflare zone, sends that one name through Cloudflare and leaves every other record answered by whoever answers it today. That is the route this product takes, and how it works walks through the mechanics and the order they run in.
One thing to be accurate about: you add two records, not one. The first is the CNAME that decides where your website points. The second sits on _acme-challenge. in front of that same name, and it is a permission rather than a destination: it is how the security certificate renews itself later without coming back to ask you for anything. Leave it out and everything works for months, then a renewal fails on a website nobody touched. The exact value for both appears on your setup screen.
What those fields are called in the panel you happen to use, and the two ways people fill them in wrongly, is covered in how to add a CNAME record at your DNS host.
What neither route changes
The firewall is identical. Both routes end with your website behind Cloudflare protection configured at the zone level, and every website on a zone gets those rules at the same strength. Firewall rules written per hostname are a Cloudflare enterprise feature, so nobody putting you on a shared zone can hand you a stronger wall than the free one. We do not have a stronger wall to sell you.
Your server also keeps answering its own address either way. Requests aimed straight at that address skip whatever is standing in front of the name, and that is what people mean by an exposed origin. Your origin is the real server your website runs on. It answered its own address before you had heard of Cloudflare, and it goes on doing so whether you moved nameservers or added a record. Neither route closes that door for you, and in both the fix is the same rule on your own server.
What we add on top of the narrow route is the watching afterwards, not the wall. Six checks run against your website every ten minutes, including whether that second record quietly disappeared, and what we check lists all six with what each one means when it turns red. Those results sit on your dashboard for you to read. The email that reaches you when one of them changes is the part we have not built yet, and we would rather tell you that here than let you find out by never receiving one.
So the question to settle is not which product is better. It is whether the nameservers are yours to move. If they are, and nothing else on the domain minds, move them and pay nobody. If they are not, the narrow route exists, and it comes apart the same way it went together: point that one record back at your server and visitors reach it directly again.