Set up Google Workspace email authentication on Cloudflare

Three TXT records, all on the DNS Records page of your Cloudflare dashboard. Google generates the values, you paste them into Cloudflare. SPF is a fixed line you can copy from this page. DKIM is a key you generate in the Google Admin console first, paste into Cloudflare second, and switch on back in Google third — in that order. DMARC is a line you write yourself. Checked against the official documentation on 5 September 2026.

Good news for Cloudflare users specifically: the two traps that make this setup painful elsewhere barely exist here. The orange cloud can't touch a TXT record, so SPF, DKIM and DMARC are immune to the classic Cloudflare mistake. And the 2048-bit DKIM key that other providers choke on is split into DNS-legal pieces by Cloudflare automatically. What's left is the Name field, one Cloudflare product that writes its own SPF record, and the order of clicks in Google.

These records let receiving mail servers check that a message claiming to be from you really is from you. They do not guarantee your email reaches the inbox — your content and sending reputation matter at least as much — but without them, anyone can send email in your name.

What we don't do: we never touch your DNS zone. We read, we prescribe, you paste. You're the one who saves it, in your own account, with your own credentials.

Before anything else: is Cloudflare actually your DNS?

Cloudflare only answers for your domain if your nameservers point to Cloudflare. You can have a Cloudflare account with a perfectly filled-in zone that nobody on the internet ever consults, because the domain still delegates to your registrar. Symptom: you add the records, Google never sees them, and you redo them three times thinking you mistyped.

Check where your domain delegates first. If it isn't Cloudflare, the values below don't change — only the panel does.

The records to copy and paste

1. SPF — who is allowed to send as you

What you must replace: nothing, if Google Workspace is your only sender. This is Google's published value, and Google is explicit about the ending: "The ~all tag tells receiving servers to mark messages as spam if they're from servers that aren't listed in the SPF record. Google recommends you use ~all in your SPF record."

If other services send on your behalf, they all go in one single line:

v=spf1 include:_spf.google.com include:spf.example-crm.com ~all

⚠️ One SPF record per domain. Always. Two v=spf1 lines don't mean double protection, they mean no SPF at all. Google says it from its side — "Each domain must have its own SPF record" — and if a line already exists in your zone, you edit it (Cloudflare: Edit on the record → change Content → Save). You never add a second one.

A correction to Google's own wording. Google's SPF page says "An SPF record can have up to 10 include: tags." The limit in the SPF standard is 10 DNS lookups, not ten include: statements — and one include: can cost several lookups. Past ten, SPF fails entirely (permerror), even though the line looks fine. Cloudflare states the real rule: "SPF records are limited to 10 DNS lookups total."

2. DKIM — the signature on your messages

Cloudflare doesn't generate your DKIM key. Google does. It's a single TXT record — never a CNAME — and the value is unique to your domain.

Step 1, in the Google Admin console. Menu → Apps → Google Workspace → Gmail → Authenticate email. Pick your domain in the Selected domain menu, then click Generate New Record. Keep the defaults: 2048-bit key, prefix google — "The default prefix selector is google. If you are using Google Workspace, this is the recommended option." Click Generate. Google shows two values: DNS Host name (TXT record name) and TXT record value.

Then — and this is the instruction people skip — Google says: "Important: Do not click Start Authentication yet. You'll do that later."

Step 2, in Cloudflare:

What you must replace: the whole Content, always — paste exactly the TXT record value Google displayed. And check the Name against Google's DNS Host name: if you already had a key with the google prefix, Google asks you to pick another one, and the Name becomes yourprefix._domainkey. Either way, type the part before your domain only — Cloudflare completes it.

Step 3, back in the Admin console: return to Authenticate email, select your domain, and click Start authentication. When it's working, "the status at the top of the page changes to: Authenticating email with DKIM."

Why the 2048-bit key is a non-issue on Cloudflare. Google's troubleshooting page warns: "If you're using a 2048-bit DKIM key, you can't enter it as a single text string in a DNS record with a 255-character limit. Instead… Split the key characters into multiple text strings. Put each string inside quotes." That's the DNS protocol talking, not Google being difficult. Cloudflare does the splitting for you: "When the value you enter exceeds 255 characters, it must be split into multiple strings. Each string is enclosed in double quotes… This splitting is required by the DNS protocol and is performed by all DNS providers, even if some do not display it in their UI." Cloudflare also says: "if you save your TXT content without any quotes, Cloudflare will automatically add double quotes."

So: paste Google's value as one string, without quotes, and save. If you later see "…" "…" with a quote in the middle of the record, that's the expected result — don't "fix" it. What does trigger a validation error is inconsistent quoting ("this or "these" ones"), which happens when you paste a value someone else already hand-split. Google's 1024-bit option exists "If your domain host doesn't support 2048-bit keys" — Cloudflare does, so you don't need it.

