Back to tutorials
Tutorial

Cloudflare DNS setup guide tutorial (2026): Add a domain, point it to your VPS, and avoid common downtime traps

Cloudflare DNS setup guide tutorial for 2026: add records, cut over safely, fix SSL issues, and verify email deliverability.

By Anurag Singh
Updated on Sep 22, 2026
Category: Tutorial
Share article
Cloudflare DNS setup guide tutorial (2026): Add a domain, point it to your VPS, and avoid common downtime traps

Most “DNS problems” aren’t DNS problems. They’re mismatched A/AAAA records, a TTL still set to a day, missing mail records, or an orange-cloud proxy toggle you flipped without realizing what it changes.

This Cloudflare DNS setup guide tutorial shows how to add a domain, point it to your VPS or dedicated server, and verify web + email.

The goal is simple: don’t discover something broke after the cutover.

If you’re moving to a new server, make the destination boring and predictable first. Build a clean baseline on a HostMyCode VPS.

Focus on the basics: correct hostname, a sensible SSL plan, and firewall rules you understand. With that in place, DNS changes become a checkbox instead of a fire drill.

What you’ll set up (and what you should have ready)

  • Cloudflare zone for your domain
  • DNS records for your website (A/AAAA, CNAME)
  • Mail DNS (MX, SPF, DKIM, DMARC) that won’t tank deliverability
  • Cutover plan with low TTL and rollback options
  • Verification using dig, curl, and Cloudflare tools

Prerequisites:

  • Root (or sudo) access to your server (Ubuntu 24.04/26.04 LTS, Debian 12/13, AlmaLinux 9/10, Rocky 9/10 all work fine)
  • Your server’s public IPv4 (and IPv6 if you’ll publish AAAA)
  • Access to your registrar account (where nameservers are changed)
  • Clarity on where your email currently lives (Google Workspace, Microsoft 365, cPanel/Exim, Postfix, etc.)

Step 1 — Confirm the destination server is ready before touching DNS

DNS should be the last step, not the first.

Before you change anything public, confirm the new server serves the site correctly. Test by IP first, or use a temporary hosts file entry.

Quick checks on the server

  • Web server is listening: ss -lntp | egrep ':(80|443)\s'
  • Firewall allows HTTP/HTTPS: ufw status (Ubuntu/Debian) or firewall-cmd --list-services (RHEL-family)
  • Virtual host/server block matches the hostname

Test from your laptop (replace values):

# Test HTTP response from the new server by IP but with the real Host header
curl -I -H 'Host: example.com' http://203.0.113.10/

# If you already have a cert on the new server, test HTTPS too
curl -Ik --resolve example.com:443:203.0.113.10 https://example.com/

If you host multiple domains on the same VPS, create the vhosts first.

Then reload safely.

This pairs well with our Nginx multi-domain guide: Nginx server blocks tutorial.

Step 2 — Add your domain to Cloudflare (zone setup)

In Cloudflare:

  1. Go to Account HomeAdd a site.
  2. Enter your domain (e.g., example.com).
  3. Pick a plan (Free is fine for many sites; paid plans matter if you need advanced WAF/rules).
  4. Cloudflare will scan existing DNS records. Treat this as a starting point, not a finished import.

Important: don’t change nameservers yet.

First, clean up the records and set TTLs so the cutover stays controlled.

Step 3 — Create the correct DNS records (A, AAAA, CNAME) for your website

The most common baseline looks like this:

  • example.com → A record to your server IPv4
  • www → CNAME to example.com

Recommended baseline records

TypeNameValueTTLProxy
A@203.0.113.10300DNS only (initially)
CNAMEwwwexample.com300DNS only (initially)

If you have IPv6, add AAAA for @ and optionally www.

Only publish AAAA if the server is reachable over IPv6 and your firewall allows it.

Why “DNS only” first?

Cloudflare’s orange-cloud proxy changes the traffic path.

That’s often useful, but it also changes what you have to troubleshoot.

