Google Workspace · Cloudflare · Complete setup

Set up SPF, DKIM and DMARC for Google Workspace — with your DNS on Cloudflare

First published 20 October 2026 · Every record value below comes from Google's current Workspace documentation, checked again on publication day of this guide. Where another official page disagrees with Google, this guide says so — see the MX warning.

The fast answer — the records, in order

  • MX (probably already right): one record, smtp.google.com, priority 1. Verify, do not duplicate.
  • SPF — TXT at the root (@): v=spf1 include:_spf.google.com ~all
  • DKIM — in Google Admin: Apps → Google Workspace → Gmail → Authenticate email → Generate New Record (2048-bit, selector google) → paste Google's TXT at google._domainkey in Cloudflare → back in Admin, click Start authentication.
  • DMARC — TXT at _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain — added after SPF/DKIM have run 48 hours.
Read this before the MX step: Cloudflare's own Google Workspace guide (still online, updated September 2026) tells you Google “requires five MX records” — the retired aspmx.l.google.com set. Google's current page says one record. Follow Google; a mixed set of old and new MX records is a self-inflicted wound.
MX Cloudflare DNS · verify only SPF Cloudflare DNS · paste exact DKIM Google generates · you paste + start DMARC Cloudflare DNS · after 48 hours Order matters: SPF and DKIM must already work before DMARC can judge them.
Four records, two consoles, one order. DKIM is the only one with a step inside Google — and the only one with a step everyone forgets.

Step 1 — MX: verify, don't rebuild

  1. In Cloudflare: your domain → DNS → Records. Look at the MX rows.
  2. Google's current requirement is one MX record: name blank/@, value smtp.google.com, priority 1. If exactly that is present and your mail works, change nothing.
  3. If the retired five-record set is there from an old setup and mail works, it still functions today — but if you are setting up fresh or repairing, build Google's current single record and remove others, per Google's own instruction. Allow up to 72 hours for receivers to recognise MX changes.
Prove it: Google's free Admin Toolbox — Check MX run on your domain should report your MX healthy. That same tool reappears at the end of this guide as your final exam.

