Cloudflare DNS setup: the settings I use when moving a site to Cloudflare

A Cloudflare DNS setup looks like a five-minute job: add the domain, accept the records Cloudflare finds, change two nameservers at the registrar. Most of the time that works. When it does not, the failure is quiet and delayed: mail stops arriving because an MX record was never imported, a SaaS tool loses its domain verification, DNSSEC makes the whole domain fail to resolve for validating resolvers, or the site goes into a redirect loop because of the SSL mode. This is the order I follow when I move a domain to Cloudflare, and the settings I choose once it is there.

Step 1: audit and export your current DNS first

When you add a domain, Cloudflare scans for common records and pre-fills them. It is a helpful start, but it can only find names it thinks to ask about, so anything under an unusual name is easily missed. Before changing anything, I get a complete copy of the current zone.

• Export the zone file from your current DNS host if it offers one. Cloudflare can import a standard BIND-format zone file, which is far more reliable than the scan.
• If there is no export, copy every record from the current panel, including the pages you normally never look at.
• Cross-check with dig against the current nameservers, so you record what is really live.

# Ask the current authoritative nameserver directly
NS=$(dig NS example.com +short | head -1)

for t in A AAAA MX TXT CAA; do dig @$NS example.com $t +short; done
dig @$NS _dmarc.example.com TXT +short
dig @$NS google._domainkey.example.com TXT +short
dig @$NS _sip._tls.example.com SRV +short
dig @$NS www.example.com +short

The records I specifically hunt for, because they are the ones that go missing:

• MX records and the hostnames they point to.
• TXT records: SPF, DMARC at _dmarc, and site verification tokens for Google, Microsoft, Facebook, Apple and similar.
• DKIM keys under selector._domainkey, either as TXT or as CNAME records. You need the selector names, which you can find in the headers of a sent message (s= in the DKIM-Signature header) or in each sending tool's settings.
• SRV records for Microsoft 365, VoIP, chat or calendar services.
• Subdomains: staging, API, shop, help desk, status pages, and custom-domain CNAMEs for tools like a newsletter platform or a knowledge base. Ask whoever runs marketing and support; they often added these themselves.

Step 2: lower TTLs on anything you plan to change

If every record keeps the same value, TTLs matter less, because old and new nameservers give the same answers during the overlap. But if you also plan to change the origin IP, the mail provider or anything else around the same time, lower the TTL on those records to 300 seconds at the old provider a day or two in advance, so a mistake or a rollback propagates in minutes rather than hours.

You cannot shorten the TTL on the nameserver delegation itself; the registry for your TLD sets it (for .com it is two days). Some resolvers will keep asking the old nameservers for a while, so the old DNS host must keep serving the same records until the change has settled. Do not delete the old zone the day you switch.

Step 3: handle DNSSEC before changing nameservers

This is the step that causes real outages. With DNSSEC on, the parent zone holds a DS record that says, in effect, “answers for this domain must be signed with this key”. Cloudflare signs with its own keys. Switch nameservers while the old DS record is still published, and validating resolvers such as 1.1.1.1 and Google Public DNS reject every answer. The domain stops resolving for a large share of visitors. The order I use:

1. Check whether DNSSEC is on: dig DS example.com +short. Empty output means no DS record at the parent.
2. If there is a DS record, disable DNSSEC at the registrar and remove the DS record.
3. Wait until the DS record has disappeared from public resolvers and its old TTL has passed, often a day or more, before changing nameservers.
4. Change the nameservers and let the move settle.
5. Enable DNSSEC in the Cloudflare dashboard. It gives you the DS record values (key tag, algorithm, digest type and digest); add those at the registrar. Some registrars pick this up automatically, but I always check.

dig DS example.com +short
dig example.com +dnssec @1.1.1.1 | grep -E 'flags|RRSIG'

The ad flag in the response header means the resolver validated the answer. Cloudflare also documents a multi-signer migration that keeps DNSSEC on throughout, but it needs support from the old provider and is more involved than most sites need.

Step 4: change nameservers and verify propagation with dig

Before touching the registrar, I query the Cloudflare nameservers assigned to the zone directly. They answer as soon as the zone exists, so you can compare old and new before anything public changes.

# Cloudflare shows two assigned nameservers, e.g. ada.ns.cloudflare.com
dig @ada.ns.cloudflare.com example.com MX +short
dig @ada.ns.cloudflare.com example.com TXT +short
dig @ada.ns.cloudflare.com _dmarc.example.com TXT +short

Once those match the audit, replace the nameservers at the registrar with the two Cloudflare gives you, exactly as shown, and remove any others. Then check from the outside:

# What the world sees as the delegation
dig NS example.com +short

# Ask the .com registry servers directly (use your TLD's servers)
dig NS example.com @a.gtld-servers.net +norecurse

# Compare public resolvers
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com MX +short

# Follow the whole chain from the root
dig +trace example.com

Cloudflare marks the zone active once it sees its nameservers at the registry. Until then, and for a while after, keep the old provider unchanged.

Proxied vs DNS only: which records get the orange cloud

Every A, AAAA and CNAME record in Cloudflare is either proxied (orange cloud) or DNS only (grey cloud). Proxied records return Cloudflare's IPs, so traffic flows through its edge for caching, TLS and security. DNS only records return your real value, exactly like any other DNS host. Other record types such as MX, TXT and SRV are never proxied.

