Cloudflare DNS Setup Guide for Domains: Records, Proxying, SSL, and Common Errors

Overview

A solid Cloudflare DNS setup is less about turning on every feature and more about matching DNS records, proxy behavior, and SSL mode to the way your site is actually hosted.

At a high level, there are four moving parts to understand:

1. Authoritative DNS
When you move a domain to Cloudflare DNS, Cloudflare becomes the place where your live DNS records are managed. This usually happens by changing your domain’s nameservers at the registrar. If you need a refresher on the difference between registrar, DNS host, and web host, see Registrar vs Hosting Provider: What to Keep Separate and What to Bundle.

2. DNS records
You still need the right A, AAAA, CNAME, MX, TXT, and other records. Cloudflare does not guess your infrastructure correctly in every case, especially after migrations, subdomain changes, or email reconfiguration.

3. Proxying
Cloudflare lets you choose whether supported records are DNS-only or proxied through its network. The common shorthand is the gray cloud versus the orange cloud. Proxied records can hide your origin IP and enable features like CDN delivery and certain security controls. DNS-only records simply resolve directly to the origin.

4. SSL mode
Your Cloudflare SSL mode needs to match what exists on the origin server. A mismatch here is one of the most common reasons a site breaks after setup. “Flexible,” “Full,” and “Full (strict)” are not interchangeable from an operational standpoint.

Before changing anything, collect a simple inventory:

• Your registrar login
• Your current DNS records
• Your web host’s IP address or CNAME target
• Your mail provider’s MX, SPF, DKIM, and DMARC records
• Any existing verification records for Google, Microsoft, payment platforms, analytics tools, or social platforms
• Whether the origin server already has a valid certificate installed

If you are also pointing a domain to new hosting, this guide pairs well with How to Point a Domain to Web Hosting: Nameservers, A Records, and DNS Steps.

Checklist by scenario

Use the scenario that matches your setup instead of treating every domain the same.

Scenario 1: New website launch on Cloudflare DNS

• Add the domain to Cloudflare and review any imported DNS records carefully rather than accepting them blindly.
• Change nameservers at your registrar only after you have confirmed the required records exist in Cloudflare.
• Create or verify the apex record for the root domain, usually an A or CNAME-style setup depending on your host.
• Create or verify the www record and decide which hostname will be canonical.
• Add mail-related records before going live if the domain will send or receive business email.
• Set SSL mode based on the origin certificate status. If your server already has a valid certificate, Full or Full (strict) is usually the safer target than Flexible.
• Test both http and https for the apex and www hostnames.
• Confirm redirects behave as expected and do not create loops.

This is also a good point to review domain-level privacy and account security basics at the registrar. See Domain Privacy Protection Guide: When WHOIS Privacy Matters and What It Costs.

Scenario 2: Moving an existing live site to Cloudflare without downtime

• Export or screenshot the current DNS zone before making changes.
• Compare every existing record with what Cloudflare imported. Pay special attention to subdomains, TXT records, and mail settings.
• Reduce TTL values in advance where possible if you still control the old DNS provider and want a smoother cutover.
• Change nameservers during a low-risk traffic window, but remember propagation is not instant everywhere.
• Keep the origin server configuration stable until traffic has clearly shifted and the site behaves normally.
• Verify that the web server allows Cloudflare-origin traffic and that firewalls are not blocking requests after proxying is enabled.
• Test forms, login flows, checkout pages, and API callbacks, not just the homepage.

If you need a refresher on propagation timing and what to expect after nameserver changes, see DNS Propagation Explained: How Long It Takes and How to Check Changes.

Scenario 3: Using Cloudflare for a website but separate email hosting

• Proxy only web traffic records that benefit from Cloudflare.
• Leave MX records unproxied; mail does not run through the orange cloud.
• Review associated mail host records such as mail, smtp, imap, pop, autodiscover, or provider-specific subdomains and keep them DNS-only unless your provider documents another pattern.
• Confirm SPF, DKIM, and DMARC TXT records are present and unchanged.
• Send and receive test messages from an external account before declaring the migration complete.

Many Cloudflare DNS mistakes are really email DNS mistakes, and they often go unnoticed until messages stop arriving or begin failing authentication.

Scenario 4: Cloudflare in front of WordPress or another CMS

• Confirm the origin application knows it should serve HTTPS when traffic is terminated at Cloudflare.
• Check site URL settings in the CMS so they match the final canonical protocol and hostname.
• Avoid stacking multiple redirect systems without a plan. Cloudflare rules, origin rules, and CMS plugins can conflict.
• Test login, admin area, media uploads, and plugin/theme updates after enabling proxying.
• If caching is added later, exclude admin paths, cart pages, account pages, and dynamic endpoints as needed.

Cloudflare DNS can be simple, but once proxying and redirects enter the picture, application-level behavior matters as much as DNS accuracy.

Scenario 5: Using Cloudflare with a VPS or custom server

• Install and maintain a valid certificate on the origin if you want a cleaner Full (strict) setup.
• Harden the origin so it is not unnecessarily exposed directly to the public internet.
• Make sure your web server returns the correct hostnames and certificates for both apex and www.
• Preserve real visitor IP handling in server logs and applications if that matters for analytics, rate limiting, or security review.
• Review firewall and port settings before enabling the orange cloud on production hostnames.