Cloudflare → DNS → Records — the MX row you should see
Type1MX
Name2@ (root)
Mail server3smtp.google.com
Priority41 — a single record is Google's current instruction
Verify only
Do this: if exactly this row is present and mail works, touch nothing. Do not "restore" the retired five-record aspmx set some pages (including one of Cloudflare's) still show. Field map drawn by Merroway.
Step 2 — SPF: one record, exact value

TXT · Name: @ · Value
v=spf1 include:_spf.google.com ~all
  1. Cloudflare → DNS → Records → Add record: Type TXT, Name @ (Cloudflare's shorthand for your root domain), paste the value exactly, TTL Auto.
  2. If a TXT record starting v=spf1 already exists at @, do not add a second one. Two SPF records invalidate both. Edit the existing record instead, merging per Google's combination table — another sender's include: joins yours inside the single record (and mind the 10-lookup budget).
  3. Nothing happens in the Google Admin console for SPF — it is DNS only. Anyone's guide that sends you console-hunting for SPF is out of date.
Prove it: read the record back at your root with any DNS lookup tool: exactly one v=spf1 TXT, value matching the box above. (Checked live for this guide: Google's include currently costs a single lookup — the old “Google costs 4” warning is retired folklore.)

Cloudflare → DNS → Add record — SPF
Type1TXT
Name2@
Content3v=spf1 include:_spf.google.com ~all
TTLAuto
Save
Do this: one record, pasted exactly. If a v=spf1 record already exists here, edit it and merge this include inside — a second record invalidates both. Field map drawn by Merroway; value is Google's.
Step 3 — DKIM: Google makes the key, you place it, then you START it

  1. In Google Admin: Apps → Google Workspace → Gmail → Authenticate email. Select your domain.
  2. Click Generate New Record. Choose 2048-bit (Google's recommendation) and keep the default selector google. Google displays a TXT record: host google._domainkey and a long value unique to your domain.
  3. In Cloudflare, add it: Type TXT, Name google._domainkey — type exactly that, not the full domain (Cloudflare appends your domain to what you type; a full name typed here doubles into google._domainkey.yourdomain.yourdomain and never resolves).
  4. Paste the value exactly as Google shows it. If it displays in Cloudflare broken into quoted pieces, that is normal: long TXT values are split automatically. Add no quotes or backslashes of your own.
  5. The step everyone misses: back in Google Admin, on the same Authenticate email page, click Start authentication. Google warns in its own words not to click it before the DNS record exists — and the record alone, without this click, signs nothing.

Two patience notes from Google itself: a brand-new domain may need 24–72 hours before it can even generate a key, and after generating, the console can show a “you must update the DNS records” warning for up to 48 hours — if your read-back (below) is correct, that warning is propagation, not an error.

How to tell you are still on Google's default key: until this step is done, Google signs your mail with a key for a Google-owned domain — a header check shows dkim=pass with header.d naming Google's domain (for example gapssmtp.com), not yours. That pass does not align with your From address, so DMARC is riding on SPF alone — and SPF breaks when mail is forwarded, taking DMARC with it. If your "DKIM passes" but the domain beside it isn't yours, you haven't done this step yet.

Prove it: send a message from your Workspace account to someone outside it, open it there, and read Show original: dkim=pass with header.d = your domain. The Admin console's Authenticate email page should also report authentication in progress/active.

Google Admin → Apps → Google Workspace → Gmail → Authenticate email — interface map drawn by Merroway from Google's documented console
Select1Your domain
Click2Generate New Record — 2048-bit key, selector prefix google
Google showsTXT host google._domainkey + a long value unique to your domain → paste it in Cloudflare (next map)
Then, same page3Start authentication — only after the DNS record reads back correctly
Start authentication
Do this: the record alone signs nothing — the Start click is the step everyone forgets, and Google warns not to click it before the record exists in DNS.
Cloudflare → DNS → Add record — the DKIM key Google generated
Type1TXT
Name2google._domainkey — relative name only; typing the full domain doubles it
Content3The exact value from Google Admin — it will display split into quoted chunks; that is normal, add no quotes of your own
TTLAuto
Save
Do this: read the record back after saving and compare it against Google's value character by character before you go back and click Start authentication. Field map drawn by Merroway.
Step 4 — DMARC: the referee goes in last

  1. Preconditions, from Google: SPF and DKIM have been authenticating your mail for at least 48 hours, and a mailbox exists to receive reports (create dmarc@yourdomain or use a free report reader — our rollout guide compares them).
TXT · Name: _dmarc · Value
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain
  1. Type the name as _dmarc only — the doubling trap from Step 3 applies here too (_dmarc.yourdomain.yourdomain is the classic silent failure).
  2. p=none is the correct start: monitor first. One trap on Google's own page: its worked example prints an enforcing p=reject record with strict alignment tags — that is an illustration of a finished state, not the starting record Google's prose recommends. Copy the box above, then climb with the rollout guide when your reports are clean.
  3. Cloudflare users have an optional shortcut for this record: Email → DMARC Management (available on all plans) can create and watch this same single record. Manual or tool — never both, never two records.
Prove it: Check MX on your domain once more — it exercises MX, SPF, DKIM and DMARC together. Then the header test: a message to an outside address should now read spf=pass, dkim=pass (your domain), dmarc=pass. Three passes, all naming your domain, is the finished setup.

Cloudflare → DNS → Add record — DMARC, after 48 hours of SPF + DKIM
Type1TXT
Name2_dmarc — relative name only
Content3v=DMARC1; p=none; rua=mailto:dmarc@yourdomain
TTLAuto
Save
Do this: start at p=none (monitoring) exactly as shown — the stricter record printed as a worked example on Google's page is a finished state, not the starting one. Field map drawn by Merroway.
SAMPLE HEADER
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=yourdomain.com dkim=pass header.d=yourdomain.com dmarc=pass header.from=yourdomain.com
Do this: this is the finished setup in one block — three passes, and every domain named is yours. Run Google's Admin Toolbox — Check MX on top of it as the final exam. Sample values.
Cloudflare-specific traps, collected

TrapWhat happensThe habit that avoids it
Typing full names into Name fieldsCloudflare appends your domain — records land at doubled names and never resolve.Type the relative name only (_dmarc, google._domainkey); read back after saving.
“Fixing” the split DKIM valueAdding quotes/backslashes to tidy the chunks corrupts the key.Paste exactly as issued; verify by read-back, where it reassembles.
A second SPF record “for” another toolTwo v=spf1 records = PermError, both ignored.One record; merge includes inside it.
Proxy thinkingTXT/MX records cannot be proxied — but mail-related A records nearby can, and break silently.Every email record: DNS only; nothing in this guide needs the orange cloud.

FAQ — the issues people hit in this exact setup

Google says “you must update the DNS records” for DKIM, but I already did.

Check the read-back first: correct name (no doubling) and exact value means the warning is the documented up-to-48-hour propagation lag. Incorrect read-back means fix the record, not the waiting.

Can I skip DMARC since SPF and DKIM pass?

Passing checks without DMARC is exactly the gap Gmail's sender rules closed: DMARC is what ties a pass to your From domain, and bulk-sender enforcement requires it to exist. It is also your only window into who else sends as you.

My domain also sends from other tools (shop, invoicing). Does this guide break them?

No — each tool gets its own include in the single SPF record and its own DKIM selector; DMARC judges all of them against the same record. This guide's SPF step is where their includes merge.

Sources

Google Workspace Admin Help — Set up MX records (single-record instruction), Set up SPF, Turn on DKIM, Set up DMARC · Cloudflare Developers — DNS records management and DMARC Management documentation · Live DNS resolution of Google's SPF chain, October 2026 (include cost: 1 lookup). · Method cross-check (default-key behaviour): GetSiteAudit Workspace authentication guide.

Verification note: record values, console paths, the 48-hour preconditions and the Start-authentication step were confirmed against Google's live documentation on 20 October 2026; the conflict between Cloudflare's Workspace MX guidance and Google's current single-record instruction is reported as found, with Google followed.