Start with DNS only until the origin behaves cleanly.

Enable the proxy after HTTPS is correct and you know what “good” looks like.

If you’re migrating, DNS records are only one piece of the move.

Plan the cutover with low TTL, verification, and a rollback path.

Use this as a companion checklist: DNS cutover tutorial.

Step 4 — Don’t break email: MX, SPF, DKIM, DMARC in Cloudflare DNS

Email failures are sneaky.

Your site loads, but password resets and invoices disappear into spam—or never arrive.

Before you switch nameservers, mirror your existing mail DNS records in Cloudflare.

4.1 Add/confirm MX records

Cloudflare DNS → MX records. Example for a mail server on the same domain:

MX  @   mail.example.com   priority 10

If you use Google Workspace or Microsoft 365, use their official MX set.

Don’t “optimize” it.

4.2 SPF (TXT)

SPF is a TXT record.

Example for a VPS sending mail directly from your server IP:

TXT  @  "v=spf1 a mx ip4:203.0.113.10 -all"

If you send through a provider (Mailgun, SES, SendGrid), include their SPF mechanism instead of your server IP.

Also avoid multiple SPF TXT records on the same hostname.

Combine mechanisms into a single record.

4.3 DKIM (TXT or CNAME)

DKIM varies based on your sender.

cPanel, Postfix/OpenDKIM, and hosted providers all use different selectors and publishing formats.

If you’re running mail on a VPS, follow a known-good DKIM workflow.

Then test end-to-end.

This tutorial stays focused on what actually matters: DKIM setup guide.

4.4 DMARC (TXT)

Start in monitoring mode.

Get visibility before you enforce anything:

TXT _dmarc  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

After you confirm alignment, move to quarantine or reject.

If you want reporting that’s set up correctly (and readable), use: DMARC reporting tutorial.

Critical rule: never proxy mail records

Cloudflare proxies HTTP(S) and a limited set of services on specific plans.

Your MX, the mail host A record (mail), and anything used for SMTP/IMAP must stay DNS only (grey cloud).

Proxy it and you’re essentially scheduling a mail outage.

Step 5 — Lower TTL before the switch (and understand what it really does)

TTL controls how long resolvers cache your records.

Lowering it speeds up your next change. It won’t instantly flush caches that already stored the old value.

Use this plan:

  • 24 hours before cutover: set TTL to 300 seconds for A/AAAA/CNAME records you’ll change.
  • Keep TTL low through the migration window.
  • After everything is stable: raise TTL to 3600 or higher to reduce query noise.

Step 6 — Switch nameservers at your registrar (the actual cutover)

Cloudflare will give you two authoritative nameservers, for example:

  • ada.ns.cloudflare.com
  • nick.ns.cloudflare.com

At your registrar:

  1. Find DNS / Nameservers for the domain.
  2. Change from “default” to “custom”.
  3. Paste Cloudflare’s two nameservers exactly.
  4. Save.

Cloudflare will detect the change and activate the zone.

Depending on registrar behavior, that’s anywhere from a few minutes to a few hours.

Step 7 — Verify DNS propagation and catch the common mistakes fast

Run dig from your laptop and, if possible, from a second network.

A mobile hotspot is perfect for this.

You’re checking two things: (1) the domain now uses Cloudflare nameservers, and (2) the records resolve to the new server.

7.1 Confirm authoritative nameservers

dig NS example.com +short

You should see Cloudflare nameservers.

If you don’t, the registrar change didn’t stick—or you edited the wrong domain.

7.2 Confirm A/AAAA results

dig A example.com +short
dig AAAA example.com +short

dig A www.example.com +short

7.3 Troubleshoot “wrong IP” and NXDOMAIN

NXDOMAIN usually means you deleted the root record, used the wrong hostname, or left the zone half-built.

A “wrong IP” result is often cache.

It can also mean you updated records in the wrong DNS provider.

For a structured fix path, use: DNS propagation troubleshooting tutorial.

