Skip to main content

Cloudflare DNS Records Explained: Proxy, TTL, and CNAME Flattening

A practical guide to Cloudflare DNS records (A, AAAA, CNAME, MX, TXT), the orange-cloud proxy, TTL choices, CNAME flattening at the root, and email setup.

Published By Li Lei
#cloudflare #dns #email #devops

Cloudflare DNS Records Explained: Proxy, TTL, and CNAME Flattening

The Cloudflare DNS panel looks deceptively simple: a type dropdown, a name, a target, an orange cloud, and a TTL. Most outages I have watched start there. Someone toggles the orange cloud on a record that should never carry HTTP traffic, or stacks a second SPF line, or sets a one-day TTL right before a migration. None of those are exotic. They are the four or five mistakes everyone makes once, and this guide walks through the rules that keep you from making them.

If you want the dense version while you work, keep the Cloudflare DNS cheatsheet open in another tab. It has a searchable table plus a local checker that flags proxied mail records and duplicate policies before you save. This post is the why behind those warnings.

What each record type actually points to

Before anything else, get the targets straight, because half of all DNS confusion comes from pointing the wrong kind of value at the wrong record:

  • A points a name to an IPv4 address, like 203.0.113.10.
  • AAAA points a name to an IPv6 address, like 2606:4700::6810:84e5.
  • CNAME points a name to another name, never an IP. shop.example.com can be a CNAME to stores.shopify.com.
  • MX points a domain to a mail server hostname with a priority number, like 10 mx1.mail.example.com.
  • TXT holds plain text. In practice that means SPF policies, domain-verification tokens, and DKIM keys.

That distinction matters because the dashboard will happily let you type an IP into a CNAME field, and the record simply will not resolve. If you ever need a refresher on what a given record is for, the DNS record explainer breaks each type down with examples.

The orange cloud: proxy versus DNS-only

Every A, AAAA, and CNAME row in Cloudflare has a cloud icon. Orange means proxied: client requests hit Cloudflare's edge, and the public DNS answer is a Cloudflare IP, not your origin. Grey means DNS-only: Cloudflare just answers with your real target and steps out of the way.

The rule worth memorizing is that proxying is for web traffic. A and AAAA records that serve your site, and CNAMEs that front HTTP services, are the normal proxy candidates. Everything else should stay grey:

  • MX records must be DNS-only. Mail is not HTTP, and Cloudflare cannot stand in front of an SMTP exchange.
  • TXT records (SPF, DKIM, DMARC, verification tokens) are DNS-only by nature — there is not even a cloud toggle on them.
  • NS, SOA, SRV, and CAA stay DNS-only for the same reason: they are not web traffic.

Turning the orange cloud on for a mail-facing A record (say, the host your MX points at) is a quiet way to break inbound email, because the published address becomes a Cloudflare edge IP that does not speak SMTP. When in doubt, ask one question: does a browser ever request this over HTTP? If not, leave it grey.

TTL and Auto TTL

TTL (time to live) is how long resolvers are allowed to cache an answer. Cloudflare shows Auto for proxied records and a manual list for DNS-only ones.

Auto TTL means Cloudflare picks the cache duration, which is fine for proxied records because the answer is Cloudflare's own edge — they control it end to end. For DNS-only records you actually plan to move, set TTL deliberately. My habit before any cutover is to drop the TTL to 300 seconds a day ahead, confirm the change has propagated, then do the migration. Short TTL means a mistake clears in five minutes instead of a day. Once the new target is verified from a few different networks, I raise the TTL back up so resolvers stop hammering the zone.

CNAME flattening at the root

DNS has an old, annoying limitation: you cannot put a CNAME at the zone apex — the bare example.com — because the apex already needs SOA and NS records, and a CNAME is supposed to be the only record on its name. So pointing example.com (no www) at a host that only gives you a CNAME target, like a platform's apps.vendor.net, breaks under plain standards.

Cloudflare solves this with CNAME flattening. You enter what looks like a CNAME at the apex, and Cloudflare resolves it behind the scenes and answers clients with plain A/AAAA records. The apex stays valid, and you still track the vendor's changing IPs automatically.

The catch: this is a Cloudflare feature, not portable zone-file syntax. If you ever export the zone and import it somewhere that lacks flattening, that apex "CNAME" will not survive. Treat it as Cloudflare behavior, not a universal trick.

Worked example: a site plus its email

Say you are launching example.com on a host whose docs say "point your domain at app.examplehost.com," and your mail runs through a provider that needs SPF. Here is the record set:

Type   Name              Content                 Proxy      TTL
A      www               203.0.113.10            Proxied    Auto
CNAME  example.com       app.examplehost.com     Proxied    Auto    (flattened apex)
MX     example.com       10 mx.mailvendor.com    DNS-only   Auto
TXT    example.com       "v=spf1 include:_spf.mailvendor.com ~all"   DNS-only   Auto

Walking through it: www is a proxied A record pointing at the host's IP. The apex is a CNAME to the host that Cloudflare flattens, so example.com resolves with no separate "make it match www" juggling. The MX stays grey and carries the priority-10 mail server. The SPF lives in a single TXT record — one v=spf1 line that authorizes the vendor and soft-fails everything else with ~all.

The single most common email break here is adding a second mail sender later and publishing a second SPF TXT record. Two SPF records on the same name is invalid; receivers can return a PermError and your mail starts failing alignment. The fix is always to merge: one v=spf1 include:_spf.mailvendor.com include:_spf.newsender.com ~all. Paste your existing TXT rows into the cheatsheet's checker and it will flag the duplicate before you save.

A short checklist before you hit save

I run the same mental pass on every DNS change now, after enough self-inflicted incidents to learn it:

  • Is the orange cloud on anything that is not web-facing A/AAAA/CNAME? Turn it off.
  • Is there exactly one SPF TXT record per name? Merge if not.
  • Did I lower the TTL before a migration, and will I raise it after?
  • Am I assuming apex behavior that only works because of Cloudflare flattening?

None of these need a tool to remember, but it is faster to let the checker catch them than to debug a bounced email an hour after a deploy. DNS is one of those layers where the cost of a mistake is measured in cache lifetimes, so a thirty-second review pays for itself many times over.

Made by Toolora · Updated 2026-06-13