DNS-only and proxied records

A DNS-only record returns the configured destination. The client then connects to that address.

With a proxied web record, Cloudflare returns Cloudflare anycast addresses instead of the configured origin address. The request path becomes:

browser -> Cloudflare proxy -> origin server

The proxy can apply caching, DDoS protection, WAF rules, redirects, and edge TLS behavior. This also means a dig result for a proxied hostname should not match the origin IP.

With DNS-only mode, the path is direct:

client -> configured destination

The origin address is publicly visible, and Cloudflare cannot apply its HTTP protections or caching to that traffic.

Only eligible A, AAAA, and CNAME records serving supported HTTP or HTTPS traffic can use the ordinary proxy. MX and TXT records are always DNS-only. The A or AAAA hostname used by a mail server must also remain DNS-only so SMTP clients reach the mail server rather than Cloudflare’s web proxy.

Proxying adds another contract. Cloudflare must be able to reach the origin, the origin must accept the requested hostname, and its TLS mode and certificate must match the configuration. A healthy DNS answer can still lead to a proxy error when that origin connection fails.

Do not rely only on hiding the origin address. Restrict origin access to intended proxy traffic where practical, and ensure no DNS-only sibling record exposes the same origin unintentionally.

Compare evidence:

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

The first command shows where clients connect. The second exercises the proxy and origin path. An HTTP error does not automatically mean DNS is wrong.

Your action is to classify five records—website A, website CNAME, MX, domain-verification TXT, and mail-server A—as proxied or DNS-only, and explain the traffic path for each.