Step 8 — Turn on Cloudflare proxy (orange cloud) safely, then fix SSL mode

After DNS-only works and the site loads correctly from the new server, enable Cloudflare proxy for @ and www.

Leave mail-related records grey.

8.1 Decide your SSL mode

In Cloudflare → SSL/TLS:

  • Full (strict): the default you should aim for. Requires a valid certificate on your origin server.
  • Full: encrypts to origin but accepts invalid/self-signed certs. Use briefly for troubleshooting, then move on.
  • Flexible: avoid. It often creates redirect loops and sends plain HTTP to your server.

Most production sites should be on Full (strict) the same day.

8.2 Install/renew origin SSL (Let’s Encrypt)

If your origin still doesn’t have HTTPS, install a certificate first.

On Nginx/Apache VPS builds, Certbot remains the common approach in 2026.

Use our hands-on guide for safe auto-renew:

If you want hardened TLS settings (ciphers, HSTS, OCSP staples where appropriate), follow: TLS hardening tutorial.

8.3 Fix the two classic Cloudflare SSL failures

  • Too many redirects: usually Flexible SSL combined with forced HTTPS at the origin. Set Cloudflare to Full (strict) and keep one redirect source of truth.
  • 525/526 errors: the origin TLS handshake failed or the cert is invalid. Check the cert chain and confirm port 443 is open.

Quick origin test (bypassing Cloudflare) if you can reach the server IP directly:

curl -Ik --resolve example.com:443:203.0.113.10 https://example.com/

Step 9 — Protect your origin IP after proxying (so attackers can’t bypass Cloudflare)

Once you proxy traffic, don’t leave your origin wide open on 80/443 to the entire internet.

If you do, bots can still hammer /wp-login.php against your raw IP and avoid Cloudflare controls.

Two practical approaches:

  • Firewall allowlist Cloudflare IP ranges for ports 80/443 (recommended for most VPS sites)
  • Keep 80/443 open but add rate limiting/WAF at the origin (less strict, but easier if your traffic comes from many sources)

9.1 UFW allowlist example (Ubuntu/Debian)

Cloudflare publishes IP ranges and updates them occasionally.

Pull the current list from Cloudflare’s documentation and apply it.

The pattern looks like this:

# Example pattern (use Cloudflare's current ranges; do not copy blindly)
ufw default deny incoming
ufw allow 22/tcp

# Allow HTTP/HTTPS only from Cloudflare
ufw allow from 173.245.48.0/20 to any port 80 proto tcp
ufw allow from 173.245.48.0/20 to any port 443 proto tcp

ufw enable
ufw status numbered

If you need a hardened SSH posture before you start tightening firewall rules, follow: SSH lockdown tutorial.

9.2 Configure real client IP logging (Nginx/Apache)

After Cloudflare proxies your site, your server will log Cloudflare IPs unless you restore the real visitor IP from headers.

Nginx (commonly in /etc/nginx/nginx.conf or /etc/nginx/conf.d/cloudflare.conf):

# Replace with Cloudflare IP ranges (current list)
set_real_ip_from 173.245.48.0/20;
real_ip_header CF-Connecting-IP;

Apache typically uses mod_remoteip. On Debian/Ubuntu:

a2enmod remoteip

# Example file: /etc/apache2/conf-available/remoteip.conf
cat > /etc/apache2/conf-available/remoteip.conf <<'EOF'
RemoteIPHeader CF-Connecting-IP
# Add Cloudflare IP ranges as RemoteIPTrustedProxy
RemoteIPTrustedProxy 173.245.48.0/20
EOF

a2enconf remoteip
systemctl reload apache2

This matters for rate limiting, WAF rules, and incident investigations.

Step 10 — Quick diagnostics: web, WordPress, and cache behavior after cutover

After the nameserver switch and proxy enablement, run these checks in order:

10.1 Confirm you’re actually hitting Cloudflare

