Cloudflare sits in front of your domain and decides how the world reaches it. Configured well it is invisible. Configured badly it takes your website and your email down together.
Cloudflare is the layer that sits between your domain and everything that uses it: your website, your email, and anything else on the name. It answers DNS queries, provides the certificate that puts the padlock in the browser, caches your site closer to visitors, and filters out a good deal of malicious traffic before it reaches your host.
It is genuinely useful and it is also the single most dangerous place to click something you do not understand. DNS is the reason a website loads and the reason email arrives. One wrong record and both stop at once, with no error message to explain why.
Four jobs worth understanding, because they explain most of what goes right and wrong.
Every time someone loads your site or sends you email, something has to look up where that traffic goes. That is DNS, and Cloudflare answering those queries is fast and reliable. More importantly, it puts every record for your domain on one screen, which matters enormously the day something breaks.
The commonest problem we meet is not a misconfiguration. It is that nobody knows who controls the DNS at all. The web person who set it up moved on, the login belongs to an agency that no longer answers, and the domain quietly renews to a card nobody recognises. Establishing control of your own DNS is a real piece of work and it is worth doing before you need it urgently.
Cloudflare can issue the certificate that makes your site load over https. What people miss is that there are two halves to that connection: visitor to Cloudflare, and Cloudflare to your actual host. The encryption mode decides whether the second half is protected too. Set it wrong and you get a padlock that is lying, a redirect loop, or a warning page that scares off every visitor. This is the setting that causes the most confusion and it is worth getting right rather than guessing.
Your images, stylesheets and often your pages get stored on Cloudflare's network and served from near your visitor rather than from your origin server every time. Real gain, especially for people far from your host. It is also the reason you can update a page and still see the old one: cached copies persist until they expire or are purged. Knowing that saves an hour of thinking you are losing your mind.
Bot filtering, rate limiting and mitigation of the flood attacks that would otherwise take a small host offline. There is also email address obfuscation, which hides the addresses printed on your pages from the scrapers that harvest them for spam lists. It is a small feature that quietly saves you a lot of junk, and it is on our own site.
This deserves its own section because it is the failure we get called about most, and it is entirely avoidable.
People think of DNS as a website thing. It is not. Your MX records decide where your mail is delivered. Your SPF, DKIM and DMARC records decide whether anyone believes mail claiming to be from you. All of that lives in the same DNS zone as your website.
So when someone changes nameservers to point at Cloudflare, they are moving the whole zone. Cloudflare scans and imports what it can find, and it usually does a decent job. Usually is not a word you want anywhere near your mail delivery. Anything it misses simply stops existing at the moment the nameservers switch, and your email quietly stops arriving with nothing on screen to tell you.
Two rules that prevent nearly all of this:
If the plan involves moving mailboxes as well, that is a bigger exercise with its own sequence: see business email migration. If you are standing up mail from scratch instead, start at Google Workspace setup.
Registrar, nameservers, and who holds the logins. Surprisingly often this step alone is the whole engagement, because nobody has known the answer for years.
Every record as it stands today, so there is something to compare against and something to restore from. Nothing gets changed until this exists.
Bring the zone into Cloudflare, then check it against the original line by line. Mail records first, always. Cloudflare imports well but it does not import perfectly.
Make the change, then confirm the site loads and, separately, send test mail in both directions. A site that loads proves nothing about your email.
Encryption mode set to genuinely encrypt both halves, caching that suits how your site is updated, and protection turned on at a level that stops bots without blocking your customers.
The account is yours, in your name, with your billing. We work in it; we do not hold it hostage. That is not a favour, it is how it should always have been.
It gets recommended as a cure for things it has nothing to do with.
DNS is the one place where a careless change breaks your website and your email at the same time, with no warning. We treat it that way: audit first, change second, verify both.
No. You keep your domain registered wherever it is now. What changes is the nameservers, which is the setting that decides who answers questions about your domain. Cloudflare becomes your DNS provider; your registrar stays your registrar.
You can move the registration to Cloudflare as well if you want everything in one place, but it is a separate decision and not required.
It should not, and when it does the cause is nearly always the same mistake: the MX records were not carried across when the nameservers changed, or an MX hostname was proxied. Mail records must never be proxied, only your web traffic.
This is why we audit every existing record before changing nameservers rather than after. If mail is already unreliable, that is a separate problem: see business email going to spam.
For a great many small business sites, honestly, yes. DNS, a certificate, caching and the baseline protection cover what most brochure and lead-generation sites actually need. We will tell you if your situation genuinely calls for more rather than assuming it does.
Note that Cloudflare is a service you hold in your own account, so whatever it costs is between you and them. We configure it; we do not resell it.
Usually because of the encryption mode between Cloudflare and your actual host. If it is set to a mode that does not encrypt that back half of the connection, or your host has no valid certificate of its own, you get warnings, redirect loops, or a padlock that lies about what is happening.
The other common cause is mixed content: the page loads over https but pulls an image or script over http. Both are fixable. See website security problems.
It can, and it is not magic. Caching your pages and files closer to your visitors genuinely cuts the time spent waiting on the network, and that is real.
What it will not do is rescue a site that is slow because of oversized images, bloated plugins or heavy scripts. The cache will faithfully deliver your slow page quickly to the edge and it will still be slow. That is a speed optimization job.
Certificates, hardening, and protection against the common attacks.
Find what is actually slowing the site down, then fix it.
Move mailboxes to a new provider without losing mail or downtime.
Business email, files and calendars on your own domain.
See how Google actually crawls, indexes and ranks your pages.
Authentication, reputation, and the fixes that actually move the needle.
Tell us your domain and what is misbehaving. We will find out where it actually points and what is in the way.