Cloudflare DNS Setup Guide: Records, Proxying, SSL Modes, and Common Mistakes

Overview

This article gives you a practical checklist for Cloudflare DNS setup rather than a one-time walkthrough. That matters because DNS changes are rarely finished forever. Teams revisit them during server migrations, CMS moves, email changes, staging rollouts, and security updates.

At a high level, a typical Cloudflare DNS setup involves four decisions:

• Which records you need for the website, subdomains, and email.
• Whether each record should be proxied or DNS only.
• Which SSL mode fits your origin server.
• What should stay untouched to avoid breaking mail flow, verification records, and external services.

If you only remember one principle, make it this: DNS should reflect the real architecture behind your domain. Cloudflare can sit in front of a service, but it does not replace the need to know where traffic terminates, what application answers on the origin, and which services require direct DNS resolution.

For most site owners, the records you will use most often are:

• A record for an IPv4 address.
• AAAA record for an IPv6 address.
• CNAME record for an alias, often used for www or third-party platforms.
• MX record for incoming email routing.
• TXT record for SPF, verification, and other text-based policies.
• CNAME or TXT records for service verification, DKIM, and other provider-specific needs.

Before making changes, write down the current working state. Export records if possible, take screenshots, and note where email is hosted. This is especially important before a migration. If you are moving from shared hosting to a VPS, it helps to pair DNS planning with a broader launch checklist such as Website Migration Checklist: Moving From Shared Hosting to VPS Without Downtime.

Checklist by scenario

Use the scenario that best matches your setup, then adapt it to your stack.

1. Pointing a domain to a single VPS

This is the most common case for self-managed hosting, whether you run Nginx, Apache, Docker, or a reverse proxy.

• Create an A record for the root domain pointing to your server's IPv4 address.
• If you use IPv6, add an AAAA record as well.
• Create a CNAME for www pointing to the root domain, or create a separate A/AAAA record if you prefer direct mapping.
• Decide whether the root and www should be proxied through Cloudflare.
• Make sure your origin web server is configured to answer for both hostnames.
• Confirm that your SSL mode matches what is installed on the origin.

If you are running your own application stack, your DNS choices should align with how your server is deployed. For example, if you are hosting a Node app behind Nginx, review the origin setup alongside DNS behavior using How to Deploy a Node.js App on Ubuntu VPS With Nginx, PM2, and SSL. If your services run in containers, use DNS changes as part of a controlled release process, not as an afterthought, and keep a production checklist nearby such as How to Deploy Docker Compose on a VPS: Production Checklist for Small Projects.

2. Using Cloudflare for the main site but not for every subdomain

Many domains include a mix of public web traffic and direct service endpoints. In that case, do not apply the same proxy setting everywhere.

• Proxy the public website hostnames, such as the root domain and www, if you want Cloudflare in front of them.
• Keep service endpoints DNS only if they must resolve directly to the origin or another provider.
• Examples that often stay DNS only include mail-related hostnames, some API endpoints, SSH-related names, database admin tools, or application-specific ports not meant for browser traffic.
• Name records clearly so teammates can tell which ones are user-facing and which ones are infrastructure-facing.

This is where the “Cloudflare proxy vs DNS only” decision matters most. Proxying places Cloudflare between the visitor and your origin. DNS only simply publishes the address and sends the client directly to the destination. If a service expects a direct TCP connection or a provider tells you to use a plain DNS record, DNS only is usually the safer choice.

3. Setting up a site on a platform or managed host

If your application is hosted on a managed WordPress platform, static hosting provider, or another third-party service, the DNS setup usually comes from the provider's required records.

• Follow the provider's documented record type and target exactly.
• Use the requested CNAME, A, or verification records without substituting a different type.
• Do not remove provider verification TXT or CNAME records after setup unless you know they are no longer needed.
• Check whether the provider recommends proxying or DNS only for the hostname.

This comes up often during CMS migrations. A root domain may point one way while a www record points elsewhere, or a staging hostname may still resolve to an old service. If you run multiple WordPress environments, it is useful to document DNS ownership alongside hosting ownership. For broader platform planning, see Best Managed WordPress Hosting for Agencies: Pricing, Limits, and Workflow Features.

4. Preserving email while changing web hosting

This is one of the easiest ways to create accidental downtime. A website move should not change mail routing unless you intend to move mail too.

• Identify all existing MX records before changing anything.
• Preserve related mail records such as SPF, DKIM, and provider verification TXT or CNAME records.
• Do not proxy mail-related records. Email-related hostnames are generally DNS only.
• Test inbound and outbound mail after the web DNS changes are live.

A common failure pattern is replacing a working DNS zone with only the new website records. The site comes back, but email silently stops routing. Always treat website DNS and email DNS as separate systems that happen to share a domain.

5. Moving from one VPS to another

When changing servers, DNS is only one part of the cutover.

• Build and test the new origin first.
• Confirm the application answers correctly for the production hostname.
• Install and test the correct SSL certificate on the new server.
• Update the DNS record target only when the application is ready.
• Monitor the new host for CPU, memory, disk, and SSL health after the switch.

For server-side preparation, these guides are useful companions: Ubuntu Server Sizing Guide for Web Apps: How Much RAM and CPU Do You Really Need? and VPS Monitoring Checklist: What to Track for Uptime, CPU, Memory, Disk, and SSL.

