Part 7 built out Cloudflare's DNS fundamentals: A records, CNAMEs, proxying, TTL strategy, and the mechanics of how Cloudflare sits between your domain and the world. If you followed that section, you have a working mental model of how DNS records translate into real network behavior. That foundation matters here, because this part goes somewhere most DNS tutorials skip entirely.
Email authentication is one of the most consequential and most misunderstood areas of DNS configuration. Get it right and your messages land in inboxes. Get it wrong and you're fighting spam filters, watching deliverability rates crater, or worse, watching someone spoof your domain to send phishing email that looks like it came from you. None of that is hypothetical. It happens to real domains, including professional ones with active users, because the records were never set up correctly in the first place.
This part covers the full email DNS stack: MX, SPF, DKIM, and DMARC. Four record types. Four layers of trust. All of them managed directly in the Cloudflare DNS dashboard you've already been working in.
Why Email Deliverability Is a DNS Problem
The invisible handshake between email and DNS
When you send an email, the receiving mail server doesn't just accept it. It interrogates your domain. It checks DNS records to answer a specific set of questions: Where should mail for this domain be delivered? Is the sending server authorized to send on behalf of this domain? Does the message carry a valid cryptographic signature? Does the domain owner have a stated policy for what to do when those checks fail?
Every one of those questions is answered by DNS. Not by your email platform. Not by your inbox provider. By the records sitting in your DNS zone. If those records are missing, malformed, or conflicting, the receiving server fills in the blanks with suspicion, and suspicion means spam folders, deferred delivery, or outright rejection.
The sequence is direct. A message leaves your mail server, arrives at the recipient's mail server, and that server immediately performs a DNS lookup against your domain. It checks for SPF authorization, retrieves your DKIM public key, and reads your DMARC policy. The whole process happens in milliseconds, invisibly, before your recipient ever sees the message. Pass all three checks and the message lands in the inbox. Fail them and the outcome depends entirely on how aggressively the receiving server is configured.
What happens when DNS records are missing or wrong
Missing records are not neutral. A domain with no SPF record gets treated as if any server is allowed to send on its behalf, which is exactly the condition spammers exploit. A domain with no DMARC record gives receiving servers no policy guidance, so they make their own decisions, and those decisions are not always in your favor.
The real-world consequences stack up fast. Deliverability drops. Users start reporting that replies never arrive. Marketing campaigns show open rates so low they look broken. Eventually, if enough mail from your domain gets marked as spam, your domain ends up on a blocklist, and recovering from that takes weeks of careful work.
Cloudflare's DNS dashboard is the right place to address all of this because it gives you direct, immediate control over every record type involved. No waiting for a registrar's slow propagation pipeline. No opaque interface that hides what's actually in your zone. The four pillars covered in this article are MX records, SPF, DKIM, and DMARC, and by the end of this section you'll have a clear path to configuring all of them correctly.
MX Records: Telling the World Where to Deliver Your Email
How MX records work and what priority means
MX records, or mail exchanger records, are the DNS entries that tell the world which servers accept incoming email for your domain. When someone sends a message to [email protected], their mail server queries DNS for your domain's MX records, gets back a list of mail servers, and attempts delivery to them in priority order.
Priority is expressed as a number. Lower numbers mean higher priority. A server with priority 1 gets tried before a server with priority 10. Most enterprise mail platforms give you multiple MX records with different priority values as a redundancy mechanism. If the primary server is unavailable, delivery falls back to the next one in the list.
This matters in practice because skipping a record or entering the wrong priority can cause intermittent delivery failures that are genuinely difficult to diagnose. The message doesn't always bounce. Sometimes it just delays, retries against a lower-priority server, and eventually arrives hours late with no clear indication of what happened.
Setting MX records in Cloudflare for Google Workspace and Microsoft 365
In the Cloudflare DNS dashboard, navigate to your domain, select the DNS tab, and click Add record. Choose MX as the record type. The Name field should be set to your root domain, which Cloudflare typically represents as @. The Mail server field takes the hostname of the mail server, and the Priority field takes the numeric priority value.
For Google Workspace, add all five of these records:
| Priority | Mail Server |
|---|---|
| 1 | ASPMX.L.GOOGLE.COM |
| 5 | ALT1.ASPMX.L.GOOGLE.COM |
| 5 | ALT2.ASPMX.L.GOOGLE.COM |
| 10 | ALT3.ASPMX.L.GOOGLE.COM |
| 10 | ALT4.ASPMX.L.GOOGLE.COM |
For Microsoft 365, you'll have a single MX record. The mail server hostname follows the format yourdomain-com.mail.protection.outlook.com, where the dots in your domain name are replaced with hyphens. Microsoft provides the exact value in the Microsoft 365 Admin Center under Settings > Domains > DNS records. Priority is typically set to 0.
MX records must never be proxied
When adding MX records in Cloudflare, the proxy toggle must be set to DNS only (gray cloud). MX records are not HTTP traffic. Routing them through Cloudflare's proxy will break mail delivery entirely. Cloudflare will warn you about this, but double-check every MX record you add.
For TTL on MX records, 3600 seconds (one hour) is a reasonable default for stable configurations. If you're planning a mail platform migration in the near future, drop it to 300 seconds a day or two before the cutover so changes propagate quickly.
SPF Records: Authorizing Which Servers Can Send on Your Behalf
Anatomy of an SPF TXT record
SPF, or Sender Policy Framework, is a DNS TXT record that tells receiving mail servers which servers are authorized to send email on behalf of your domain. When a message arrives claiming to be from [email protected], the receiving server looks up the SPF record for yourdomain.com and checks whether the sending server's IP address is on the authorized list. If it isn't, the message fails SPF.
The record format starts with a version declaration and builds from there:
v=spf1 include:_spf.google.com ~allBreaking that down: v=spf1 declares the SPF version. The include: mechanism pulls in the SPF records published by a third-party sender, in this case Google. The ~all at the end is the qualifier for everything not explicitly listed.
The qualifier at the end matters significantly. ~all is a soft fail: messages from unlisted servers are accepted but marked as suspicious. -all is a hard fail: messages from unlisted servers are rejected outright. Most configurations start with ~all during the testing phase and move to -all once the record is confirmed complete and accurate.
SPF for Google Workspace, Microsoft 365, and third-party senders
In Cloudflare DNS, add a TXT record with the Name set to @ (your root domain). The Content field takes the full SPF string.
For Google Workspace:
v=spf1 include:_spf.google.com ~allFor Microsoft 365:
v=spf1 include:spf.protection.outlook.com ~allIf you also send through Mailchimp, Brevo, or SendGrid, you chain additional include: entries before the qualifier:
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendinblue.com include:sendgrid.net ~allOne SPF record only
If your domain already has an SPF record, do not add a new one. Edit the existing record to include additional senders. Multiple SPF TXT records on the same domain cause a permerror result, which is treated as an SPF failure by most receiving servers.
The SPF lookup limit problem and how to avoid it
SPF has a hard limit of 10 DNS lookups per evaluation. Every include: mechanism triggers at least one lookup, and some include targets nest additional lookups inside them. Exceed the limit and SPF evaluation fails with a permerror, regardless of whether the sending server would have been authorized.
This becomes a real problem for organizations using multiple email platforms simultaneously. Google Workspace plus Microsoft 365 plus SendGrid plus Mailchimp plus a transactional email service can push past the limit quickly.
The solution is SPF flattening: replacing include: mechanisms with the actual IP addresses they resolve to, eliminating the lookup chain. Several tools automate this process, including AutoSPF and dmarcian's SPF tools. The tradeoff is that flattened records need to be updated manually whenever a provider changes their IP ranges, so you're trading lookup efficiency for maintenance overhead. For most small to mid-sized setups with two or three senders, staying under the limit through careful include: management is the simpler path.
DKIM: Cryptographic Proof That Your Email Wasn't Tampered With
How DKIM signing works under the hood
DKIM, or DomainKeys Identified Mail, uses a public/private key pair to cryptographically sign outgoing messages. Your mail server holds the private key and uses it to sign each outgoing message, embedding that signature in the message headers. The receiving server retrieves your public key from DNS and uses it to verify the signature. If the signature is valid, the message hasn't been altered in transit and genuinely originated from a server with access to your private key.
The DNS record that makes this work lives at a specific address: selector._domainkey.yourdomain.com. The selector is a label chosen by your mail platform that allows multiple DKIM keys to coexist on the same domain, which matters when you're signing through more than one sending platform.
A 1024-bit key was acceptable a decade ago. It isn't now. When configuring DKIM for any platform that gives you a choice, select 2048-bit keys. The DNS record is slightly longer, but the security margin is meaningfully better.
Adding DKIM records for Google Workspace and Microsoft 365
For Google Workspace, the DKIM public key is generated in the Google Admin Console. Navigate to Apps > Google Workspace > Gmail > Authenticate email, select your domain, and click Generate new record. Choose a 2048-bit key. Google will display a TXT record with a selector (typically google) and a long public key string. Copy both values exactly.
In Cloudflare DNS, add a TXT record. The Name field takes the full selector path: google._domainkey (Cloudflare will append your domain automatically). The Content field takes the full v=DKIM1; k=rsa; p=... string provided by Google.
For Microsoft 365, navigate to the Microsoft 365 Defender portal, then Email and collaboration > Policies and rules > Threat policies > Email authentication settings > DKIM. Select your domain and enable DKIM signing. Microsoft provides two CNAME records rather than a TXT record directly.
DKIM for third-party email platforms like SendGrid and Brevo
Platforms like SendGrid, Brevo, and Mailchimp typically provide DKIM authentication through CNAME records rather than TXT records. Instead of publishing the public key directly, you create CNAMEs that point to records hosted on the platform's own DNS infrastructure. This lets the platform rotate keys on their end without requiring you to update your DNS every time.
The setup process is consistent across platforms: authenticate your sending domain in the platform's dashboard, copy the CNAME records they provide, and add them in Cloudflare DNS.
DKIM CNAMEs must be DNS-only in Cloudflare
CNAME records used for DKIM must have the Cloudflare proxy disabled (gray cloud, DNS only). Proxying these records breaks the DNS lookup that receiving servers perform to retrieve the DKIM public key. This is a common setup mistake and it produces DKIM failures that can be difficult to trace back to the cause.
Key rotation is worth planning for. Most platforms allow you to generate a new key and run both the old and new keys simultaneously for a transition period. Rotating annually is a reasonable practice, and moving from 1024-bit to 2048-bit during a rotation is the right time to make that upgrade if it hasn't happened already.
DMARC: The Policy Layer That Ties SPF and DKIM Together
Understanding DMARC alignment. Strict vs relaxed
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is the policy record that tells receiving servers what to do when SPF or DKIM checks fail. But DMARC doesn't just check whether SPF and DKIM pass in isolation. It checks alignment: whether the domain in the From: header matches the domain authenticated by SPF or DKIM.
This distinction matters. A message can technically pass SPF while being sent from a completely different domain than the one in the From: header. DMARC closes that gap.
Alignment comes in two modes. Relaxed alignment allows a subdomain match. If your From: header shows yourdomain.com and the SPF check passes for mail.yourdomain.com, that's a relaxed alignment pass. Strict alignment requires an exact match. The default for both SPF and DKIM alignment in DMARC is relaxed, which is the right starting point for most configurations.
"DMARC doesn't replace SPF and DKIM. It coordinates them and gives you a policy for what happens when they disagree."
Building your first DMARC record: a starter policy
DMARC is a TXT record added at _dmarc.yourdomain.com. In Cloudflare DNS, add a TXT record with the Name set to _dmarc and the Content containing your DMARC policy string.
A safe starter record looks like this:
1v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:dma
2
3## Preventing Email Spoofing on Domains That Never Send Email
4
5Attackers don't just target active senders. They go after the quiet domains. The parked domain you registered three years ago and never touched. The subdomain you use only for a marketing landing page. The internal-facing hostname that serves a dashboard and nothing else. These targets are attractive precisely because there's nothing to fail against. No SPF record means any server can claim to send from that domain. No DMARC means there's no policy telling receivers what to do when something looks wrong. The absence of records is an open door.
6
7### Locking Down Parked Domains and Subdomains
8
9The fix is straightforward, and it takes about five minutes per domain in Cloudflare DNS. You need three records, and they work together to close every angle.
10
11First, the SPF record. Add a **TXT record** at the root of the domain (or at the subdomain you're locking down) with the value `v=spf1 -all`. That's it. No mechanisms, no includes, no IP ranges. The `-all` means hard fail: any server that claims to send from this domain should be rejected outright.
12
13Second, the DMARC record. Add a **TXT record** at `_dmarc.yourdomain.com` with this value: `v=DMARC1; p=reject; adkim=s; aspf=s`. The `p=reject` policy tells receivers to drop messages that fail. The `adkim=s` and `aspf=s` flags set strict alignment, meaning the domains in the headers must match exactly, not just share a parent domain.
14
15DKIM doesn't apply here. There's no signing key because there's no mail server. You can add a wildcard DKIM record pointing to nothing if you want to be thorough, but it isn't required.
16
17<div class="pullquote">The absence of email records isn't neutral. It's an invitation.</div>
18
19<div class="stat-callout"><div class="stat-number" data-count-target="36%">36%</div><div class="stat-label">of phishing emails in recent analyses impersonate domains with no published SPF record</div></div>
20
21### The Null MX Record Trick
22
23The third record is the one most people skip: the **null MX record**. Add an MX record at the domain root with priority `0` and a target value of `.` (a single dot). This explicitly tells receiving mail servers that this domain accepts no mail. Without it, some servers will attempt delivery anyway, and certain spam tools will use the absence of an MX record as cover.
24
25In Cloudflare, the record looks like this:
26
27| Type | Name | Priority | Content | Proxy |
28|------|------|----------|---------|-------|
29| MX | @ | 0 | . | DNS only |
30| TXT | @ | — | v=spf1 -all | DNS only |
31| TXT | _dmarc | — | v=DMARC1; p=reject; adkim=s; aspf=s | DNS only |
32
33This applies to any subdomain that serves only web traffic. If `app.yourdomain.com` runs a SaaS dashboard and never touches email, lock it down the same way. Attackers don't care that it's a subdomain.
34
35---
36
37## Domain Reputation and Deliverability Hygiene Beyond DNS
38
39DNS records are the foundation. They're not the whole building. You can publish a perfect SPF record, sign every message with DKIM, and enforce a `p=reject` DMARC policy, and still land in spam. Receivers don't make decisions based on DNS alone. They watch what you actually do.
40
41### Warming Up a New Sending Domain
42
43When you start sending from a domain that has no history, receivers don't know you yet. Their filters default to skepticism. **IP and domain warm-up** is the process of building that history deliberately, starting with low volumes and ramping up over several weeks.
44
45The general shape of a warm-up looks like this: start with your most engaged contacts, the people most likely to open and reply. Send a few hundred messages in the first week. Double that in week two. Keep ramping. The goal is to accumulate positive signals, opens, clicks, replies, before you start hitting the full list. Sending 50,000 messages on day one from a brand-new domain is a reliable way to get blocklisted before anyone reads a word.
46
47<div class="stat-callout"><div class="stat-number" data-count-target="21 days">21 days</div><div class="stat-label">typical minimum warm-up period recommended before full-volume sending on a new domain</div></div>
48
49### Monitoring Your Sender Reputation with Free Tools
50
51**Google Postmaster Tools** is the most useful free tool available for monitoring how Gmail treats your domain. After verifying ownership (the same TXT record process you'd use for any Google service), you get access to dashboards showing your domain reputation, IP reputation, spam rate, and delivery errors. If Gmail is flagging your messages, Postmaster Tools will tell you before your open rates collapse.
52
53**Microsoft SNDS** (Smart Network Data Services) covers the Outlook and Hotmail side of the equation. It shows complaint rates and trap hits for your sending IPs, which matters if a significant portion of your list uses Microsoft-hosted email.
54
55<div class="bg-indigo-50 dark:bg-indigo-500/10 rounded-xl p-6 my-8 border border-indigo-200 dark:border-indigo-500/30"><p class="font-semibold text-navy-900 dark:text-white mb-2">Key Hygiene Practices That Actually Move the Needle</p><div class="text-sm text-gray-600 dark:text-gray-400"><p>Clean your list before you send. Bounce rates above 2% are a red flag to filters. Spam complaint rates above 0.1% will trigger suppression at Gmail. Include a working, one-click unsubscribe link in every commercial message. Remove complainers immediately. Avoid purchasing lists. Spam traps, addresses that exist only to catch senders who don't maintain clean lists, will damage your reputation in ways that take months to recover from.</p>
56</div></div>
57
58For pre-send testing, **MXToolbox Email Health Check** gives you a comprehensive view of your DNS configuration. **Mail Tester** lets you send a test message and get a scored report on everything from headers to content. **GlockApps** goes further, showing inbox placement across major providers before you hit send on a real campaign. Use all three when setting up a new sending configuration.
59
60---
61
62## Full Worked Examples: Google Workspace, Microsoft 365, and SendGrid
63
64Theory is useful. Tables you can copy are more useful. Here are complete DNS configurations for the three most common setups, formatted for entry into Cloudflare's DNS interface.
65
66### Complete DNS Setup for Google Workspace
67
68Google Workspace MX records use weighted priority values to distribute inbound mail across Google's servers. The DKIM record comes from your Google Admin console under Apps > Google Workspace > Gmail > Authenticate email. The selector is typically `google`.
69
70| Type | Name | Priority | Content | Proxy |
71|------|------|----------|---------|-------|
72| MX | @ | 1 | aspmx.l.google.com | DNS only |
73| MX | @ | 5 | alt1.aspmx.l.google.com | DNS only |
74| MX | @ | 5 | alt2.aspmx.l.google.com | DNS only |
75| MX | @ | 10 | alt3.aspmx.l.google.com | DNS only |
76| MX | @ | 10 | alt4.aspmx.l.google.com | DNS only |
77| TXT | @ | — | v=spf1 include:_spf.google.com ~all | DNS only |
78| TXT | google._domainkey | — | v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY | DNS only |
79| TXT | _dmarc | — | v=DMARC1; p=none; rua=mailto:[email protected] | DNS only |
80
81Replace `YOUR_PUBLIC_KEY` with the value generated in your Google Admin console. It's long. That's normal.
82
83### Complete DNS Setup for Microsoft 365
84
85Microsoft 365 uses a single MX record that routes to a tenant-specific hostname. Your exact MX target will look something like `yourdomain-com.mail.protection.outlook.com`. Find it in the Microsoft 365 Admin Center under Settings > Domains.
86
87| Type | Name | Priority | Content | Proxy |
88|------|------|----------|---------|-------|
89| MX | @ | 0 | yourdomain-com.mail.protection.outlook.com | DNS only |
90| TXT | @ | — | v=spf1 include:spf.protection.outlook.com ~all | DNS only |
91| CNAME | selector1._domainkey | — | selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com | DNS only |
92| CNAME | selector2._domainkey | — | selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com | DNS only |
93| TXT | _dmarc | — | v=DMARC1; p=none; rua=mailto:[email protected] | DNS only |
94
95Microsoft uses **CNAME-based DKIM rotation** with two selectors. Both need to be present.
96
97### Adding a Third-Party Sender Like SendGrid or Brevo Alongside Your Primary Provider
98
99This is where most people make their first SPF mistake. You cannot have two SPF TXT records. You merge them into one.
100
101If you're using Google Workspace and SendGrid together, the merged SPF record looks like this:
102v=spf1 include:_spf.google.com include:sendgrid.net ~all
1
2One record. Both includes. One `-all` or `~all` at the end.
3
4SendGrid also provides **CNAME-based DKIM records** for domain authentication. They look like this in Cloudflare:
5
6| Type | Name | Content | Proxy |
7|------|------|---------|-------|
8| CNAME | s1._domainkey | s1.domainkey.u12345.wl.sendgrid.net | DNS only |
9| CNAME | s2._domainkey | s2.domainkey.u12345.wl.sendgrid.net | DNS only |
10
11Your actual CNAME values come from your SendGrid account under Settings > Sender Authentication. The `u12345` portion is your account-specific identifier.
12
13<div class="bg-teal-50 dark:bg-teal-500/10 rounded-xl p-6 my-8 border border-teal-200 dark:border-teal-500/30"><p class="font-semibold text-navy-900 dark:text-white mb-2">DMARC Covers All Senders, Not Just One</p><div class="text-sm text-gray-600 dark:text-gray-400"><p>You only set DMARC once, at the domain level. It applies to every sender claiming to use your domain, whether that's Google Workspace, SendGrid, or anything else. What matters is that each sender's messages pass either SPF alignment or DKIM alignment against your domain. If SendGrid signs with your domain via DKIM and Google passes SPF, both satisfy DMARC. The policy doesn't care which service sent the message.</p>
14</div></div>
15
16After adding any of these records, verify them. Run `dig TXT yourdomain.com` and `dig MX yourdomain.com` from a terminal, or use MXToolbox's Email Health Check tool. DNS propagation through Cloudflare is fast, usually under a minute, but downstream resolvers cache based on TTL. If a record doesn't appear immediately from an external checker, wait for the TTL to expire before assuming something is wrong.
17
18---
19
20## Troubleshooting Common Email DNS Mistakes in Cloudflare
21
22Most email DNS problems fall into a small number of categories. The symptoms vary. The root causes don't.
23
24### Orange Cloud vs Gray Cloud Errors for Email Records
25
26This is the most common mistake, and it's easy to make because Cloudflare's interface defaults to proxying new records. **MX records must never be proxied.** Neither should DKIM CNAME records. Neither should any record that email infrastructure needs to resolve directly.
27
28When you proxy an MX record through Cloudflare, the receiving mail server connects to Cloudflare's edge instead of your mail provider's servers. The connection fails, or behaves unpredictably, and your inbound mail stops working. The fix is simple: click the orange cloud icon next to the record and switch it to gray (DNS only). Do this for every MX record, every DKIM TXT or CNAME record, and every SPF TXT record.
29
30<div class="pullquote">The orange cloud is one of the best features Cloudflare offers. It's also the fastest way to break your email if you apply it to the wrong records.</div>
31
32### Duplicate and Conflicting SPF Records
33
34SPF allows exactly one TXT record per domain. If you add a second one, because a new email platform told you to add their SPF include without mentioning you need to merge it, you now have a conflict. Receivers will see multiple SPF records and treat the result as a **permerror**, which typically means SPF fails entirely.
35
36> "Multiple SPF records on a single domain is undefined behavior per RFC 7208. Receivers are not required to handle it gracefully, and most don't."
37
38Check for duplicates with `dig TXT yourdomain.com | grep spf`. If you see two lines starting with `v=spf1`, merge them into one record and delete the other.
39
40### DMARC Failures Despite Valid SPF and DKIM
41
42SPF passing and DKIM passing don't automatically mean DMARC passes. DMARC requires **alignment**, meaning the domain in the `From:` header must match the domain that passed SPF or DKIM.
43
44The common failure scenario: a third-party platform sends on your behalf, the envelope sender (the actual SMTP `MAIL FROM`) uses the platform's own domain, SPF passes for the platform's domain, but DMARC checks alignment against your domain in the `From:` header. It doesn't match. DMARC fails.
45
46The fix is to use **DKIM alignment** instead. When you authenticate your domain with SendGrid or Brevo using their CNAME method, they sign outgoing messages with your domain as the DKIM `d=` value. That creates alignment. SPF alignment from a third-party platform is unreliable. DKIM alignment from a properly configured sender is not.
47
48DKIM can also fail temporarily after you add a new record, because DNS propagation takes time and some resolvers cache aggressively. Wait the full TTL period before concluding something is broken. For most Cloudflare-managed records, that's 300 seconds. For records you migrated from another registrar, it could be much longer.
49
50---
51
52## Your Email DNS Setup Checklist
53
54<div class="tasklist" data-tasklist-slug="email-dns-setup-checklist">
55 <div class="tasklist-header">
56 <span class="tasklist-title"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" style="width:1.1rem;height:1.1rem"><path d="M9 11l3 3L22 4"/><path d="M21 12v7a2 2 0 01-2 2H5a2 2 0 01-2-2V5a2 2 0 012-2h11"/></svg> Email DNS Setup Checklist</span>
57 <span class="tasklist-progress">0/10</span>
58 </div>
59 <ul class="tasklist-items"><li class="tasklist-item" data-index="0">
60 <input type="checkbox" id="task-email-dns-setup-checklist-0" aria-label="Add MX records for your email provider with the proxy set to DNS only (gray cloud)">
61 <label for="task-email-dns-setup-checklist-0">Add MX records for your email provider with the proxy set to DNS only (gray cloud)</label>
62 </li>
63<li class="tasklist-item" data-index="1">
64 <input type="checkbox" id="task-email-dns-setup-checklist-1" aria-label="Create a single merged SPF TXT record that covers every service sending on your behalf">
65 <label for="task-email-dns-setup-checklist-1">Create a single merged SPF TXT record that covers every service sending on your behalf</label>
66 </li>
67<li class="tasklist-item" data-index="2">
68 <input type="checkbox" id="task-email-dns-setup-checklist-2" aria-label="Add DKIM TXT or CNAME records for each sending platform (Google, Microsoft, SendGrid, etc.)">
69 <label for="task-email-dns-setup-checklist-2">Add DKIM TXT or CNAME records for each sending platform (Google, Microsoft, SendGrid, etc.)</label>
70 </li>
71<li class="tasklist-item" data-index="3">
72 <input type="checkbox" id="task-email-dns-setup-checklist-3" aria-label="Add a DMARC TXT record at _dmarc.yourdomain.com starting with p=none and an rua reporting address">
73 <label for="task-email-dns-setup-checklist-3">Add a DMARC TXT record at _dmarc.yourdomain.com starting with p=none and an rua reporting address</label>
74 </li>
75<li class="tasklist-item" data-index="4">
76 <input type="checkbox" id="task-email-dns-setup-checklist-4" aria-label="Lock down all non-sending domains and subdomains with a null MX record, v=spf1 -all, and a p=reject DMARC policy">
77 <label for="task-email-dns-setup-checklist-4">Lock down all non-sending domains and subdomains with a null MX record, v=spf1 -all, and a p=reject DMARC policy</label>
78 </li>
79<li class="tasklist-item" data-index="5">
80 <input type="checkbox" id="task-email-dns-setup-checklist-5" aria-label="Verify all records using MXToolbox Email Health Check or dig after adding them in Cloudflare">
81 <label for="task-email-dns-setup-checklist-5">Verify all records using MXToolbox Email Health Check or dig after adding them in Cloudflare</label>
82 </li>
83<li class="tasklist-item" data-index="6">
84 <input type="checkbox" id="task-email-dns-setup-checklist-6" aria-label="Set up Google Postmaster Tools and complete domain verification for your primary sending domain">
85 <label for="task-email-dns-setup-checklist-6">Set up Google Postmaster Tools and complete domain verification for your primary sending domain</label>
86 </li>
87<li class="tasklist-item" data-index="7">
88 <input type="checkbox" id="task-email-dns-setup-checklist-7" aria-label="Plan a DMARC escalation path from p=none to p=quarantine to p=reject over 4 to 8 weeks">
89 <label for="task-email-dns-setup-checklist-7">Plan a DMARC escalation path from p=none to p=quarantine to p=reject over 4 to 8 weeks</label>
90 </li>
91<li class="tasklist-item" data-index="8">
92 <input type="checkbox" id="task-email-dns-setup-checklist-8" aria-label="Review DMARC aggregate reports weekly during the rollout period and investigate any unexpected sources">
93 <label for="task-email-dns-setup-checklist-8">Review DMARC aggregate reports weekly during the rollout period and investigate any unexpected sources</label>
94 </li>
95<li class="tasklist-item" data-index="9">
96 <input type="checkbox" id="task-email-dns-setup-checklist-9" aria-label="Confirm that no MX records, DKIM records, or SPF records have the Cloudflare orange cloud proxy enabled">
97 <label for="task-email-dns-setup-checklist-9">Confirm that no MX records, DKIM records, or SPF records have the Cloudflare orange cloud proxy enabled</label>
98 </li></ul>
99 <div class="tasklist-footer">
100 <button class="tasklist-btn tasklist-share-btn" aria-label="Share task list"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2"><path d="M4 12v8a2 2 0 002 2h12a2 2 0 002-2v-8"/><polyline points="16 6 12 2 8 6"/><line x1="12" y1="2" x2="12" y2="15"/></svg> Share</button>
101 <button class="tasklist-btn tasklist-copy-btn" aria-label="Copy task list"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2"><rect x="9" y="9" width="13" height="13" rx="2" ry="2"/><path d="M5 15H4a2 2 0 01-2-2V4a2 2 0 012-2h9a2 2 0 012 2v1"/></svg> Copy List</button>
102 </div>
103 </div>
104
105---
106
107## What's Next: Building on a Solid Email Foundation
108
109Part 7 established how Cloudflare handles DNS at the infrastructure level. Part 8 took that foundation and applied it to one of the most consequential DNS use cases you'll encounter: email authentication. MX records, SPF, DKIM, DMARC, subdomain isolation, spoofing prevention for non-sending domains, and the deliverability hygiene that keeps your messages out of spam folders. That's a complete picture of email DNS, not just the records but the reasoning behind them.
110
111The good news is that this is largely a one-time setup. You configure it, verify it, monitor the DMARC reports for a few weeks, and then escalate to enforcement. It doesn't demand constant attention after that.
112
113<div class="reminder-btn-wrap"><button class="reminder-btn" data-reminder-date="2026-06-07" data-reminder-label="Run an MXToolbox Email Health Check on your domain before moving to Part 9. DMARC reports will surface senders you forgot about." onclick="downloadReminder(this)"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2"><rect x="3" y="4" width="18" height="18" rx="2" ry="2"/><line x1="16" y1="2" x2="16" y2="6"/><line x1="8" y1="2" x2="8" y2="6"/><line x1="3" y1="10" x2="21" y2="10"/></svg> Run an MXToolbox Email Health Check on your domain before moving to Part 9. DMARC reports will surface senders you forgot about.</button><div class="reminder-cal-links"><a href="#" class="reminder-cal-link" data-reminder-date="2026-06-07" data-reminder-label="Run an MXToolbox Email Health Check on your domain before moving to Part 9. DMARC reports will surface senders you forgot about." onclick="openGoogleCalendar(this);return false"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" style="width:1em;height:1em;vertical-align:middle"><rect x="3" y="4" width="18" height="18" rx="2" ry="2"/><line x1="16" y1="2" x2="16" y2="6"/><line x1="8" y1="2" x2="8" y2="6"/><line x1="3" y1="10" x2="21" y2="10"/></svg> Google Calendar</a><a href="#" class="reminder-cal-link" data-reminder-date="2026-06-07" data-reminder-label="Run an MXToolbox Email Health Check on your domain before moving to Part 9. DMARC reports will surface senders you forgot about." onclick="openOutlookCalendar(this);return false"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" style="width:1em;height:1em;vertical-align:middle"><rect x="3" y="4" width="18" height="18" rx="2" ry="2"/><line x1="16" y1="2" x2="16" y2="6"/><line x1="8" y1="2" x2="8" y2="6"/><line x1="3" y1="10" x2="21" y2="10"/></svg> Outlook</a></div></div>
114
115Before you move on, run that health check. You'll likely find at least one thing that needs adjusting, and it's better to catch it now than after you've built more on top of it. Part 9 moves into Cloudflare's nameserver management and zone configuration, where the DNS skills you've built here start intersecting with multi-domain architecture and delegation strategies.
