Cloudflare sits in front of more websites than most people realize. Orange cloud on, DNS at Cloudflare, problem solved. Except half the support tickets we see are DNS records pointing at the wrong place, mail breaking after a migration, or SSL loops that only happen when the proxy is on.
Cloudflare is not a replacement for hosting. It is a layer on top. Your site still lives on a server somewhere (hopefully in Canada if that matters to you). Cloudflare handles DNS, caching, DDoS scrubbing, and a bunch of edge features. Knowing what to point where keeps your site fast and your inbox working.
The three records everyone mixes up
A / AAAA records point your domain at the server IP that serves your website. When the orange cloud (proxy) is on, visitors hit Cloudflare first, then Cloudflare fetches from your origin IP. When proxy is off (DNS only), browsers go straight to your host.
CNAME records alias one name to another. Common for www pointing at the apex, or SaaS tools like Shopify or Flywheel. Do not CNAME your root domain unless you know what you are doing; use A/AAAA or Cloudflare's CNAME flattening.
MX records route email. They almost never go through the orange cloud proxy. Mail servers talk SMTP to specific hosts listed in MX. Point MX at your mail provider (Google Workspace, Microsoft 365, your host's mail server), not at a random A record left over from last year's migration.
Orange cloud vs grey cloud
Proxied (orange): traffic flows through Cloudflare's network. You get caching, WAF rules, and hidden origin IP. Good for public websites.
DNS only (grey): Cloudflare is just DNS. No CDN benefits, but also fewer surprises for non-web services. Use grey cloud for mail-related hostnames, FTP if you still use it, and some API endpoints that break behind Cloudflare's proxy.
Classic mistake: orange-clouding mail.yourdomain.ca and wondering why SMTP acts weird. Mail records should stay grey or not exist in Cloudflare at all if MX points elsewhere.
Where your host fits
Your hosting provider gives you origin IP addresses (or hostnames) for web, and sometimes separate mail server names. Cloudflare A records should match what your host documents for HTTP/HTTPS.
After a migration to Swift Host or any other provider, update A/AAAA in Cloudflare before you cancel the old server. Lower TTL a day ahead if you can. We covered cutover timing in our DNS and propagation guide.
If you use a staging subdomain like staging.client.ca, grey-cloud it or password-protect it. You do not want staging cached globally.
SSL modes and the redirect loop
Cloudflare SSL has modes: Off, Flexible, Full, Full (strict). Flexible encrypts visitor-to-Cloudflare but leaves Cloudflare-to-origin on HTTP. That can work until your host forces HTTPS and you get redirect loops.
Best practice today: Full (strict) with a valid cert on the origin (Let's Encrypt on the host is fine). Match what your server actually serves. "Full" without a valid origin cert is a warning sign, not a long-term fix.
Email when DNS lives at Cloudflare
Moving DNS to Cloudflare does not move email. You still need correct MX, SPF, DKIM, and DMARC for wherever mail is hosted. Import existing records during setup; do not assume Cloudflare auto-detects Microsoft or Google correctly.
SPF is a single TXT record per domain in practice. If you add a new sender, merge into one SPF string instead of stacking multiple TXT records that fail validation.
We wrote more on mail moves in moving email when you change web hosts. Web and mail DNS live in the same panel but change on different schedules.
Page rules, caching, and WordPress
Aggressive caching at Cloudflare speeds up static assets. It also caches dynamic WordPress admin, WooCommerce carts, and contact forms if you are not careful. Exclude /wp-admin/*, cart/checkout paths, and logged-in cookie rules per Cloudflare's WordPress recommendations.
Development mode in Cloudflare bypasses cache for three hours. Useful during a launch, not a substitute for proper cache rules.
Canadian data and compliance questions
Cloudflare's edge is global. Cached content may be served from US or other PoPs even when your origin is in Edmonton or Montreal. For many marketing sites that is fine. For strict data residency contracts, read what Cloudflare and your host each store and where. Sometimes you grey-cloud, skip CDN, or choose providers with Canadian-only edges.
Your origin location still matters for database and admin traffic. CDN does not move MySQL to Canada by itself.
A quick sanity checklist
- A/AAAA for
@andwwwpoint at current host IP (or correct CNAME target) - MX points at your mail provider, not your web server unless you really host mail there
- Orange cloud only on hostnames that serve HTTP/HTTPS to the public
- SSL mode matches HTTPS on origin (prefer Full strict)
- SPF/DKIM/DMARC updated after any mail provider change
- Staging and webmail subdomains thought through (grey cloud or separate rules)
Bottom line
Cloudflare is powerful when DNS records reflect reality: web here, mail there, SSL end to end. Guessing during a migration costs you a day of broken forms or silent mail bounces. Point records at what your host and mail provider document, test from outside your laptop, then turn the orange cloud on.
Migrating to Swift Host with Cloudflare in the mix? Talk with us. Bring a DNS export or screenshots. We will walk through what to flip and what to leave alone.