Two Google timings that aren't failures. On a brand-new account: "after you turn on Gmail for your organization, you must wait 24–72 hours before you can get your DKIM key in the Admin console." And after publishing: "the Authenticate email page in your Google Admin console might continue to display this message for up to 48 hours: You must update the DNS records for this domain. If you've correctly added your DKIM key at your domain provider, you can ignore this message."

3. DMARC — the instruction you give to inboxes

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read. That's where your reports land, and a DMARC record without a rua= is a report you'll never see.

Why p=none first. It means "watch and tell me". Nobody gets blocked, nothing changes for your recipients, and you start receiving a list of everything sending in your name — including the tools you'd forgotten about. You watch for two to four weeks, confirm every legitimate sender is recognised, and only then tighten one notch to p=quarantine, then p=reject. Google agrees on the starting point: "we recommend setting the policy option (p) to none. As you learn how messages from your domain are authenticated by receiving servers, update your policy."

If you send more than 5,000 messages a day to Gmail addresses, this isn't optional. Since 1 February 2024 Google requires bulk senders to "Set up SPF and DKIM email authentication for your domain" — both, not one — and to "Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none." Below that volume, "SPF or DKIM" is the minimum; publishing all three is still the right reflex.

⚠️ Don't copy Google's own DMARC examples. Its setup page illustrates the record with v=DMARC1; p=none; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s, and its rollout guide — last updated 26 August 2026 — gives v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com as the middle step. pct= was removed from the DMARC standard by RFC 9989, published in May 2026. Servers following the current standard ignore it, so pct=5 doesn't give you a cautious 5 % rollout — it gives you your full policy on everyone while you believe you're easing in. And adkim=s; aspf=s (strict alignment) is the setting you tighten last, if ever, not the one you start with. Ramp with the policy itself: none, then quarantine, then reject.

One piece of Google advice worth keeping: "Set up DKIM and SPF at least 48 hours before setting up DMARC." Publishing DMARC before the other two actually authenticate is how people frighten themselves with their first report.

⚠️ One DMARC record per domain too. If you already have a _dmarc record — Cloudflare's DMARC Management may have created one for you, see below — you edit it.

The click path

In Google — generate the DKIM key

1. Sign in to the Google Admin console as a super administrator — Google: "You must be signed in as a super administrator for this task."
2. Menu → Apps → Google Workspace → Gmail → Authenticate email.
3. In Selected domain, pick your domain. Click Generate New Record, keep 2048 and the google prefix, click Generate.
4. Leave this tab open. Copy the TXT record value; don't click Start authentication yet.

In Cloudflare — create the three records

1. Sign in to the Cloudflare dashboard, select your account, then your domain.
2. Go to the DNS Records page.
3. Look at the table first. Is there already a TXT on @ starting with v=spf1? A _dmarc record? If so, you'll Edit, not add.
4. Select Add record, choose Type TXT.
5. Fill in Name (@, google._domainkey or _dmarc) and Content. Leave TTL on Auto.
6. Select Save. Repeat for the other records.

The Name field wants the relative name. Cloudflare: "To create a zone apex record, use @ for the record Name." Google, meanwhile, describes the DMARC host as "_dmarc.example.com (replace example.com with your domain name)" — right in Google's world, wrong inside Cloudflare's form. Type _dmarc and nothing else. Leading underscores are fine: "Underscores are valid in DNS and commonly used for service records."

No proxy decision to make. Cloudflare: "Only records used for IP address resolution — A, AAAA, and CNAME records — can be proxied. Other record types (such as MX or TXT) are always DNS-only." All three Google records are TXT, and Google's MX targets are Google's own hostnames, so the orange cloud simply has nothing to grab here.

Cloudflare's wizard — and what it can't do for you

Cloudflare's docs recommend its own Email security Wizard over hand-typed TXT records: "You could also use TXT to create email authentication records, but we recommend that you use our Email security Wizard instead." It lives at Email → DMARC Management → Email record overview → View records, where you "use the available options to set up SPF, DKIM, and DMARC records", and the page "will also list any previous records you might already have."

It's a fine way to publish the SPF and DMARC lines, and it will show you an SPF or DMARC record you'd forgotten about. What it cannot do is generate your DKIM key — that only exists in the Google Admin console. Whichever route you take, DKIM is a Google value pasted into a Cloudflare TXT record.

