Part 3 walked through adding your domain to Cloudflare, configuring your nameservers, and watching the orange cloud appear for the first time. That's the foundation. But once your domain is live inside Cloudflare's dashboard, you're immediately staring at a DNS records table that expects you to know what you're doing. Most people don't. Not yet.
This part fixes that.
DNS records are not complicated once someone explains them plainly. The problem is that most documentation assumes you already understand what a resolver is, what a zone file looks like, or why an MX record can't point to an IP address. This article assumes none of that. It starts from zero and builds to the point where you can configure every major record type with confidence, understand what Cloudflare is doing behind the scenes, and avoid the mistakes that cause email to vanish or websites to stop loading.
Six record types. All of them covered here: A records, AAAA records, CNAME records, MX records, and TXT records. By the end of this part, you'll know what each one does, when to use it, and how Cloudflare's proxy layer changes the equation.
What DNS Records Actually Do (And Why They Matter)
DNS as the Internet's Phone Book
Your domain name is a human-readable label. Computers don't use labels. They use numbers, specifically IP addresses, to find each other across a network. DNS is the system that bridges those two worlds. When someone types your domain into a browser, a DNS resolver (usually operated by their ISP or a service like Cloudflare's 1.1.1.1) looks up your domain and asks a simple question: where does this go?
The answer lives in your DNS zone, a collection of records that act as instructions. Each record tells resolvers something specific. This record sends web traffic here. That record routes email there. Another record proves you own the domain to a third-party service. Resolvers worldwide read these instructions constantly, billions of times per day, and the whole system works because the rules are standardized.
How Cloudflare Fits Into the Picture
When you add your domain to Cloudflare and point your nameservers at Cloudflare's infrastructure, Cloudflare becomes the authoritative host for your DNS zone. That means Cloudflare's servers are the ones answering resolver queries about your domain.
Cloudflare also adds something standard DNS doesn't include: an optional proxy layer. When a record is set to proxied, traffic passes through Cloudflare's network before reaching your server. When it's DNS-only, Cloudflare simply answers with your real IP and steps aside. That distinction matters for certain record types, and this article will flag it wherever it's relevant. No prior networking knowledge required. The concepts build on each other as you read.
A Records: Pointing Your Domain to an IP Address
What an A Record Looks Like
The A record is the most fundamental record in DNS. It maps a hostname to an IPv4 address, which is the four-part number format you've seen everywhere: something like 203.0.113.10. When a resolver asks "where does example.com live?", an A record is usually what answers.
Every A record has four components. The Name field holds the hostname, which could be your root domain or a subdomain like www or mail. The Type field is simply A. The Value field holds the IPv4 address. The TTL (Time to Live) tells resolvers how long to cache the answer before checking again, expressed in seconds. Cloudflare defaults to Auto TTL for proxied records, which it manages internally.
One thing that trips up beginners: the @ symbol. In Cloudflare's dashboard, @ is shorthand for the apex domain, meaning the root of your domain with no subdomain prefix. An A record with a Name of @ applies to example.com directly. An A record with a Name of www applies to www.example.com.
Example: Connecting Your Root Domain to Your Web Server
Say your hosting provider gives you a server at 203.0.113.10. You want example.com to load your site. The A record you'd create looks like this:
- Name:
@ - Type:
A - Value:
203.0.113.10 - TTL: Auto
- Proxy: Proxied (orange cloud)
That single record is enough to make your root domain resolve to your server. Add a second A record with the Name www pointing to the same IP and both example.com and www.example.com reach your server.
You can also create multiple A records for the same hostname pointing to different IP addresses. Resolvers will return all of them, and clients will try each one. This is a basic form of load distribution and failover, useful if you're running multiple servers.
On the proxy question: for most web-facing A records, proxied is the right choice. It hides your server's real IP address, enables Cloudflare's CDN caching, and activates DDoS protection. DNS-only makes sense when the service behind the record can't work through Cloudflare's proxy, which comes up most often with non-HTTP traffic like game servers or certain VPN configurations. Part 7 covers the proxy layer in full detail.
AAAA Records: The IPv6 Equivalent
IPv4 vs IPv6 at a Glance
The internet ran out of IPv4 addresses. That's not a prediction or a concern for the future. It happened. The IPv4 address space contains roughly 4.3 billion unique addresses, and the last unallocated blocks were distributed to regional registries years ago. The solution was IPv6, a newer addressing scheme that uses 128-bit addresses instead of 32-bit ones, producing an address space so large that every device on earth could have billions of unique addresses and still not exhaust it.
An IPv6 address looks different from what you're used to. Instead of 203.0.113.10, you get something like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Eight groups of four hexadecimal characters, separated by colons. The AAAA record does exactly what the A record does, mapping a hostname to an address, but for IPv6 instead of IPv4.
When You Actually Need an AAAA Record
If your hosting provider assigns you an IPv6 address alongside your IPv4 address, add an AAAA record. It's not complicated. The structure is identical to an A record: Name, Type (AAAA), Value (your IPv6 address), and TTL. Visitors with IPv6 connectivity will resolve your domain faster because their traffic doesn't need to traverse any IPv4 translation layer.
Cloudflare Handles Some of This Automatically
When your A record is proxied through Cloudflare, Cloudflare exposes your site over both IPv4 and IPv6 automatically, even if your origin server only has an IPv4 address. You don't need to add an AAAA record in that case. AAAA records matter most when you're running DNS-only mode or when your origin server is genuinely IPv6-capable and you want direct IPv6 connections.
The practical advice for beginners: if your host gives you an IPv6 address, add the AAAA record alongside your A record. If they don't give you one, don't worry about it. Cloudflare's proxy covers the gap for most use cases.
CNAME Records: Aliases That Follow the Chain
How a CNAME Differs From an A Record
A CNAME record doesn't point to an IP address. It points to another hostname. That's the entire distinction, and it's an important one. Where an A record says "this hostname lives at this IP," a CNAME says "this hostname is an alias for that other hostname." The resolver follows the chain until it finds an A or AAAA record with an actual address.
That chain matters. If www.example.com has a CNAME pointing to example.com, and example.com has an A record pointing to 203.0.113.10, then a resolver looking up www.example.com follows two steps: CNAME to example.com, then A record to 203.0.113.10. The end result is the same IP, but the path is different.
Example: The www Subdomain Redirect
The most common CNAME setup is pointing www to the root domain so both addresses reach the same site without maintaining two separate A records. In Cloudflare's dashboard, that looks like this:
- Name:
www - Type:
CNAME - Value:
example.com - TTL: Auto
- Proxy: Proxied
Now if your server's IP address changes, you update one A record and both example.com and www.example.com follow automatically. That's the practical value of the alias approach.
CNAMEs are also how you connect subdomains to third-party services. Deploying a site on Vercel? They'll give you a hostname like cname.vercel-dns.com and ask you to create a CNAME record pointing your subdomain there. Netlify does the same. The CNAME lets those platforms route your traffic without needing your server's IP address.
CNAME Flattening and the Apex Domain Problem
Standard DNS has a rule: you cannot use a CNAME at the apex domain (the root, represented by @). The technical reason is that a CNAME at the root would conflict with other records that must exist there, like SOA and NS records. Most DNS providers enforce this strictly.
Cloudflare doesn't enforce it the same way, because Cloudflare implements CNAME Flattening. When you set a CNAME at the root, Cloudflare's resolver follows the chain internally and returns the final IP address to the querying resolver as if it were a plain A record. The CNAME behavior happens behind the scenes. The outside world sees a normal A record response. This matters when you're deploying a site on a platform that only gives you a CNAME target and expects you to point your root domain at it.
One firm rule: don't build CNAME chains that are unnecessarily long. Each hop is a separate DNS lookup. Three or four hops deep is a configuration that will cause intermittent slowness and be nearly impossible to debug under pressure.
MX Records: Routing Email to the Right Place
Anatomy of an MX Record
MX records tell the internet's mail infrastructure where to deliver email for your domain. When someone sends a message to [email protected], their mail server performs a DNS lookup for example.com MX records and then delivers the message to whatever server those records specify.
MX records have two fields that A and CNAME records don't. The first is the mail server hostname, which must be a valid hostname with its own A or AAAA record. The second is a priority number, which tells sending servers which mail server to try first when multiple MX records exist for the same domain.
Priority Values and What They Mean
Lower priority numbers mean higher preference. A mail server with priority 1 gets tried before one with priority 5. If the priority-1 server is unavailable, the sending server falls back to priority 5. This is how redundant mail delivery works.
Never Proxy MX Records
MX records must always be set to DNS-only in Cloudflare. Never proxied. The Cloudflare proxy handles HTTP and HTTPS traffic. It does not handle SMTP, which is the protocol email uses. Proxying an MX record will cause incoming email to fail silently. Cloudflare's dashboard will usually warn you about this, but the warning is easy to dismiss by accident.
Example: Setting Up Google Workspace or Microsoft 365 Email
Google Workspace requires five MX records. A simplified two-record version illustrates the structure clearly:
- Name:
@| Type:MX| Value:aspmx.l.google.com| Priority:1 - Name:
@| Type:MX| Value:alt1.aspmx.l.google.com| Priority:5
Microsoft 365 uses a single MX record with a hostname that looks like yourdomain-com.mail.protection.outlook.com. The structure is the same: Name, Type, Value (hostname), Priority.
Two rules to keep in mind. First, MX record values must always be hostnames, never IP addresses directly. The DNS specification forbids it, and most mail servers will reject or ignore IP-addressed MX records. Second, incorrect MX records are the single most common cause of lost email. When email stops working after a DNS change, the MX records are the first place to check. Propagation can take up to 48 hours, but most changes resolve within an hour when TTLs are set reasonably.
TXT Records: Verification, Security, and Everything Else
What TXT Records Are Used For
TXT records are the most flexible record type in DNS. They store free-form text that DNS serves to anyone who queries for it. That sounds simple, and it is. But the uses are surprisingly broad because so many systems have adopted TXT records as a lightweight way to publish machine-readable instructions and proof-of-ownership tokens without requiring any new DNS record types.
The most common uses you'll encounter:
- Domain ownership verification: Google Search Console, Bing Webmaster Tools, and dozens of other services ask you to add a unique TXT record to prove you control the domain.
- SPF (Sender Policy Framework): specifies which mail servers are authorized to send email on behalf of your domain.
- DKIM (DomainKeys Identified Mail): publishes a public key that receiving mail servers use to verify your outgoing email wasn't tampered with.
- DMARC: tells receiving servers what to do with email that fails SPF or DKIM checks.
Example: Domain Verification for Google Search Console
Google Search Console's HTML tag verification method requires no server access. The TXT record method is cleaner. Google gives you a string that looks like google-site-verification=abc123XYZsomeLongString. You create a TXT record at your root domain with that exact string as the value:
- Name:
@ - Type:
TXT - Value:
google-site-verification=abc123XYZsomeLongString
Google's verification crawler queries your domain's TXT records, finds the string, and confirms ownership. The record can stay there permanently without causing any problems.
Multiple TXT Records on the Same Hostname
Unlike A records where multiple entries create load balancing, multiple TXT records on the same hostname simply coexist. Resolvers return all of them. This is how you can have a domain verification record, an SPF record, and a DMARC record all sitting at @ simultaneously without conflict.
There is one exception worth burning into memory. Only one SPF record is allowed per hostname. If you have multiple email senders (say, your main mail provider plus a transactional email service like SendGrid), you cannot create two
SPF, DKIM, and DMARC: The Email Authentication Trio
Email is the most impersonated communication channel on the internet. Anyone can send a message that claims to come from your domain. Without the right DNS records in place, there's nothing stopping a scammer from crafting an email that looks exactly like it came from you, complete with your domain in the From field. SPF, DKIM, and DMARC are the three DNS records that fix this. Together, they form a verification chain that tells receiving mail servers whether a message claiming to be from your domain actually is.
SPF: Who Is Allowed to Send Email for Your Domain
SPF stands for Sender Policy Framework. It lives in a TXT record at your root domain and lists the mail servers and services that are authorized to send email on your behalf.
A minimal SPF record for Google Workspace looks like this:
v=spf1 include:_spf.google.com ~allThe include:_spf.google.com part tells receiving servers to check Google's published list of sending IPs. The ~all at the end is a soft fail directive: if a message comes from a server not on the list, treat it with suspicion but don't outright reject it. When you're confident your SPF record is complete, you can move to -all for a hard fail.
SPF alone isn't enough. It verifies the sending server, not the message content itself.
DKIM: Cryptographic Proof That an Email Is Genuine
DKIM stands for DomainKeys Identified Mail. It works by attaching a cryptographic signature to outgoing messages. The receiving server checks that signature against a public key stored in your DNS. If the signature matches, the message is verified as genuine and unmodified in transit.
The DKIM record lives at a subdomain formatted like this:
google._domainkey.example.comThe value is a long TXT record containing a public key. You don't generate this yourself. Your email provider generates the key pair and gives you the public key to paste into DNS. Google Workspace, Microsoft 365, and every major provider handles this through their admin console. Your job is to copy the value they give you and create the record accurately.
DMARC: The Policy That Ties SPF and DKIM Together
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It's a TXT record placed at _dmarc.example.com that tells receiving servers what to do when a message fails SPF or DKIM checks.
A starter DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]The p=none policy means: monitor and report, but don't take action yet. The rua tag specifies where aggregate reports get sent. You'll receive regular emails summarizing who is sending mail that claims to be from your domain.
The progression goes like this. Start with p=none to gather data and understand your sending sources. Once you're confident all legitimate mail is passing authentication, move to p=quarantine so failing messages land in spam. When you're fully confident, move to p=reject so failing messages are blocked entirely.
The numbers make the argument clearly. Domains without DMARC are dramatically easier to spoof, and attackers know it.
A Real-World Example: Full Email Auth Setup
Here's what a complete email authentication setup looks like for a domain using Google Workspace. All three of these records must be set to DNS-only in Cloudflare. Proxying TXT records doesn't apply, and attempting to proxy MX or TXT records will break delivery.
"SPF says who can send. DKIM proves the message wasn't tampered with. DMARC decides what happens when either check fails. You need all three working together before your email authentication story is complete."
The three records together take maybe fifteen minutes to configure. The protection they provide is permanent. There's no good reason to skip them.
CAA Records: Controlling Which CAs Can Issue SSL Certificates
Most website owners never think about which certificate authority issued their SSL certificate. The browser shows a padlock, the certificate is valid, and that feels like enough. The problem is that the certificate authority system has a structural weakness: any CA trusted by browsers can technically issue a certificate for any domain. A CAA record closes that gap.
Why CAA Records Exist
CAA stands for Certification Authority Authorization. It's a DNS record that tells the world which certificate authorities are permitted to issue SSL/TLS certificates for your domain. If a CA that isn't on your list attempts to issue a certificate, the issuance fails. Compliant CAs are required to check CAA records before issuing.
The security benefit is real. Fraudulent certificates have been issued in the past, sometimes through compromised CA infrastructure and sometimes through social engineering. CAA records don't eliminate every attack vector, but they significantly raise the bar.
Example: Locking Your Domain to Let's Encrypt or DigiCert
A CAA record has three components: a flag, a tag, and a value. The two most important tags are issue (controls standard certificate issuance) and issuewild (controls wildcard certificate issuance separately). There's also iodef, which lets you specify a URL or email address where a CA should send a report if it receives a request it can't fulfill due to your CAA policy.
1example.com. CAA 0 issue "letsencrypt.org"
2example.com. CAA 0 issue "pki.goog"
3example.com. CAA 0 issuewild "letsencrypt.org"
4example.com. CAA 0 iodef "mailto:[email protected]"This setup allows Let's Encrypt and Google's CA to issue certificates, blocks everyone else, and sends a report if an unauthorized issuance is attempted.
Cloudflare Universal SSL and CAA Records
Cloudflare automatically adds CAA records for its own Universal SSL when your domain is proxied. If you add custom CAA records manually, make sure Cloudflare's own CA entries are included. Removing them while Cloudflare is managing your SSL will cause certificate renewal failures.
CAA records are optional. For a personal blog or low-stakes project, you can skip them. For anything handling user accounts, payments, or sensitive data, they're worth the five minutes it takes to add them.
TTL: How Long DNS Records Are Cached
DNS doesn't work like a live phone book lookup every time someone visits your site. Resolvers cache the answers they get so they don't have to ask again for every request. TTL, or Time To Live, is the number of seconds a resolver is allowed to hold onto a cached DNS record before it fetches a fresh copy.
What TTL Actually Controls
Set a TTL of 3600 and resolvers cache your record for an hour. Set it to 300 and they check back every five minutes. The number controls how quickly changes you make in Cloudflare propagate to the rest of the internet.
That default sounds alarming, but in practice most resolvers don't hold records for the full TTL duration. Still, the number matters when you're planning changes.
Choosing the Right TTL for Different Situations
Before a planned migration, IP change, or any DNS edit that needs to take effect quickly, drop your TTL to 60 or 300 seconds at least 24 to 48 hours in advance. That way, by the time you make the actual change, the old record has already expired from most caches. After the migration is stable, raise the TTL back to something reasonable like 3600 or higher.
TTL Behavior When Cloudflare Proxy Is Enabled
When a record is proxied through Cloudflare, the TTL you set is mostly academic from the outside world's perspective. Cloudflare overrides the external TTL to 300 seconds for proxied records. Resolvers see Cloudflare's IP address, not yours, and Cloudflare controls how long that gets cached.
For DNS-only records, Cloudflare respects whatever TTL you configure. The Auto TTL option in Cloudflare's dashboard defaults to 300 seconds for most record types. It's a reasonable starting point for most setups, and you can always override it manually when you need tighter control.
Proxied vs DNS-Only: Cloudflare's Orange Cloud Explained
Every DNS record you create in Cloudflare has a small cloud icon next to it. Orange means proxied. Grey means DNS-only. This single toggle controls whether Cloudflare sits between your visitors and your server, and the implications run deeper than most beginners expect.
What Happens When You Enable the Proxy
When the cloud is orange, traffic flows through Cloudflare's global network before it reaches your server. Your real server IP is hidden. Visitors connect to Cloudflare's edge, and Cloudflare connects to your origin on their behalf. In exchange, you get DDoS protection, caching, Web Application Firewall rules, and every other Cloudflare performance and security feature.
When the cloud is grey, Cloudflare publishes your real IP address directly in DNS. Anyone who queries your domain gets your server's actual IP. Cloudflare is acting purely as a DNS host, nothing more.
Which Record Types Can Be Proxied
Only A records, AAAA records, and CNAME records support proxying. These are the record types associated with web traffic. Everything else must stay DNS-only.
MX, TXT, CAA, NS, and SOA records are always DNS-only. Cloudflare doesn't even offer the orange cloud toggle for most of these. The reason is straightforward: Cloudflare's proxy only handles HTTP and HTTPS traffic. Email, certificate authority checks, and nameserver lookups operate on completely different protocols that the proxy layer can't handle.
Don't Proxy Your MX Records
This is the most common DNS mistake in Cloudflare. If you somehow proxy an MX record or point email traffic through the Cloudflare proxy, mail delivery breaks. Email servers can't deliver through an HTTP proxy. Keep every MX record grey, always.
When to Use DNS-Only Mode
Beyond the record types that require it, there are situations where you'll want to disable the proxy even for A or CNAME records. If you need to SSH into your server, the Cloudflare proxy doesn't pass port 22 traffic by default. Same for most non-HTTP services. In those cases, either use DNS-only mode for that specific record or look into Cloudflare Spectrum, which extends proxy support to arbitrary TCP and UDP ports. For most small sites, DNS-only on your SSH subdomain is the simpler path.
Putting It All Together: A Complete DNS Setup Walkthrough
Reading about record types in isolation is useful. Watching them come together for a real domain makes everything click. Here's a complete walkthrough from zero to fully configured.
Scenario: Launching a New Website With Email
The setup: a small business is launching example.com. They're hosting their website on a VPS with the IP address 203.0.113.42. They're using Google Workspace for email. They want Cloudflare's proxy protection on their web traffic, proper email authentication, and a clean, verifiable DNS configuration.
Record-by-Record Build
Step 1: A record for the root domain. Create an A record with the name @ pointing to 203.0.113.42. Set it to proxied (orange cloud). This is the record that makes example.com resolve to your web host.
Step 2: CNAME for www. Create a CNAME record with the name www pointing to example.com. Set it to proxied. This ensures www.example.com works the same way as the root.
Step 3: MX records for Google Workspace. Add all five Google Workspace MX records with their correct priority values. Every single one must be DNS-only. No exceptions.
Step 4: SPF TXT record. Create a TXT record at @ with the value v=spf1 include:_spf.google.com ~all. DNS-only.
Step 5: DKIM TXT record. In your Google Workspace admin console, generate your DKIM key. Copy the subdomain name (something like google._domainkey) and the long TXT value. Create the record exactly as Google specifies. DNS-only.
Step 6: DMARC TXT record. Create a TXT record at _dmarc with the value v=DMARC1; p=none; rua=mailto:[email protected]. DNS-only. You'll refine this policy over time as reports come in.
Step 7: Google Search Console verification. Google provides a TXT record value for domain verification. Add it as a TXT record at @. DNS-only.
Step 8: CAA record (optional but recommended). Add a CAA record allowing letsencrypt.org to issue certificates. If Cloudflare is managing your SSL, make sure to include Cloudflare's CA entry as well.
Here's the full record table at a glance:
| Type | Name | Value | Proxy |
|---|---|---|---|
| A | @ | 203.0.113.42 | Proxied |
| CNAME | www | example.com | Proxied |
| MX | @ | aspmx.l.google.com (priority 1) | DNS-only |
| TXT | @ | v=spf1 include:_spf.google.com ~all | DNS-only |
| TXT | google._domainkey | (DKIM public key from Google) | DNS-only |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:[email protected] | DNS-only |
| TXT | @ | (Google Search Console verification token) | DNS-only |
| CAA | @ | 0 issue "letsencrypt.org" | DNS-only |
Two records are proxied. Everything else is DNS-only. That pattern holds for most standard website plus email configurations.
Your DNS Setup Checklist and Next Steps
DNS Records Checklist
Open your Cloudflare DNS dashboard and run through this list. Every item either applies to your domain or has a reason why it doesn't. If you can't answer why a record is configured the way it is, that's worth investigating before you move on.