6. Hosting open-source apps on subdomains

Many developers run tools like Ghost, Nextcloud, n8n, or Plausible on their own subdomains. DNS should be simple and explicit.

• Create one hostname per service, such as blog.example.com, cloud.example.com, or analytics.example.com.
• Point each hostname to the correct origin with A, AAAA, or CNAME as appropriate.
• Choose proxying deliberately. Browser-facing apps may work well behind the proxy, while some app-specific behaviors may be easier to manage with DNS only.
• Verify upload limits, websocket behavior, callback URLs, and SSL handling at the application layer.

If you run these kinds of tools, pair DNS planning with the relevant deployment guides: How to Host a Ghost CMS Site on a VPS, How to Host a Nextcloud Server, How to Self-Host n8n, and How to Host Plausible Analytics Yourself.

What to double-check

Before and after any DNS change, review the following items. This is the part most readers will come back to during launches and migrations.

Record correctness

• Does each hostname point to the right destination?
• Are you using the correct record type for the service?
• Did you accidentally leave an old A, AAAA, or CNAME record in place for the same hostname?
• Are root and www both covered?

Proxy status

• Should this hostname really be proxied, or does it need direct DNS resolution?
• Did you proxy a mail or verification record by mistake?
• If a service stopped working after enabling the orange cloud, does it need to be DNS only?

SSL mode fit

Cloudflare SSL modes are often misunderstood because they affect the connection between Cloudflare and your origin, not just the visitor-facing lock icon.

• Flexible is generally best avoided for modern setups because it can create confusion and redirect loops when the origin expects HTTPS.
• Full means Cloudflare connects to the origin over HTTPS.
• Full (strict) is the cleanest target when your origin certificate is valid and properly installed.

In practical terms, if your server already has a working certificate and your application is meant to run over HTTPS end to end, Full (strict) is usually the setup to aim for. If the origin has no usable certificate, fix that first rather than using a weaker mode as a permanent configuration.

Origin behavior

• Does your server answer for the expected hostname, not just the bare IP?
• Does the origin redirect HTTP to HTTPS in a way that matches the selected SSL mode?
• Are application-level URLs, callback domains, and canonical settings correct?

Email safety

• Are MX records still present and unchanged unless you intended a mail migration?
• Are SPF, DKIM, and any required TXT records still intact?
• Have you tested both receiving and sending mail after the change?

DNS propagation expectations

DNS changes do not become visible everywhere at the exact same moment. That does not always mean something is broken. Use a DNS propagation check process to confirm that the public records are updating as expected, but also test the application itself at the destination. A propagated DNS record pointing to a misconfigured origin is still downtime.

Common mistakes

Most Cloudflare DNS problems come from a small set of avoidable mistakes.

Proxying everything by default

The orange cloud is useful, but not every hostname should sit behind it. Mail, some third-party validation records, and certain infrastructure endpoints often need DNS only. Treat proxying as a per-record decision, not a blanket setting.

Using the wrong SSL mode

A common issue is choosing an SSL mode that does not match the origin. That can lead to redirect loops, certificate errors, or mixed assumptions between Cloudflare and your web server. If your origin is configured properly for HTTPS, use a mode that preserves end-to-end encryption.

Breaking email during a website change

It is surprisingly easy to focus on the website and forget the mail records. Never replace an existing zone file without first identifying which records belong to email. Website and email often change on different schedules.

Leaving stale records behind

After a migration, old A or CNAME records may continue to exist for hostnames you no longer use. Stale records create confusion, leak traffic to retired systems, and make troubleshooting harder. Clean up records that are no longer needed once the new setup is stable.

Assuming DNS is the only issue

If the domain resolves correctly but the site still fails, the problem may be on the server, inside the reverse proxy, or in the application itself. DNS gets blamed for many origin issues. Check logs, virtual host configuration, upstream containers, and firewall rules before concluding that propagation is the problem.

Not documenting the final state

Even small teams benefit from a simple record of what each DNS entry does, whether it is proxied, and which service owns it. This turns future edits from guesswork into maintenance.

When to revisit

Cloudflare DNS is not a set-and-forget task. Revisit your setup whenever the inputs change, especially in the following situations:

• Before a site launch or redesign, when root and www behavior may change.
• Before moving servers, especially from shared hosting to VPS or from one cloud instance to another.
• When adding a new app or subdomain, such as Ghost, Nextcloud, analytics, or automation tools.
• When changing email providers, because MX, SPF, DKIM, and verification records need a coordinated update.
• When enabling HTTPS on the origin or replacing certificates, since SSL mode should be reviewed at the same time.
• During recurring infrastructure reviews, to remove stale records and confirm each hostname still serves a purpose.

A practical habit is to keep a short DNS review checklist in your launch process:

1. List all active hostnames.
2. Confirm which records are proxied and why.
3. Verify SSL mode against the real origin certificate state.
4. Test root domain, www, key subdomains, and email flow.
5. Remove stale records only after the new setup is confirmed stable.
6. Document the final working configuration for the next migration.

If you treat Cloudflare DNS setup as part of release management rather than a one-time admin task, you will avoid most launch-day problems. The goal is not just to make the domain resolve, but to make every hostname, certificate path, and mail record reflect the infrastructure you actually run.