Cloudflare Pages Custom Domain DNS Setup That Actually Works

Pointing a custom domain to Cloudflare Pages sounds like it should be a two-minute job — and when your domain is already on Cloudflare, it usually is. But when things go sideways (ERR_TOO_MANY_REDIRECTS, a stuck "Initializing" SSL badge, or a domain that resolves to the wrong project), the cause is almost always a DNS misconfiguration that Cloudflare's UI doesn't explain clearly. This guide cuts straight to the exact records you need, the exact settings to toggle, and the exact CLI commands to confirm everything is wired up correctly.

How Cloudflare Pages Custom Domain DNS Actually Works

Before touching any records, understand the architecture. Cloudflare Pages serves your site from Cloudflare's global edge. When you add a custom domain, Pages needs a DNS record that routes traffic to pages.dev — your project's default subdomain. Depending on whether your domain registrar is Cloudflare or a third party, the process differs significantly.

• Domain on Cloudflare DNS: Pages can create the record automatically, and the proxy (orange cloud) is available immediately.
• Domain on external DNS (Namecheap, GoDaddy, Route 53, etc.): You must add a CNAME record manually at your registrar's nameservers, and Cloudflare's Universal SSL must provision before HTTPS works.
• Apex/root domain (@): Standard CNAMEs are not allowed at the apex per RFC. Cloudflare solves this with CNAME Flattening. External DNS providers must use ALIAS or ANAME records — not all support them.

Scenario 1: Your Domain Is Already on Cloudflare DNS (Easiest Path)

This is the recommended setup. If your domain uses Cloudflare nameservers, Pages can auto-configure everything.

Step-by-step

1. In the Cloudflare dashboard, go to Workers & Pages → Your Project → Custom Domains → Set up a custom domain.
2. Enter your domain or subdomain (e.g., www.example.com or app.example.com).
3. Click Continue. Cloudflare will detect that the domain is on your account and offer to create the DNS record automatically.
4. Click Activate domain. A CNAME record pointing to your-project.pages.dev is created with the proxy enabled (orange cloud).
5. Wait for SSL to provision — typically 1–3 minutes. The badge in the Custom Domains tab moves from Initializing to Active.

For the apex domain (example.com with no www)

Same steps — enter the bare domain. Cloudflare automatically applies CNAME Flattening, which returns the A/AAAA records of your-project.pages.dev at the zone apex. No special action needed on your part, but be aware the DNS response your visitors see will be IP addresses, not a CNAME record.

Scenario 2: Domain Is on External DNS

This requires manual record creation at your current DNS provider and takes longer for SSL to activate.

Records to create

For a subdomain (e.g., www):

For the apex domain, you need an ALIAS or ANAME record (not a standard CNAME). Support varies by provider:

• Namecheap: Use ALIAS record type in Advanced DNS.
• Route 53: Use A record with Alias routing to your Pages domain (Route 53-specific feature).
• Porkbun: Supports ALIAS natively.
• GoDaddy / Network Solutions: No native ALIAS support — use a www subdomain and redirect the apex to www at the registrar level, or migrate DNS to Cloudflare.

After adding the record, go back to Cloudflare Pages → Custom Domains and add the same domain. Pages will verify DNS ownership and begin SSL provisioning. This can take 5–30 minutes depending on your external DNS TTL.

Proxied vs. Unproxied (Gray Cloud vs. Orange Cloud)

This is the most common source of confusion for Pages DNS records.

• Proxied (orange cloud): Traffic goes through Cloudflare's edge. Your origin IP is hidden, Cloudflare's WAF, caching, and performance features apply. Required for Pages to serve HTTPS correctly when your domain is on Cloudflare DNS.
• DNS only (gray cloud): DNS resolves directly to Pages' edge IPs. Still works, but you lose Cloudflare's layer-7 features. Never set a Pages CNAME to DNS-only and then enable a Page Rule for HTTPS redirect — this creates redirect loops.

The correct setting for virtually every Pages custom domain is proxied. If you explicitly need DNS-only (rare: for SPF/DKIM subdomains or non-HTTP services), that's a different scenario entirely.

Fixing ERR_TOO_MANY_REDIRECTS

This is the most common error after Pages DNS setup and has three root causes:

Cause 1: SSL mode set to Flexible

Navigate to your domain → SSL/TLS → Overview and confirm the mode is Full (strict) or at minimum Full. If it's set to Flexible, Cloudflare sends HTTP to your origin, Pages redirects to HTTPS, Cloudflare tries HTTP again — infinite loop.

Fix: Change SSL/TLS mode to Full (strict). Pages always serves HTTPS, so strict is safe and correct.

Cause 2: A redirect rule or Page Rule adding an extra HTTPS redirect