This scenario is common for teams comparing shared hosting, VPS hosting, and custom stacks. The more flexible the server, the more important it is to document exactly what Cloudflare is expected to do versus what remains the server’s responsibility.

What to double-check

These are the items worth reviewing every time, even if the site appears to load.

Record type accuracy

Make sure each hostname uses the correct record type. A web root might use an A record to an IPv4 address, while some hosts prefer a CNAME-style target on a subdomain. Mail routing depends on MX, and verification often depends on TXT. A wrong record type can look “close enough” in the dashboard but still fail in production.

Proxy status by record

Not every DNS record should be proxied. A safe working habit is to proxy only public web hostnames that should pass through Cloudflare and leave infrastructure, mail, and verification records DNS-only unless you have a specific reason to do otherwise.

In practice, double-check these common patterns:

• Usually proxied: apex website host, www, public app subdomains serving web traffic
• Usually DNS-only: MX-related hosts, mail submission hosts, FTP or SSH hostnames, many third-party verification targets, some API or webhook endpoints depending on architecture

SSL mode alignment

If the origin has no certificate or has an invalid one, some SSL modes may load partially or trigger loops and warnings. If the origin does have a valid certificate, using a stricter mode generally produces a more reliable end state. The key is consistency: browser to Cloudflare and Cloudflare to origin should both be planned, not accidental.

Canonical hostname and redirects

Choose whether your site should resolve at example.com or www.example.com, then enforce that cleanly. Keep redirect logic simple. One permanent redirect layer is easier to maintain than several overlapping ones.

DNS records that are easy to forget

• Google Workspace or Microsoft 365 verification TXT records
• SPF, DKIM, and DMARC
• Subdomains used by staging, status pages, or support tools
• Payment provider callbacks and webhook hostnames
• Ownership verification records for search or analytics platforms

Registrar-level security

Cloudflare DNS is not the same thing as registrar account security. Keep domain lock, registrar MFA, and renewal controls in place. For broader registrar decision-making, see Best Domain Registrars Compared: Pricing, Renewal Fees, WHOIS Privacy, and Support and Domain Renewal Pricing Tracker: Which Registrars Raise Prices the Most?.

Common mistakes

Most failed Cloudflare domain setups come from a small number of recurring issues.

Turning on proxying for everything

The orange cloud is useful, but it is not a universal default. Over-proxying can break mail, validation flows, and some service connections. Start narrow, then expand deliberately.

Trusting imported DNS records without review

Automatic scans can miss records or import outdated values. This is especially common on older domains with multiple subdomains or services added over time. Always compare the imported zone with your current production DNS.

Using the wrong SSL mode to “make it work”

Temporary fixes tend to stay in place longer than intended. If a less strict SSL mode gets the site online, treat it as a short-term bridge and document what must change at the origin to move to a cleaner configuration.

Forgetting that DNS changes and nameserver changes are different

Editing a record inside Cloudflare only matters after Cloudflare is actually authoritative for the domain. If nameservers have not been switched yet, the dashboard may look correct while public DNS still points elsewhere.

Breaking email during a web migration

Website migrations often focus on A and CNAME records while MX and TXT records are left behind. The homepage works, so the move seems successful, then email starts failing hours later. Always test website and email together.

Creating redirect loops

These usually happen when the origin forces HTTPS, Cloudflare also forces HTTPS, and the application is not correctly detecting the forwarded scheme. Similar loops happen when both the server and Cloudflare try to canonicalize www versus apex in conflicting ways.

Ignoring propagation and cache behavior during testing

If one device loads the new setup and another does not, that does not automatically mean the zone is broken. DNS propagation, local cache, browser cache, and old redirects can all create mixed signals during rollout.

When to revisit

Cloudflare DNS setup is not a one-time task. Revisit it whenever the underlying stack changes or the business depends on new subdomains, providers, or security expectations.

At minimum, review your setup in these situations:

• Before a hosting migration or server upgrade
• Before launching a new subdomain, app, or landing page stack
• When changing email providers or adding business email authentication
• When moving from shared hosting to VPS or cloud hosting
• When tightening SSL posture on the origin server
• Before peak seasonal campaigns when downtime would be more costly
• When Cloudflare workflow changes prompt you to re-check old assumptions

A practical maintenance routine looks like this:

1. Export or document the current DNS zone.
2. List every public hostname the business depends on.
3. Mark each one as proxied or DNS-only and note why.
4. Verify website, email, and third-party verification records still match active providers.
5. Test apex, www, login pages, forms, and mail flow.
6. Review origin certificate status and decide whether your current SSL mode still makes sense.
7. Confirm registrar lock, MFA, and renewal settings are in place.

If you expect to change registrars, transfer a domain, or split services across different providers, keep your Cloudflare DNS notes with your broader domain documentation. These related guides can help: How to Transfer a Domain Name: Requirements, Timelines, Fees, and Common Delays and Best Domain Extensions for Business: SEO, Trust, Pricing, and Availability.

The simplest rule is also the most durable: treat Cloudflare as part of your domain operations system, not as a set-and-forget toggle. A short checklist before each infrastructure change will prevent most DNS, SSL, and proxying problems long before they reach customers.