Cloudflare Proxied vs DNS Only: Choose by Hostname and Service

Web Hosting & Domains · Cloudflare DNS · Configuration guide

Use Proxied for compatible website hostnames when you want their HTTP/HTTPS traffic to pass through Cloudflare. Use DNS only for services that must connect directly, including ordinary mail hostnames and many verification records. Choose by the service behind each name, not by turning every cloud icon orange.

The decision affects more than a DNS lookup. It changes the path a request takes and which system must handle certificates, filtering and troubleshooting. Make a small inventory before changing an unfamiliar record.

Proxied and DNS-only change where web traffic goes

Cloudflare’s proxy-status documentation explains the distinction. A proxied hostname resolves to Cloudflare addresses so web requests pass through its network. DNS-only publishes the underlying record information and leaves web traffic outside that HTTP proxy.

The cloud icon does not replace the hosting account. Your application still needs a working origin and an appropriate configuration. Nor does an orange icon establish that every security or caching feature has been configured correctly.

Review the entire hostname when investigating mixed records or CNAME chains. Cloudflare documents that proxying can apply across related records; do not draw a conclusion from one row viewed in isolation.

A proxyable record type is only the first requirement

Cloudflare’s proxying limitations allow A, AAAA and CNAME records serving HTTP/HTTPS traffic to be proxied. Other record types, including MX and TXT, cannot be proxied. Some CNAME targets are intentionally ineligible, so a missing proxy option is not necessarily a dashboard fault.

Check the protocol and port as well. The ordinary proxy supports a defined list of HTTP and HTTPS ports, including 80 and 443. It is not a general-purpose relay for any application that happens to have a DNS name. An SSH service on port 22, for example, needs a suitable direct-access or separately designed proxy arrangement.

Write the intended service in plain language: “public HTTPS website,” “mail-server address,” or “provider ownership check.” A record named app does not tell you whether it serves a website, a custom TCP application or a vendor-specific endpoint.

If a hosting provider gives a special connection hostname for administration, use its documented connection method. Do not change the website’s record merely to make an unrelated file-transfer or management connection work.

Treat websites, mail and verification as separate decisions

Cloudflare’s proxy-status use cases recommend proxying compatible web services, while explaining why email and verification records often need DNS-only behavior.

Website and application hostnames

For a conventional website, evaluate the root name and www separately, along with any web subdomains. Confirm that the origin or hosted platform supports the intended setup. For a SaaS-hosted site, follow the platform’s Cloudflare instructions; do not assume an extra proxy layer is always supported.

Mail hostnames

MX records are not proxyable. An A or AAAA record dedicated to the mail server should also be DNS-only for ordinary mail service. Cloudflare’s standard HTTP proxy does not carry SMTP on port 25, so proxying the mail-server address can prevent delivery.

Use a distinct mail hostname where the provider instructs you to do so. If you are also changing email providers, our MX migration checklist covers the separate mailbox and delivery work.

Verification and vendor CNAMEs

A verification CNAME may need to return the provider’s expected target rather than Cloudflare addresses. Some providers require DNS-only permanently, not just during initial verification. Keep the provider’s purpose and instructions beside the record in your inventory.

Do not convert a verification record into a proxied website endpoint after a green success message unless the provider explicitly supports that change. Verification and ongoing service operation may depend on different checks.

Check HTTPS before turning the proxy off

Proxy status and certificate trust are related but separate settings. With proxied HTTPS, the browser connects to Cloudflare, which then connects to the origin. Cloudflare’s Full (strict) guidance requires an unexpired origin certificate issued by a publicly trusted authority or Cloudflare Origin CA, with a matching hostname.

Have the person responsible for hosting confirm the intended direct-access configuration, including certificate coverage and firewall access. A successful proxied request does not prove the same hostname will work correctly when reached directly.

If changing status produces an HTTPS error, record the exact error and determine which connection is failing. Do not make random encryption-mode changes to hide the symptom. Keep certificate work separate from DNS routing so the cause remains understandable.

Prepare a small, reversible change

Before changing a record, capture the current type, name, destination, proxy status and any relevant provider requirement. Identify the person who can restore the configuration if an important workflow fails.

1. Name the goal. For example, route one public website hostname through the proxy while preserving its destination.
2. Confirm dependencies. Check redirects, API clients, mail use, verification and third-party hosting requirements for that name.
3. Check the origin. Verify the service and HTTPS setup for the intended traffic path.
4. Choose a useful test window. Avoid combining a proxy-status change with a nameserver migration or application release.
5. Change one logical unit. Record what changed, then run the planned checks before continuing.

Ask the hosting administrator whether the application depends on client IP information. Cloudflare’s use-case guidance notes that the origin sees Cloudflare as the connecting source, with visitor IP information conveyed through headers. Applications using source IP for rate limits or access decisions need an appropriate trusted configuration.

That is a reason to coordinate the change, not to paste an arbitrary header into an access-control rule. Follow the hosting stack’s supported method for recognizing proxy traffic.

Check DNS answers and the real application

First confirm the record in the authoritative DNS configuration. Then check what a resolver returns and what the application actually does. A DNS answer alone cannot tell you whether login, checkout or mail delivery works.

If dig and curl are available, these read-only examples illustrate a basic check. Replace the example hostname with the name you manage:

dig www.example.com A
dig www.example.com AAAA
curl -I https://www.example.com/

A proxied answer normally shows Cloudflare addresses, so it need not match the origin value stored in the DNS dashboard. CNAME chains and flattening can affect the visible answer. Interpret the complete response against the intended setup rather than expecting one literal line.

The header request is only a quick diagnostic. Some applications handle HEAD requests differently, and a successful status does not establish that every page or workflow is healthy. Open the site and run an appropriate functional check.

Allow for DNS caching during a transition. Cloudflare’s DNS-only transition notes explain that recursive resolvers may retain earlier answers. Avoid repeatedly toggling status while different clients are still observing different cached responses.

Example: one website, one mail service, one booking platform

Hypothetical example: a small consultancy has a public website, an email provider and a hosted booking page. The owner wants Cloudflare’s web proxy for the website.

The administrator first identifies the root and www website records, the mail-related records and the booking provider’s verification name. The web host confirms the origin certificate and supported setup. The email and booking instructions remain separate requirements.

After the website change, the administrator checks both website names, the redirect between them and a representative form. They also verify that the mail configuration and booking verification still meet their providers’ instructions. The record inventory explains why different names have different proxy states.

The result is a service map that someone else can maintain. “Everything orange” would hide the important distinction between a website request and a record used to prove ownership or deliver email.

Frequently asked questions