The trap with DNS only records is that they publish the IP they point at. If mail.example.com is DNS only and sits on the same server as the website, anyone can look it up and bypass Cloudflare. The same goes for an ip4: entry in SPF, an old cpanel or direct record, and mail sent from the web server, whose IP appears in message headers. Public DNS history services also record what your domain resolved to before the move. If the origin IP was already public, the only real fix is to change it and update the proxied records.

SSL/TLS: use Full (strict), never Flexible

The SSL/TLS encryption mode decides how Cloudflare talks to your origin. I set Full (strict) on every site: Cloudflare connects over HTTPS and requires a valid certificate on the origin. There are two good ways to provide it:

• A Cloudflare Origin CA certificate. Free, long-lived, and trusted by Cloudflare only. Perfect behind the proxy, but browsers will reject it if you ever switch the record to DNS only.
• A public certificate such as Let's Encrypt. Trusted everywhere, so the site still works if the proxy is off. I usually issue it with the DNS-01 challenge and a scoped Cloudflare API token, which does not depend on HTTP traffic reaching the origin.

Flexible mode connects to your origin over plain HTTP. Besides leaving that leg unencrypted, it causes the most common post-migration bug I see: WordPress or the web server redirects HTTP to HTTPS, Cloudflare requests HTTP again, and the browser ends up with ERR_TOO_MANY_REDIRECTS. Full (strict) fixes it at the root. If you get 525 or 526 errors after switching, the origin certificate is missing or invalid, and my guide to Cloudflare 52x errors walks through the checks.

Then I turn on Always Use HTTPS, which redirects HTTP to HTTPS at the edge. HSTS comes last, because browsers cache it and refuse plain HTTP for the whole max-age. I start with a short max-age, leave includeSubDomains off until every subdomain is confirmed on HTTPS, and only consider preload much later.

CAA records: allow the CAs you actually use

A CAA record lists which certificate authorities may issue certificates for your domain. It must include everyone who issues for you: the CAs behind Cloudflare's edge certificates, plus whatever issues your origin or DNS only subdomains. Cloudflare documents that it adds entries for its own CAs when Universal SSL is on and CAA records exist, but I check rather than assume.

dig CAA example.com +short
# e.g.
# 0 issue "letsencrypt.org"
# 0 issue "pki.goog"
# 0 iodef "mailto:security@example.com"

If a certificate renewal suddenly fails after a Cloudflare move, a CAA record left over from the old setup is one of the first things I look at.

Lock the origin to Cloudflare's IP ranges

Proxying hides the origin IP, but hiding is not protection. I configure the server firewall to accept ports 80 and 443 only from Cloudflare's published ranges at https://www.cloudflare.com/ips-v4 and https://www.cloudflare.com/ips-v6, and restore the real visitor IP from the CF-Connecting-IP header so logs and rate limiting see real visitors.For stronger guarantees, Authenticated Origin Pulls makes the origin require a client certificate that only Cloudflare presents, and Cloudflare Tunnel removes open inbound ports altogether. Firewall rules, SSH and the rest of the server get locked down as part of my server security hardening work.

Basic security settings and a cache rule caution

On the security side I start modest: the managed WAF rules available on the plan, a custom rule blocking paths that should never see public traffic (on WordPress, xmlrpc.php if nothing uses it), and a rate limit on login endpoints. Test bot protection features carefully, because they can challenge legitimate automated traffic such as payment webhooks, uptime monitors and API clients. If something breaks, check the security events log first.

Caching is where a careless rule does real damage. By default Cloudflare does not cache HTML. The moment you add a rule that caches everything, you must bypass cache for admin areas, carts, checkouts, account pages and any request carrying a logged-in session cookie, or one user's page, with their name or cart, can be served to other visitors. I write the bypass conditions first, then test in a private window and a logged-in window side by side.

Verify email still flows

Email breaks most often, and silently. After the switch, I compare MX, SPF, DKIM and DMARC answers from public resolvers against the audit, send test messages from every system that sends as the domain, and check the headers for passes. I also send mail to the domain from an outside account, since a missing MX record only shows up on inbound. If anything fails, my SPF, DKIM and DMARC setup guide covers the records in detail.

Cloudflare DNS setup checklist

• Zone exported or fully copied; MX, TXT, DKIM, SRV, verification records and subdomains accounted for.
• TTLs lowered on any record whose value will change.
• DNSSEC disabled and DS record gone before the nameserver change.
• Records checked on Cloudflare's nameservers before switching; delegation confirmed with dig after; old provider left running.
• Only web hostnames proxied; mail, SSH, FTP and verification records DNS only.
• No DNS only record, SPF entry or mail header exposing the origin IP; IP changed if it was already public.
• SSL/TLS on Full (strict) with an Origin CA or public certificate; Always Use HTTPS on; HSTS only when ready.
• CAA records allow every CA that issues for the domain.
• Origin firewall accepts web traffic only from Cloudflare; real visitor IP restored.
• Cache rules bypass admin, cart, checkout and logged-in sessions.
• DNSSEC re-enabled with Cloudflare's DS record at the registrar.
• Inbound and outbound email tested.

None of these steps is hard on its own; the risk is in skipping one. If you would rather have the move done for you, with the zone audited, DNSSEC handled and the origin locked down, that is exactly what my Cloudflare setup service covers, and ongoing record changes and cleanups fall under DNS management. Small fixes are $20/hour; a full move gets a fixed price agreed in writing before I start.

Frequently asked questions