How to Connect and Use a Domain with Cloudflare: A Complete Guide

Cloudflare has become the go-to layer between a website and the internet — a mix of CDN, DNS host, security shield, and performance booster, all sitting in front of the origin server. For a hosting environment built on cPanel/WHM, adding Cloudflare in front of a client’s domain is one of the most common and most consequential changes a systems administrator makes. Done correctly, it’s invisible to the end user except for a faster, more secure site. Done carelessly, it can take down email, break subdomains, or trigger SSL errors that generate a flood of support tickets.

This guide walks through the entire process — from account creation to nameserver cutover — with real-world examples drawn from a typical hosting scenario, and pays special attention to the one mistake that causes more outages than any other: forgetting DNS records that keep cPanel-hosted email running.

What Actually Happens When You “Connect” a Domain to Cloudflare

It helps to understand the mechanics before touching anything. A domain’s authority over its own DNS records lives with whichever nameservers are listed at the registrar. Right now, that’s likely your hosting provider’s nameservers (e.g., ns1.yourhost.com and ns2.yourhost.com), which are generated and managed by WHM/cPanel’s built-in DNS (BIND) zone.

When you “add a site to Cloudflare,” you are not changing where the website or mailboxes physically live. You are changing who answers DNS queries for that domain. Cloudflare becomes the authoritative DNS provider, and every record that previously lived in the cPanel DNS zone — A records, MX records, TXT records, CNAMEs, SRV records — has to be recreated inside Cloudflare’s dashboard. If a record isn’t copied over, it simply stops resolving the moment the nameserver change propagates, even though the underlying service (the mail server, the FTP server, whatever) hasn’t moved an inch.

This is why the migration is really a two-part job: point Cloudflare at the domain, and faithfully reproduce the entire existing DNS zone inside it before or immediately after the switch.

Step 1: Create a Cloudflare Account and Add the Site

1. Sign up at cloudflare.com (a free plan is sufficient for the vast majority of small-to-mid-sized hosting clients).
2. From the dashboard, click Add a Site and type in the domain — for example, example-bakery.com. Do not include www or https://.
3. Choose a plan. Free is fine for standard websites; Pro/Business add advanced WAF rules, image optimization, and more granular caching, which matter more for high-traffic e-commerce sites.
4. Cloudflare will now scan the domain’s current public DNS and import what it can find automatically.

Real-world example: A hosting client, “Example Bakery,” has example-bakery.com on a shared cPanel server. Cloudflare’s scan picks up the main A record pointing to the server’s shared IP and a www CNAME. That’s a good start — but it is very rarely the complete picture.

Step 2: Audit and Rebuild the Full DNS Zone — Don’t Trust the Auto-Scan

This is the step where migrations go wrong, and it deserves the most attention in this entire guide.

Cloudflare’s automatic scan is a best-effort DNS lookup — it can only find records that are already resolving publicly and commonly recognized (A, some CNAMEs, sometimes MX). It frequently misses:

• SPF, DKIM, and DMARC TXT records
• Autodiscover/autoconfig records used by mail clients
• SRV records for services like _dmarc, calendaring, or CalDAV/CardDAV
• Secondary A/CNAME records for subdomains like mail., cpanel., webmail., whm., ftp., webdisk.
• Custom TXT records used for domain verification (Google Workspace, Microsoft 365, SSL certificate validation, etc.)

If the domain uses cPanel email, this step is not optional

This is the single most important rule in the entire migration: if the domain has active mailboxes hosted through cPanel (Exim/Dovecot on the server), every DNS record involved in mail delivery and mail client configuration must be recreated in Cloudflare — not just the MX record. Missing pieces cause mail to bounce, spam-filter, or become unreachable by mail clients, often hours or days after the change (once the old nameservers’ TTLs expire and caches worldwide catch up), which makes the root cause much harder to trace back to a DNS migration.

At minimum, replicate:

Real-world example: During the Example Bakery migration, the SPF and DKIM TXT records used for cPanel-based email (through Exim) were not part of Cloudflare’s auto-import. If the nameservers had been switched without adding them manually, every outgoing order-confirmation email from the bakery’s WooCommerce store would have started failing SPF/DKIM checks within a day, and a portion of their customer receipts would have landed in spam or bounced outright — a problem that would surface as “customers say they never got their receipt,” not as an obvious DNS issue.

