In the Cloudflare dashboard, every DNS record has a little cloud icon next to it. Orange means the record is proxied through Cloudflare; grey means it is DNS only. That one toggle changes what the rest of the internet sees when it looks up your domain, and it explains why a DNS lookup of a Cloudflare-fronted site returns Cloudflare's addresses instead of your server's. Here is exactly what each setting does and when to use which.
The two states of the cloud
The orange cloud and the grey cloud are two fundamentally different modes, not just a styling choice.
- Orange cloud (Proxied): Cloudflare answers DNS queries with its own anycast IP addresses. Traffic to your domain hits Cloudflare's network first, which then forwards requests to your origin server. Your real server IP is hidden.
- Grey cloud (DNS only): Cloudflare acts as a plain authoritative DNS provider. It returns your actual record value, and visitors connect straight to your origin. No proxying, no caching, no protection.
Only A, AAAA, and CNAME records can be proxied, because only those terminate a web connection Cloudflare can sit in front of. Records like MX, TXT, NS, and SRV are always DNS only; Cloudflare greys them out automatically.
What a lookup returns in each mode
This is the part that confuses people checking their records. When a record is proxied, a public DNS lookup does not show your origin IP at all. It shows Cloudflare anycast addresses.
# Proxied (orange cloud): you get Cloudflare IPs
$ dig +short www.example.com
104.21.52.12
172.67.183.44
# DNS only (grey cloud): you get the real origin
$ dig +short www.example.com
203.0.113.25
Both are correct. If you expected to see your server's address and instead got something in Cloudflare's ranges (104.16.0.0/13, 172.64.0.0/13, and others), the record is simply proxied. That is the orange cloud working as designed.
What the orange cloud actually changes
Turning on proxying does far more than hide an IP. Because traffic now flows through Cloudflare, you gain a stack of features that only apply in proxied mode.
| Capability | Proxied (orange) | DNS only (grey) |
|---|---|---|
| Origin IP hidden | Yes | No |
| DDoS protection and WAF | Yes | No |
| CDN caching of static assets | Yes | No |
| Cloudflare SSL/TLS at the edge | Yes | No |
| Page Rules, Workers, redirects | Yes | No |
| Analytics and bot management | Yes | Limited |
| Real visitor IP at origin | Via header | Native |
One consequence worth calling out: in proxied mode your origin sees Cloudflare's IP as the source of every request. The visitor's real address arrives in the CF-Connecting-IP header (or X-Forwarded-For), so any logging or rate limiting at your origin must read that header instead of the connection IP.
When to use DNS only (grey cloud)
Proxying is not always what you want. Choose DNS only in these situations:
- Non-HTTP services. Proxying only handles HTTP and HTTPS on supported ports. A record for SSH, a game server, a mail server, SMTP, or a database must be grey, or the service will not reach the origin.
- Verifying origin changes. During a server migration, set the record to DNS only temporarily so you can confirm the origin responds directly before putting Cloudflare back in front.
- TXT and MX-adjacent hosts. A hostname that mail or verification systems must reach directly should not be proxied.
- Certificate validation. Some external services that validate domain control over a specific host need to see the real origin during issuance.
A classic mistake is proxying the hostname your mail server connects to. If mail.example.com is orange, inbound SMTP breaks because Cloudflare does not proxy port 25. Keep mail-related A records grey.
SSL/TLS modes interact with the cloud
When a record is proxied, Cloudflare terminates TLS at its edge and then makes a second connection to your origin. The SSL/TLS encryption mode controls that second hop, and getting it wrong causes redirect loops or insecure connections.
- Flexible: encrypts browser to Cloudflare only; Cloudflare to origin is plain HTTP. Avoid this; it can cause loops and is not truly end to end.
- Full: encrypts both hops but does not validate the origin certificate.
- Full (strict): encrypts both hops and validates the origin certificate. This is the recommended setting, usually paired with a free Cloudflare Origin CA certificate on your server.
These modes only matter when the cloud is orange. In DNS-only mode, TLS is entirely between the visitor and your origin, and Cloudflare is not involved in the handshake.
A common migration gotcha
Teams moving a site onto Cloudflare often import their existing records, and Cloudflare proxies most of them automatically. That is fine for the website host, but it quietly breaks anything that is not plain web traffic. Walk the record list and set the right state deliberately.
- Root and www A/CNAME records for the website: orange, so you get the CDN, WAF, and hidden origin.
- mail, smtp, imap, or pop hostnames: grey, because Cloudflare does not proxy mail protocols.
- FTP, SSH, RDP, or database hosts: grey, for the same reason.
- Subdomains pointed at third-party services that do their own TLS and host validation: usually grey unless the provider documents Cloudflare support.
The symptom of getting this wrong is almost always "the website works but email stopped," and the fix is to grey-cloud the mail-related records. Because MX records cannot be proxied anyway, the break is usually an A record that the MX target depends on.
How to toggle the cloud
In the Cloudflare dashboard, open DNS, find the record, and click the cloud icon in the Proxy status column to switch between Proxied and DNS only. The change takes effect almost immediately because Cloudflare controls its own authoritative answers, though resolvers that cached the previous value will hold it until the TTL expires. Proxied records always report an "Auto" TTL, because the TTL is managed by Cloudflare's edge rather than set by you.
Checking your work
After flipping the cloud, confirm the change from outside your own network. A quick dig shows which mode is live:
# Confirm whether the record is proxied now
$ dig +short example.com
# Check that mail records stayed DNS only
$ dig MX example.com +short
Because a cached answer can make the old mode linger in some regions, verifying from a single machine can mislead you. Run your hostname through the Valla DNS propagation checker to see, across many networks at once, whether resolvers are returning Cloudflare's proxied addresses or your origin. If you are troubleshooting why a lookup "shows the wrong IP," our guides on why a checker returns different IPs by location and on reading a dig response will usually close the case. In most instances, the wrong IP is simply the orange cloud doing precisely what it is supposed to do.