A Cloudflare DNS proxy status checklist prevents a small cloud-icon change from breaking mail, bypassing web protection, or exposing the origin unexpectedly. Review each hostname by service purpose, not by record type alone, and test the public behavior after every change.
Inventory records and services
Export or record each DNS name, type, target, proxy state, business purpose, service owner, and rollback value. Group records into web traffic, email, domain verification, vendor-hosted services, and non-HTTP protocols. Include duplicate names and CNAME chains because their combined behavior may differ from a single row in the dashboard.
Cloudflare states that A, AAAA, and CNAME records can be proxied. Other types, including MX and TXT, remain DNS-only (Cloudflare DNS). That technical capability does not mean every eligible record should be proxied.
Choose proxied or DNS-only intentionally
Use the proxied state for supported web traffic when you want HTTP or HTTPS requests to pass through Cloudflare's network. In that state, Cloudflare can apply products such as caching, Web Application Firewall rules, redirects, analytics, and DDoS protection. Visitors receive Cloudflare addresses rather than the origin address.
Use DNS-only for records that must reveal the service target directly or support services Cloudflare's HTTP proxy does not handle. Cloudflare identifies email routing, third-party domain verification, some SaaS-hosted sites, and non-HTTP services as common DNS-only cases (Cloudflare DNS). Follow the connected provider's instructions when it explicitly requires DNS-only resolution.
Check related configuration
For each proxied web hostname, verify that SSL or TLS mode, origin certificates, redirects, cache rules, firewall policy, and allowed origin traffic match the intended setup. Cloudflare's architecture places the network between visitors and the origin for proxied requests, so application behavior can depend on both edge and origin settings (Cloudflare Fundamentals).
Review whether a DNS-only hostname reveals an origin also used by a proxied hostname. If so, decide whether the exposure is necessary and whether the origin restricts traffic appropriately. Do not copy an origin address into a report that will be shared publicly.
Test the change from outside
Record the previous state before editing. After the change, query DNS from more than one resolver and inspect the HTTP response from an external network. For a proxied record, confirm the expected certificate, hostname, redirects, cache behavior, security rules, and application response. For DNS-only, confirm the service works without depending on Cloudflare HTTP features.
Test mail delivery after any nearby DNS edit even when the MX row itself was untouched. Check SPF, DKIM, and verification records for accidental name or target changes. A proxy toggle should not become an excuse for unrelated bulk edits.
Account for mixed records
Cloudflare documents that when multiple A or AAAA records share a name and at least one is proxied, the name is treated as proxied. It also notes that a proxied hostname in a CNAME chain can affect the request path. Review the full name and chain rather than interpreting each line in isolation.
Document and recheck
Save the reason for every DNS-only web record and every proxied service record. Assign an owner and next review date. Repeat the review after moving hosts, adding email services, changing a CDN, or connecting a verification provider.
Quick completion test
The review is complete when each record has a service purpose and owner, web hostnames use the intended edge path, mail and verification records remain correct, exposed origins are understood, external tests pass, and rollback values are preserved.
Sources
- Proxy status — Cloudflare
- How Cloudflare DNS works — Cloudflare