DMARC for Google Workspace: SPF, DKIM, and DMARC Step by Step

Google Workspace handles a lot for you. Email authentication isn't one of them.

Out of the box, Workspace mail only passes SPF if you've added Google to your SPF record, and DKIM signs with a Google-owned domain instead of yours. That second part is why so many first-time DMARC reports show Workspace mail with "DKIM pass" and a DMARC failure on the same row.

Here's the complete setup: SPF, DKIM, then DMARC, in the order that avoids surprises. Plan on about 30 minutes of actual work plus some waiting on DNS.

Before you start

You need three things:

Super admin access to the Google Admin console.
Access to your DNS host, wherever your domain's records live (Cloudflare, your registrar, Route 53, etc).
A list of everything else that sends as your domain. This guide only covers mail sent through Gmail. Your app's transactional email, newsletter tool, CRM, and helpdesk each need their own SPF and DKIM setup. If you skip them, they'll show up as failures in your reports. The indie dev DMARC stack post covers the general approach.

Step 1: Add Google to your SPF record

If you don't have an SPF record yet:

example.com TXT "v=spf1 include:_spf.google.com ~all"

If you already have one, add the include before the all at the end:

example.com TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"

A few things to get right:

One SPF record per domain. A second v=spf1 record doesn't add to the first one. It makes both invalid.
Use ~all, not -all, to start. Some receivers reject on an SPF hard fail before DMARC ever runs, which can bounce forwarded mail that would have passed on DKIM. Let your DMARC policy do the enforcing.
Watch the lookup count. Google's include nests other includes, so it costs more than one of your 10 allowed DNS lookups. If you're stacking several providers, run the record through the SPF checker before you publish it.

SPF on its own isn't enough. It breaks as soon as a message gets forwarded, because the forwarding server's IP isn't in your record. DKIM survives forwarding. That's why the next step matters more.

Step 2: Turn on DKIM with your own domain

This is the step people skip, and it's the one that decides whether Workspace mail passes DMARC.

Until you set it up, Google signs your outgoing mail with a default key on a Google-owned domain, something like example-com.20230601.gappssmtp.com. The signature is valid, so DKIM passes. But the signing domain doesn't match your From address, so it doesn't count toward DMARC. (The alignment post explains why that matters.)

To fix it:

Go to admin.google.com and open Menu > Apps > Google Workspace > Gmail > Authenticate email.
Pick your domain from the Selected domain dropdown.
Click Generate new record. Choose 2048-bit unless your DNS host can't handle it. Leave the selector prefix as google unless you're already using that selector for something else.
Copy the host name and TXT value Google shows you.
Add it as a TXT record at your DNS host:

google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Wait for DNS to propagate, then go back to Authenticate email and click Start authentication. The status should change to show it's authenticating email with DKIM.

Where this usually goes wrong:

Not clicking Start authentication. Generating the key and publishing it in DNS isn't enough. Google doesn't sign with your key until you click the button. If your reports still show gappssmtp.com as the DKIM domain a week later, this is almost always why.
The doubled host name. Most DNS dashboards append your domain automatically. Enter google._domainkey in the name field, not google._domainkey.example.com, or you'll end up with google._domainkey.example.com.example.com. The DKIM checker will tell you if the record is where it should be.
A truncated 2048-bit key. A 2048-bit key is longer than the 255-character limit for a single TXT string. Most DNS hosts split it automatically. Some older ones need you to break it into multiple quoted strings in the same record. If verification keeps failing, compare the p= value in DNS against what Google gave you.
Forgetting other domains. Secondary domains and alias domains each need their own key. Alias domains are easy to miss when users send from them.
Impatience. Google says DNS changes can take up to 48 hours to be visible. If Start authentication says it can't find the record, wait and try again before you start changing things.

Step 3: Publish a DMARC record

Nothing to do in the Admin console here. It's one DNS record:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Start at p=none. Point rua= at a mailbox you'll actually check, or straight at your MyDMARC reporting address so the reports get parsed for you.

Two Google-specific notes:

Don't copy Google's example record. Google's DMARC help page shows a sample with p=reject and strict alignment. That's an end state, not a starting point. Publishing it on day one is a good way to bounce your own invoices from a sender you forgot about. Get there gradually: here's how to move off p=none without breaking mail.
Don't wait for failure reports from Gmail. Google doesn't send forensic (ruf) reports. You'll get daily aggregate reports from Gmail, and that's it.

Step 4: Check that it works

Send a message from a Workspace account to a personal Gmail address (or any outside account), open it, and use Show original. You want to see SPF, DKIM, and DMARC all passing, with DKIM showing your domain, not gappssmtp.com.

You can also check each record with Google's Admin Toolbox (CheckMX) or the free DMARC, SPF, and DKIM checkers.

What your first reports will show

Aggregate reports usually start arriving within a day or two. Here's how to read the Workspace rows:

Google IPs, SPF and DKIM aligned: working as intended.
Google IPs, DKIM pass but not aligned: DKIM signing isn't on yet, or the report covers mail sent before you clicked Start authentication.
Google IPs, SPF fail but DKIM pass: usually forwarded mail or mailing lists. DKIM carried it, which is exactly why you set it up.
Sources that aren't Google: either another service you use that needs its own setup, or someone spoofing you. Here's how to tell the difference.

Do you actually need this?

If you send more than 5,000 messages a day to Gmail addresses, yes. Google has required SPF, DKIM, and a DMARC record (at least p=none) from bulk senders since February 2024.

If you're below that, Google still expects SPF or DKIM on everything you send, and a domain with no DMARC record is open for anyone to spoof. The setup above takes half an hour. Skipping it costs more the first time someone phishes your customers with your domain.

Once every legitimate source in your reports is passing and aligned, give it a couple of weeks, then move to p=quarantine and eventually p=reject. Here's how to step through that progression without breaking legitimate mail.