Set the right proxy status per record

Cloudflare gives each DNS record an orange-cloud (proxied) or grey-cloud (DNS only) toggle.

• Web traffic (A/CNAME for @ and www): usually proxied (orange cloud) to get Cloudflare’s CDN, caching, and WAF protection.
• Mail-related records (MX, mail-related A/CNAME, autodiscover, TXT records): must be DNS only (grey cloud). Cloudflare’s proxy only works for HTTP/HTTPS traffic; proxying mail-related A records breaks SMTP/IMAP/POP3 connections because those protocols aren’t served through Cloudflare’s edge.
• cPanel/WHM/webmail access subdomains: typically grey-clouded too, unless you specifically want them behind Cloudflare’s proxy (uncommon for admin panels, since it can complicate direct IP-based troubleshooting and some panel software doesn’t play well behind a reverse proxy).

A simple field rule: if it isn’t served over HTTP/HTTPS by Cloudflare’s edge, it should not be proxied.

Step 3: Change the Nameservers at the Registrar

Once you’re confident every record is replicated and proxy statuses are correctly set:

1. Cloudflare will display two nameservers to use, e.g., aisha.ns.cloudflare.com and todd.ns.cloudflare.com.
2. Log in to the domain registrar (GoDaddy, Namecheap, the client’s own registrar account, or WHM if the domain is registered through the host) and replace the existing nameservers with Cloudflare’s.
3. Save the change.

Nameserver propagation isn’t instant — it can take anywhere from a few minutes to 24–48 hours worldwide, depending on how aggressively resolvers cache the old NS records. Cloudflare will email a confirmation once it detects the change has taken effect and the zone is active.

Practical tip for a hosting admin: lower the TTL on the existing cPanel DNS zone a day or two before the planned cutover, if that’s feasible. Shorter TTLs mean caches expire faster once you make the switch, minimizing the window where some resolvers still point to the old nameservers while others have moved to Cloudflare.

Step 4: Verify Everything Before Declaring Victory

After Cloudflare shows the zone as Active:

• Check the website: load it in a browser, check for mixed-content warnings, verify SSL is issuing correctly (Cloudflare’s “Flexible,” “Full,” or “Full (strict)” SSL modes affect this — “Full (strict)” is recommended when the origin already has a valid certificate, which it will if the site was already running SSL through cPanel/AutoSSL).
• Check mail flow: send a test email from an external address (Gmail, Outlook) to a mailbox on the domain, and send one back out. Check headers for SPF/DKIM/DMARC pass status.
• Check subdomains: confirm webmail., cpanel., ftp., and any app-specific subdomains resolve and function.
• Run a DNS propagation checker (e.g., a dig or nslookup against multiple public resolvers, or a web-based checker) to confirm global consistency.

dig MX example-bakery.com +short
dig TXT example-bakery.com +short
dig A mail.example-bakery.com +short

Common Pitfalls Recap

• Trusting the auto-scan as complete. Manually verify every record type your services actually use, especially anything mail-related.
• Proxying mail-related records. MX records can’t be proxied by design, but people frequently proxy the mail A record by mistake, breaking IMAP/SMTP client connections.
• Forgetting SPF/DKIM/DMARC. These are invisible in a browser test but devastating for deliverability, and problems often take hours or days to surface.
• Not communicating the SSL mode correctly. Choosing “Flexible” SSL when the origin also has SSL enabled creates redirect loops on some cPanel/WordPress configurations that force HTTPS at the origin.
• Skipping the propagation verification step, then assuming a slow DNS resolver cache is a broken migration.

Closing Thoughts

Connecting a domain to Cloudflare is conceptually simple — change the nameservers — but the real work is in the DNS zone migration that has to happen first. For any domain running cPanel email, every mail-related record needs a Cloudflare counterpart before the nameservers change, or mail delivery will quietly break in ways that are much harder to diagnose after the fact than before. A careful, record-by-record migration turns what could be a support-ticket-generating outage into a seamless, invisible upgrade for the client.