Use cases
This page lists common scenarios where DNS records should be proxied or set to DNS only, and describes aspects to keep in mind depending on your configuration. For background on how proxy status works, refer to Proxy status.
You should proxy all A, AAAA, and CNAME records that serve HTTP or HTTPS web traffic. This includes records for:
- Your website or web application (for example,
example.com,www.example.com) - Subdomains that serve web content (for example,
blog.example.com,app.example.com) - API endpoints that accept HTTP/HTTPS requests and do not require origin IP validation
Proxied records benefit from DDoS protection ↗, caching, WAF, and other Cloudflare security and performance features.
When traffic is proxied through Cloudflare, the following behaviors apply. You may need to adjust your origin configuration, depending on your use case.
Your origin server sees Cloudflare IP addresses as the source of all requests instead of the end-user's IP address. Applications that rely on the source IP for authentication, rate limiting, or geolocation will not function as expected without additional configuration.
Cloudflare includes the original visitor IP address in the CF-Connecting-IP and X-Forwarded-For request headers. Configure your origin server to read the visitor IP from these headers. For more information, refer to Restoring original visitor IPs.
When a record is proxied, TLS terminates at Cloudflare's global network. Cloudflare establishes a separate TLS connection to your origin server. This means the origin never receives the end-user's client certificate during the TLS handshake. You can achieve mTLS through the following:
- Client certificates (mTLS): validate client certificates between your end-users and Cloudflare.
- Authenticated Origin Pulls: Verify that traffic reaching your origin comes from Cloudflare.
- Forward a client certificate: Forward client certificate details to your origin via HTTP headers.
Cloudflare adds and modifies HTTP request headers when proxying traffic, including headers for visitor IP identification, diagnostics, and connection management. Applications that expect a fixed number of headers or parse headers by position instead of by name may experience errors.
For a full list of headers that Cloudflare adds or modifies, refer to HTTP request headers.
The following records should be set to DNS-only because the services they support are not compatible with Cloudflare's HTTP proxy. Proxying these records causes the associated service to break.
MX records cannot be proxied. If an A or AAAA record is used exclusively for email (for example, mail.example.com), it should also be set to DNS-only.
Cloudflare does not proxy SMTP traffic on port 25 by default. Proxying a record that handles email traffic causes mail servers to connect to Cloudflare's IP addresses instead of your mail server. This prevents email delivery.
Use a dedicated hostname for email that is separate from your proxied web traffic hostname. If your MX record points to the same hostname as your website, Cloudflare dynamically prepends _dc-mx to the hostname in the response for the MX record. This ensures that mail or service traffic bypasses the Cloudflare proxy and reaches your server directly.
Third-party services often require CNAME or TXT records to verify domain ownership. Proxying a verification CNAME record returns Cloudflare IP addresses instead of the expected verification target. The third-party service cannot match the response and verification fails.
Common services that require DNS-only verification records:
- Google Workspace
- AWS Certificate Manager (
acm-validations.aws) - Squarespace (
verify.squarespace.com) - Amazon Amplify
Set domain verification records to DNS Only until verification completes. Some services require the record to be DNS-only permanently.
If your site is hosted on a SaaS platform (for example, Wix, Squarespace, Webflow), the platform serves your site from its own infrastructure. Proxying the DNS record pointing to a SaaS platform causes one or more of the following issues:
- SSL errors: Both Cloudflare and the SaaS platform attempt to terminate SSL, which causes certificate mismatches or handshake failures.
- Redirect loops: Both services try to redirect HTTP to HTTPS, which creates an infinite loop.
- Broken pages or assets: The platform rejects requests that do not come directly from the expected DNS resolution.
If your SaaS platform does not explicitly support Cloudflare's proxy, set the record to DNS-only. Refer to vendor-specific DNS records for platform-specific guidance.
Records used for FTP, SSH, RDP, game servers, or other non-HTTP protocols must be DNS-only. Cloudflare's proxy only handles HTTP and HTTPS traffic. Proxying these records routes the traffic to Cloudflare, which drops the non-HTTP connection.
To proxy non-HTTP protocols, use Cloudflare Spectrum.
If a CNAME record points to another CDN or proxy provider (for example, AWS CloudFront, Akamai, Fastly), proxying it through Cloudflare can cause conflicts between the two proxies:
- SSL negotiation failures: Both proxies attempt to terminate TLS, which creates certificate chain errors.
- Routing loops: Each proxy forwards requests back to the other.
- Connectivity errors: The upstream CDN rejects requests from Cloudflare's IP addresses.
Cloudflare automatically prevents proxying for some known targets. For targets that are not automatically blocked, set the record to DNS-only if you experience connectivity issues.
Some third-party services validate the origin IP address of incoming API calls or webhook deliveries. When you proxy the DNS record for an endpoint that sends outbound requests or receives webhooks, the remote service sees Cloudflare's IP addresses instead of your server's IP address. This causes the validation to fail.
If a third-party service requires IP-based validation and does not accept Cloudflare's IP ranges ↗, set the record for that service to DNS-only.