Go to Rules → Redirect Rules (and the legacy Page Rules section). If you have a rule that redirects HTTP to HTTPS for *example.com/* or the specific subdomain, and the SSL mode is Flexible, disable the manual redirect rule and rely on Cloudflare's Always Use HTTPS toggle under SSL/TLS → Edge Certificates instead.

Cause 3: www to apex redirect loop

If you added both www.example.com and example.com as custom domains in Pages, and you have a redirect rule sending one to the other, make sure the redirect rule is at the Cloudflare Rules level — not duplicated inside Pages settings and Cloudflare Rules simultaneously.

Fixing a Stuck "Initializing" SSL Status

Cloudflare Pages uses Cloudflare's Universal SSL to issue a certificate for your custom domain. If it stays in "Initializing" for more than 30 minutes:

1. Verify the DNS record actually resolves to your-project.pages.dev using dig (see CLI section below).
2. Check that the domain is not under a CAA record that excludes Cloudflare's CA (DigiCert or Let's Encrypt). Go to DNS → Records and look for CAA entries. If 0 issue "letsencrypt.org" is there but digicert.com is missing, add it or delete the restrictive CAA record.
3. Remove the custom domain from Pages and re-add it. This re-triggers SSL provisioning.
4. Check the SSL/TLS → Edge Certificates tab on your domain — if a cert is listed for the hostname but shows "Pending Validation," Cloudflare is waiting for DNS to confirm. This resolves itself once propagation completes.

CLI Verification Commands

Don't rely only on the Cloudflare dashboard to confirm your records. Use these commands to verify from the outside.

Verify CNAME record

Verify apex CNAME flattening (returns A/AAAA, not CNAME)

Check SSL certificate subject

nslookup alternative (Windows/Mac/Linux)

Using a Custom Domain With a Branch Deployment

Cloudflare Pages supports branch deployments at branch-name.your-project.pages.dev. You can also map a custom subdomain to a specific branch:

1. In Pages → Custom Domains, add the subdomain (e.g., staging.example.com).
2. After the domain activates, go to Deployments and find your branch deployment.
3. Use Manage aliases on a specific deployment to assign the subdomain to that branch rather than the production deployment.

Note: The CNAME target will still be your-project.pages.dev — Cloudflare routes the correct branch based on the HTTP Host header internally.

Migrating an Existing Site to Cloudflare Pages Without Downtime

If www.example.com currently points to another host and you're migrating to Pages, follow this sequence to avoid downtime:

1. Deploy and test your Pages project at your-project.pages.dev first.
2. Add the custom domain in Pages before changing DNS. Pages will show "Verifying" — this is expected.
3. Lower your existing CNAME or A record TTL to 300 seconds (5 minutes). Wait one full TTL cycle for resolvers to pick up the lower TTL.
4. Change the DNS record to point to your-project.pages.dev.
5. Pages detects the DNS change within minutes and activates SSL.
6. Monitor with dig CNAME www.example.com @8.8.8.8 +short until you see the Pages target.

Common Misdiagnoses

Several errors get blamed on DNS when the actual cause is different:

• "My domain shows the old site" — but DNS is already updated: This is almost always a browser cache or local DNS resolver cache issue. Flush with ipconfig /flushdns (Windows), sudo dscacheutil -flushcache (macOS), or sudo resolvectl flush-caches (Linux). Try an incognito tab or a different device to confirm.
• "Pages shows Active but the site shows a 522 error": 522 is a connection timeout from Cloudflare to origin. For Pages this usually means the project itself has a build or runtime error, not a DNS problem. Check the Pages deployment logs.
• "CNAME looks correct but SSL still won't provision": Check for a conflicting A record. If both an A record and a CNAME exist for the same hostname (which DNS technically doesn't allow, but some providers silently permit), remove the A record.
• "www works but apex doesn't": If your domain is on external DNS that doesn't support ALIAS records, the apex cannot CNAME to Pages. The fix is either migrating nameservers to Cloudflare or using a registrar-level redirect from example.com → www.example.com.

2026 Notes: IPv6, DoH/DoT, and DNSSEC

Cloudflare Pages fully supports IPv6 — when your domain is proxied through Cloudflare, AAAA records are returned automatically. No manual IPv6 configuration is needed. External DNS providers that do not support IPv6 for their own nameservers can still work for Pages, because the CNAME target (pages.dev) is on Cloudflare's dual-stack network.

DNS over HTTPS (DoH) and DNS over TLS (DoT) are now common on modern operating systems (iOS 14+, Android 9+, Windows 11, macOS Ventura). These encrypted resolvers do not affect Pages DNS records themselves, but they can make it harder to flush local DNS caches. If you're testing a domain migration on a mobile device and the old site keeps appearing, check whether the device is using a private DNS setting (Settings → Network → Private DNS on Android) and temporarily disable it during testing.

DNSSEC: If your domain has DNSSEC enabled, ensure you're not creating a CNAME for a zone apex — this breaks DNSSEC validation. With Cloudflare DNS and CNAME Flattening, this is handled automatically. With external DNS, confirm with your provider that their ALIAS/ANAME implementation is DNSSEC-compatible. Refer to RFC 1035 for the foundational rules around CNAME restrictions that explain why apex CNAMEs require special handling.

Quick Reference: DNS Records for Cloudflare Pages

• Subdomain on Cloudflare DNS: CNAME → your-project.pages.dev, Proxied (orange cloud)
• Apex on Cloudflare DNS: CNAME → your-project.pages.dev, Proxied — Cloudflare flattens automatically
• Subdomain on external DNS: CNAME → your-project.pages.dev, TTL 3600
• Apex on external DNS with ALIAS support: ALIAS/ANAME → your-project.pages.dev
• Apex on external DNS without ALIAS support: Redirect apex → www at registrar level, CNAME www → your-project.pages.dev

Once everything is configured, your Pages project serves globally from Cloudflare's edge with automatic HTTPS, HTTP/3, and zero additional infrastructure to manage. The DNS layer is thin — get it right once and you won't touch it again.