If you also enable DMARC Management itself (Email → DMARC Management → Enable DMARC Management), know that when "a DMARC record is found in your zone, Cloudflare will add another rua… entry to it", pointing at a Cloudflare address so it can receive a copy of your reports; if none is found, "Cloudflare will automatically invite you to add one". It only works on the apex domain, and allow "up to 24 hours to receive your first DMARC report". It's free on all plans. It shows you whether messages passed or failed; it won't tell you in plain language what to change, or walk you to p=reject without cutting off a sender you'd forgotten. That's where we come in.

Back in Google — switch DKIM on

Return to Authenticate email, select your domain, click Start authentication. To confirm afterwards, heed Google's caveat: "Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.)"

The 3 mistakes we see most often here

1. Pasting Google's _dmarc.example.com into Cloudflare's Name field

Google writes the host as a full name; Cloudflare's Name field wants the part before your domain and adds the rest. Follow Google literally and you publish a record at _dmarc.example.com.example.com — an address nothing will ever query. Same failure for google._domainkey.example.com.

How you spot it: your domain name appears twice in the Name column of the DNS Records table, and an outside lookup of _dmarc.yourdomain.com returns nothing.

The fix: Edit the record and shorten the Name to the prefix: _dmarc, google._domainkey, @.

⚠️ Don't confuse this with its mirror image. At some other hosts (OVH, Gandi), the symmetrical trap sits on a CNAME target, where the fix is to add a trailing dot. Cloudflare's Content field takes values as-is. Same look, opposite fixes.

2. Two SPF records, because Cloudflare wrote one for you

The Google Workspace combination has a specific version of the classic mistake. Cloudflare's Email Routing (under Compute → Email Service → Email Routing) publishes an SPF TXT on your root domain — v=spf1 include:_spf.mx.cloudflare.net ~all — the moment you enable it. Add Google's line next to it and you have two v=spf1 records, which means no SPF at all, for Google included. Cloudflare's own fix, in its own words: "If you have existing SPF records, merge them: v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all."

The records Email Routing publishes are also locked — you can't edit them from the DNS Records page until you unlock them (Email Routing → Settings → DNS records → Unlock). And since Email Routing also publishes its own MX records, ask yourself why it's on at all: it forwards mail for a domain without mailboxes, and Google Workspace is your mailboxes. Cloudflare's troubleshooting page says it plainly: "If Email Routing is turned on but you use a different mail provider, the Email Routing MX records may conflict with your provider's records."

How you spot it: a scan reports "multiple SPF records", or SPF shows permerror while each line looks correct; or your MX records point at route1.mx.cloudflare.net instead of Google.

The fix: one SPF line containing both includes if you really need both; otherwise turn Email Routing off and keep Google's line alone.

3. Clicking "Start authentication" too early — or never

Google's DKIM flow has an order — generate, publish, then authenticate — and people either rush it or over-respect it. Rush it and Google says the DNS record is missing; many then regenerate the key, which invalidates the one they'd just pasted. Over-respect it and DKIM never turns on, because nobody went back for step 3.

Google imposes no waiting period between saving the record in Cloudflare and clicking. And on Cloudflare the propagation excuse is thin: changes "take effect globally within 5 minutes, usually much less."

How you spot it: the console still shows You must update the DNS records for this domain and you've regenerated the key "to see"; or the status never reaches Authenticating email with DKIM.

The fix: stop regenerating. Confirm the Content in Cloudflare matches the last key Google displayed, wait a few minutes, click Start authentication once.

How long before it takes effect

• In Cloudflare: saved immediately. Cloudflare's DNS FAQ: changes "take effect globally within 5 minutes, usually much less"; its Email Service docs are more cautious — "can take up to 24 hours to propagate globally, but usually complete within 5-15 minutes". Either way, fast.
• The old value can stay cached for as long as the TTL you had set before the change — five minutes on Cloudflare's Auto, up to a day if you had set one.
• For SPF and DKIM to start authenticating: Google says up to 48 hours for each. Its Admin console may keep showing a DNS warning for that long even when everything is right.
• For MX changes, if you're also moving mail: Google says up to 72 hours.
• For DMARC reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day.

On MX, while you're here. Google now recommends a single MX record, smtp.google.com at priority 1. Cloudflare's own troubleshooting table still lists the five legacy ASPMX.L.GOOGLE.COM records for Google Workspace — not wrong, just older: Google says "the legacy MX record values are still supported" and "If your email is working, no changes are required." Don't migrate for the sake of it, but do "Remove any other MX records."

Further reading

• How to set up SPF, DKIM and DMARC on Cloudflare
• Set up Google Workspace email authentication on GoDaddy
• How to move your DMARC policy to p=reject safely
• My emails go to spam even though SPF, DKIM and DMARC pass