Cloudflare DNS: Records, Proxy Status, and Verification

Cloudflare exposes two related decisions in one DNS form: which DNS record to publish and whether compatible HTTP/HTTPS traffic should pass through Cloudflare’s reverse proxy. A correct record with the wrong proxy status can behave very differently from the intended design.

This guide focuses on the information to collect, the current product behavior to expect, and the checks to run after saving a record.

Collect the Cloudflare-specific inputs

Write down:

• the full hostname
• the target supplied by the origin or platform
• the required record type
• whether the workload is HTTP/HTTPS, verification-only, email, or another protocol
• whether the origin is intended to be exposed directly
• the certificate and host-binding plan
• the previous value and proxy status, if this is a change

Use the A record and CNAME decision guide when the target format is unclear. Provider documentation takes precedence over a generic preference.

Keep DNS data and proxy status separate

For eligible record types, Cloudflare stores an origin target and separately controls how clients reach it:

Status	DNS response	HTTP/HTTPS request path
Proxied	Cloudflare anycast addresses	Client → Cloudflare → origin
DNS only	Actual origin address or unproxied alias result	Client → origin

Only A, AAAA, and CNAME records used for address resolution can be proxied. MX, TXT, and other record types remain DNS only.

Cloudflare recommends proxying A, AAAA, and CNAME records that serve web traffic. Records used for third-party verification, mail-related routing, unsupported protocols, or services whose provider requires direct DNS may need to stay DNS only.

Create the record that matches the target

In the Cloudflare dashboard, open the zone’s DNS Records page, select Add record, choose the type, complete its fields, set proxy status where available, and save.

These are illustrative form values:

Type: A
Name: web
IPv4 address: 192.0.2.10
Proxy status: Proxied
TTL: Auto

Type: CNAME
Name: verify
Target: vendor-validation.example
Proxy status: DNS only
TTL: Auto

The first represents an HTTP origin intentionally placed behind Cloudflare. The second represents a hypothetical validation record that a vendor needs to inspect directly. Both use reserved documentation values and must be replaced with the real service instructions.

Choose proxy status for the workload

Proxied web traffic

When an A, AAAA, or CNAME record is proxied:

• DNS queries return Cloudflare anycast addresses rather than the configured origin address
• compatible HTTP/HTTPS traffic reaches Cloudflare first
• Cloudflare can apply enabled caching, WAF, redirect, TLS, and other edge settings
• a proxied CNAME is flattened by default and normally returns Cloudflare addresses

The origin still needs to accept traffic for the public hostname and meet the selected Cloudflare SSL/TLS mode.

DNS-only records

When a record is DNS only, Cloudflare remains authoritative for the DNS answer but does not proxy the connection. For an address record, a public query reveals the origin IP.

Use DNS only when the workload or destination requires it, not merely because the first proxied request failed. First identify whether the failure is caused by host routing, TLS mode, an unsupported port or protocol, or a platform-specific domain requirement.

Cloudflare lists third-party verification records and non-web services among common DNS-only cases. Some SaaS providers also require their own direct DNS configuration.

Use Cloudflare’s actual TTL controls

Cloudflare’s current TTL behavior is:

• Proxied records: Auto, currently 300 seconds, and not editable
• DNS-only records: Auto is 300 seconds; custom values range from 60 seconds to one day on non-Enterprise zones and from 30 seconds to one day on Enterprise zones

Therefore, “set a proxied record to 300 seconds” is not a dashboard step; Cloudflare already enforces that Auto value. A local cache can still make an observed change take longer than five minutes.

For a planned DNS-only migration, lower the editable TTL early enough for the previous TTL to expire. The DNS cache and propagation guide explains why changing TTL immediately before the target does not shorten already cached answers.

Verify the answer shape

Query the public hostname through independent resolvers:

dig @1.1.1.1 web.example.com A +noall +answer
dig @8.8.8.8 web.example.com A +noall +answer

Expected interpretation:

• a proxied hostname returns Cloudflare addresses, not the origin IP
• a DNS-only A record returns the configured origin IPv4 address
• a DNS-only CNAME exposes the alias chain
• a proxied CNAME may return flattened Cloudflare A and AAAA answers rather than a visible CNAME

Do not declare a proxied record incorrect simply because dig does not reveal the target stored in the dashboard. That origin masking is part of the proxy behavior.

Illustrated change record

Illustrative example using reserved example domains and IPs. The following SVG is a constructed dashboard-and-terminal teaching aid, not a Cloudflare account capture. Any provider-like target or edge response in it is non-live sample data.

Illustrative example using reserved example domains and IPs. It contains no account identifier, zone export, or production traffic evidence.

Use a real change record to capture the before and after values, operator, time, and validation results without publishing secrets or origin details.

Test the public request path

After the DNS answer has the expected shape, test the application:

curl -I https://web.example.com

Substitute the real hostname. Inspect:

• TLS validity for the public name
• status and redirect location
• expected application or API response
• whether Cloudflare response headers are present when proxying is intended
• whether the origin recognizes the requested hostname

If DNS is correct and Cloudflare returns a 502, 521, 522, 523, 524, or 525-class error, use Cloudflare’s error-specific documentation and inspect the origin path. Repeated record changes can hide the original problem.

Separate common failure modes

The origin target is right but the public host is unknown

The server or SaaS platform has not registered the custom domain. Complete its domain-binding step and certificate process.

DNS-only exposes an origin that was meant to be private

Changing from Proxied to DNS only changes both routing and what public DNS reveals. Review firewall rules and exposure before making that switch.

A provider-validation CNAME was proxied

The external provider may need to see the exact CNAME target. Follow its instructions and keep verification records DNS only when required.

A proxied CNAME appears as A or AAAA answers

Cloudflare flattens proxied CNAMEs. Verify the configured target in the authenticated dashboard or API and verify the public request through the returned Cloudflare addresses.

A five-minute TTL is treated as a five-minute guarantee

Cloudflare documents that local caches can extend the time before a user observes the change. Inspect authoritative and recursive state rather than relying on elapsed time alone.

Keep a concise operational record

Before closing the change, record:

• name, type, and target
• Proxied or DNS only
• TTL behavior
• reason for the proxy decision
• origin owner and host binding
• TLS status
• resolver checks
• HTTP or application check
• rollback value

For the complete cross-layer sequence, continue with subdomain DNS, routing, and HTTPS setup. A Cloudflare dashboard save is one step in that endpoint lifecycle, not the completion signal by itself.