curl -I https://example.com/ | egrep -i 'server:|cf-ray|cf-cache-status'

You should see Cloudflare headers such as cf-ray.

If you don’t, the proxy may still be off—or you’re resolving a non-proxied record.

10.2 Confirm WordPress site URL and HTTPS

WordPress moves often “work” but still point to HTTP or an old domain variant.

That shows up as odd redirects, broken admin sessions, or asset URLs that never switch.

# On the server (if WP-CLI is installed and you're in the site directory)
wp option get home
wp option get siteurl

If updates or permissions get weird after moving to a VPS, this guide is a reliable fix list: WP-CLI troubleshooting tutorial.

10.3 Watch for mixed content

If the page loads but assets get blocked, check your browser console for mixed-content warnings.

Fix the origin first (WordPress URL, hard-coded HTTP assets).

Treat Cloudflare rewrite features as a temporary bridge, not the real solution.

Step 11 — Validate email deliverability after DNS changes (the part people skip)

Even if you didn’t move email hosting, switching nameservers can drop TXT/MX records.

That happens when records weren’t imported or recreated correctly.

11.1 Check MX and SPF from a terminal

dig MX example.com +short

dig TXT example.com +short | tr ' ' '\n' | egrep -i 'v=spf1|spf'

11.2 Confirm rDNS/PTR if you send mail from your server

If your VPS sends mail directly, reverse DNS should match your hostname strategy.

If it’s wrong, some receivers will throttle you or route you to spam.

Use: PTR record setup tutorial.

Step 12 — Post-cutover checklist (do this within 24 hours)

  • Raise TTL from 300 to 3600+ once stable
  • Enable Cloudflare proxy only for web records; keep mail records DNS-only
  • Set Cloudflare SSL/TLS to Full (strict)
  • Enable HTTP → HTTPS redirect in one place (Cloudflare or origin), not both
  • Confirm real client IP logging is correct
  • Run a backup job and do a quick restore test to a staging path

If the server is new (or newly migrated), schedule backups before you start tweaking caching rules and redirects.

For VPS owners, a simple 3-2-1 approach is still the safest default: VPS backup strategy tutorial.

Summary: the safe path for Cloudflare DNS on a VPS

Keep the process predictable.

Validate the origin first. Recreate mail records carefully.

Lower TTL before you switch nameservers.

Then enable the proxy and lock down the origin.

If something feels off, pause in DNS-only mode.

It’s the easiest state to debug.

If you want a clean server to point Cloudflare at, start with HostMyCode VPS for full control, or choose managed VPS hosting if you’d rather have an experienced team handle baseline hardening and ongoing maintenance.

Planning a DNS cutover or moving a site to a new server? HostMyCode is built for migration-friendly hosting: predictable VPS performance, clean networking, and support that can troubleshoot DNS, SSL, and mail records without guesswork.

Pick a HostMyCode VPS for hands-on control, or go with managed VPS hosting if you want the setup reviewed by pros before you flip nameservers.

FAQ

Should I proxy my root domain in Cloudflare right away?

No. Start with “DNS only” until your origin server responds correctly for HTTP and HTTPS. Then enable proxy and set SSL/TLS to Full (strict).

Can Cloudflare host my email too?

Cloudflare is a DNS provider (and a web proxy/CDN). Your email still needs a mail host (Google, Microsoft, cPanel/Exim, Postfix, etc.). Keep MX and mail-related records as DNS-only.

Why did I get a redirect loop after enabling Cloudflare?

Most loops come from Flexible SSL plus an origin redirect to HTTPS. Use Full (strict) and ensure you only force HTTPS in one place.

How long does a nameserver change take?

It’s often minutes, but registrars and caches vary. Plan for a few hours of mixed results and keep TTL low during the window.

What’s the fastest way to confirm which DNS provider I’m using?

Run dig NS example.com +short. If it doesn’t show Cloudflare nameservers, your cutover didn’t complete (or you updated the wrong domain).