How to Set Up SPF, DKIM & DMARC for Google Workspace (2026 Guide)

If you run email on Google Workspace, you already have most of what you need to authenticate your domain — but "most" is the problem. Workspace passes SPF out of the box, yet it won't sign your mail with DKIM until you explicitly enable it, and it never publishes a DMARC record for you. That gap is why a domain can "work fine" for years and still be trivially spoofable.

This guide walks the three records in the order that actually passes, with the gotchas that quietly cost teams a week. If you want the underlying concepts first, start with what DMARC is and why it matters — everything below assumes you just want the records in place.

What Google Workspace authenticates by default

When you verified your domain, Google had you add an MX record and, usually, an SPF record. That covers the envelope — the path mail travels. It does not cover two things attackers exploit:

• DKIM signing for your domain. Workspace can sign with a generic Google key, but that key aligns to a Google domain, not yours. For DMARC to pass on your domain, you need a DKIM key published under your domain. It's off until you switch it on.
• A DMARC policy. Without one, receivers have no instruction for what to do when mail fails authentication — so they let it through. A spoofed message sails into the inbox.

The fix is three DNS records. Budget an afternoon, plus 24–48 hours for reports to start flowing.

Step 1 — SPF for Google Workspace

SPF tells receivers which servers may send mail for your domain. For Workspace the core record is:

v=spf1 include:_spf.google.com ~all

Publish that as a TXT record on your root domain (@). Two rules that trip people up:

• One SPF record per domain. If you already have an SPF record — say for a marketing platform — merge the includes into a single record. Two separate v=spf1 records is a hard fail.
• Mind the 10-lookup limit. Every include: counts. Stack Workspace + a CRM + a helpdesk + a newsletter tool and you can blow past ten DNS lookups, which invalidates SPF entirely. If you're close, our free SPF generator flattens and checks the count for you.

Leave the qualifier at ~all (soft fail) while you roll out. You can move to -all (hard fail) once DMARC is enforcing.

Step 2 — Turn on DKIM in the Admin console

This is the step that's easy to half-finish. In the Google Admin console:

1. Go to Apps → Google Workspace → Gmail → Authenticate email.
2. Pick your domain, choose a 2048-bit key, and click Generate new record.
3. Google shows you a TXT record with the host google._domainkey. Publish it in your DNS exactly as shown.
4. Come back and click Start authentication.

That last click is the gotcha. Publishing the TXT record alone does nothing — Workspace doesn't begin signing until you press Start authentication, and plenty of domains sit for months with a perfect DKIM record that's never actually used. If your DNS UI rejects the long 2048-bit value, split it into quoted strings (most providers accept the chunked format), or temporarily generate a 1024-bit key and upgrade later.

Give DNS up to 48 hours to propagate before you expect to see DKIM passing. Want the deeper mechanics? See what DKIM is.

Step 3 — Publish DMARC at p=none

Now the policy record. Publish a TXT record at the host _dmarc on your root domain:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none means "watch, don't block." It changes nothing about delivery — it just asks receivers to send you aggregate reports about who's sending as your domain. That visibility is the entire point of starting here. Generate a complete record (including subdomain policy and reporting options) with the free DMARC generator.

Point rua= at an address — or a monitoring tool — that someone actually reads. Reports landing in an unwatched inbox are useless, and reading raw aggregate XML by hand is its own special misery.

Verify alignment before you enforce

Here's the part legacy guides skip. Passing SPF or DKIM is not the same as DMARC passing — the authenticated domain has to align with the domain in your visible From: address. Workspace mail will align once DKIM is signing on your domain, but third-party senders (your CRM, billing, newsletters) often won't until you configure each one.

So before you tighten the policy, read your aggregate reports and confirm every legitimate source is authenticating and aligned. When the reports are clean, move in stages:

• p=none → monitor until sources align
• p=quarantine → suspicious mail goes to spam
• p=reject → spoofed mail is refused outright

The day you flip to reject should be a non-event, because the reports already told you nothing legitimate will break. We cover the staged path in detail in the DMARC rollout playbook.

Common Workspace gotchas

• DKIM published but not "started." The #1 issue. Re-check that you clicked Start authentication.
• Two SPF records. Merge into one; never publish a second v=spf1.
• SPF over 10 lookups. Adding senders silently breaks SPF — audit the count.
• Jumping to p=reject early. You'll junk your own invoices and replies. Earn enforcement with evidence.
• Subdomains left open. A root-domain p=reject doesn't cover subdomains unless you set sp=. Unused subdomains are a favorite spoofing vector.

Frequently asked questions

Does Google Workspace set up DMARC automatically? No. Workspace handles SPF at verification and can generate a DKIM key, but you must enable DKIM signing and publish your own DMARC record. None of the three enforce anything until you configure them.

Why is my DKIM not working after I added the record? Almost always because authentication was never started. Publishing the google._domainkey TXT record is only half the step — return to Apps → Gmail → Authenticate email and click Start authentication. Then allow up to 48 hours.

Can I go straight to p=reject? You can, but don't. Until your reports confirm every legitimate sender aligns, p=reject risks blocking your own mail. Start at p=none, verify, then tighten.

---

Once the three records are live and your reports are clean, the work shifts from setup to monitoring — catching the new sender someone adds next quarter before it fails silently. That's the part DDMARC is built for: readable reports instead of raw XML, and an alert when something drifts.