How to set up SPF, DKIM & DMARC for Google Workspace

If you send mail from Google Workspace (Gmail on your own domain), three DNS records prove that mail is really yours: an SPF record that authorises Google’s servers, DKIM that Google enables and signs with, and a DMARC record that ties both to your visible From address. This guide gives you the plain-English version first, then the exact records and the Admin console clicks an administrator needs.

Written & reviewed by the VerifyAnyEmail team · Last reviewed July 2026

Here is the whole thing in one breath: publish one SPF TXT record that includes Google, turn on DKIM in the Admin console and publish the key it hands you, then publish a starter DMARC record. The first two tell Gmail, Yahoo and Outlook that your messages genuinely come from your Google Workspace tenant; the third tells those inboxes what to do if a message fails and sends you reports so you can watch. None of it costs anything, and you can verify all three in about a minute once DNS has propagated.

What each record does here (the non-technical version)

Think of it as three overlapping proofs. SPF is a public list of “servers allowed to send as my domain” — you add Google to that list. DKIM is a tamper-proof wax seal: Google signs every outgoing message with a private key, and receivers check it against a public key you publish in DNS. DMARC is the policy that says “at least one of those two must not only pass but also match my From address, and here is what to do when it doesn’t.” With Google Workspace the happy path is easy because Google both sends and DKIM-signs as your own domain, so alignment falls out naturally once DKIM is on. For the deeper mechanics see the complete SPF, DKIM & DMARC guide.

Step 1 — Publish the SPF record

Add a single TXT record at the root of your domain authorising Google’s mail servers. The Google include is stable and well-known:

Host/Name:  @   (your root domain) Type:       TXT Value:      v=spf1 include:_spf.google.com ~all

If you also send through other services (a newsletter platform, a helpdesk, a billing system), those includes go in the same record — you may only ever have one v=spf1 record, for example v=spf1 include:_spf.google.com include:sendgrid.net ~all. Two separate SPF records is a permanent error that voids SPF entirely, and remember the total is capped at ten DNS lookups. Use ~all (soft fail) while you settle in; you can tighten to -all later. Google’s own instructions are here: Add or update your SPF record. When it’s live, confirm it with the SPF Checker.

Step 2 — Turn on DKIM in the Admin console

Unlike SPF, the DKIM public key is unique to your tenant, so you generate it inside Google’s console rather than copying a fixed value. As a Workspace super administrator:

  1. Sign in to the Google Admin console.
  2. Go to Apps → Google Workspace → Gmail → Authenticate email.
  3. Select the domain, choose a 2048-bit key length, and click Generate new record. Google returns a DNS host and a long TXT value.

The record Google generates uses the selector google and looks like this (your p= value will be your own key, not the placeholder):

Host/Name:  google._domainkey Type:       TXT Value:      v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...  (from your Admin console)

Publish that TXT record at your DNS provider exactly as shown. Some providers split a long value into multiple quoted strings automatically — that’s fine. Then return to the Authenticate email page and click Start authentication. Google’s reference: Turn on DKIM signing. Confirm the published key resolves with the DKIM Checker (selector google).

Two things worth knowing: DKIM can take up to 48 hours to become active after you click Start authentication, and until you turn it on Google signs with a shared default key that is not aligned to your domain — so this step is what actually makes DMARC pass.

Step 3 — Publish a starter DMARC record

Now add DMARC. Start in monitor-only mode so nothing is affected while you watch the reports come in:

Host/Name:  _dmarc Type:       TXT Value:      v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

The p=none policy changes nothing about delivery — it just switches on the daily aggregate reports sent to the rua mailbox, which tell you every service sending as your domain and whether each passes. Build a correct record with the DMARC Generator and validate it with the DMARC Checker. Because the XML reports are unreadable by hand at any volume, point rua at a DMARC monitoring inbox that parses them for you.

Step 4 — Verify everything passes

Once DNS has propagated (allow a few hours, up to 48 for DKIM), confirm all three at once. Run your domain through the Email Health Check for a single pass/fail on SPF, DKIM and DMARC, or check them individually with the SPF Checker, DKIM Checker and DMARC Checker. The most reliable real-world test is to send an actual message to a personal Gmail account, open Show original, and confirm SPF, DKIM and DMARC all read PASS.

Step 5 — Move DMARC toward enforcement

After two to four weeks of clean reports where every legitimate sender passes, tighten the policy so spoofers are actually stopped. Go p=none → p=quarantine (optionally with pct=25 first) → p=reject, checking reports at each step. This is the policy Gmail and Yahoo reward and the prerequisite for a BIMI logo. The staged rollout is covered in the complete guide.

Common mistakes

  • Forgetting to click “Start authentication.” Publishing the DKIM TXT record isn’t enough — Google won’t sign with your key until you flip the switch in the console. DKIM will keep failing until you do.
  • A second SPF record. If another tool already added v=spf1, don’t create another — merge Google’s include into the existing one. Two SPF records is a permerror.
  • Adding the DKIM record at the wrong host. It belongs at google._domainkey, not the root. If your DNS panel auto-appends the domain, don’t type it twice.
  • Sending through a third party without aligning it. Marketing platforms and helpdesks each need their own DKIM/SPF setup or DMARC will fail for that stream even though Gmail is fine. See why SPF passes but DMARC fails.
  • Jumping straight to p=reject. Do it before you’ve inventoried your senders and you’ll blackhole legitimate mail. Stage it.

Where the records go

All three records live at whoever hosts your domain’s DNS, not at Google. If that’s Cloudflare, follow how to add DNS records in Cloudflare and remember to keep these records DNS-only (grey cloud). The authoritative, always-current values come from Google’s own docs linked above and from the record Google generates in your Admin console — treat the DKIM p= value there as the source of truth for your tenant.

Check your domain in seconds

Run the free diagnostics referenced in this guide — no sign-up needed.

Email Health CheckAll tools

More guides

🧹 How to Clean an Email List Before a Campaign (2026 guide)
A step-by-step workflow to dedupe, validate and verify a list before you hit send — and keep bounces low.
🔬 How Email Verification Works (Without Sending an Email)
Syntax → MX → live SMTP probe → catch-all/role/disposable checks: the real pipeline, explained.
🚦 Deliverable, Risky, Catch-All & Unknown: How to Handle Every Verification Result
What each verification status means and the safe action to take — from sign-up forms to bulk sends.
🎯 Should You Send to Catch-All Emails? (2026)
Catch-all domains accept everything, so SMTP can’t confirm the mailbox. A practical decision framework.