DMARC for Google Workspace: A Complete MSP Implementation Guide

MSP Playbook

Introduction

Google Workspace is the other dominant tenant platform behind Microsoft 365, and the mechanics of getting DMARC working on a Workspace tenant are different enough from M365 that anyone running both will trip over the gaps. The good news: Workspace handles SPF and DKIM in the admin console rather than mail-server configuration, so the technical setup is genuinely simple. The bad news: the propagation timelines are longer, the DKIM model is single-selector by default (no automatic rotation), and the relay-routing edge cases are subtler than M365's.

This article is the complete implementation guide — whether you're an MSP managing many Workspace client tenants or a single tenant admin running a one-time rollout. The companion article for the Microsoft side lives at DMARC for Microsoft 365 if you need to switch contexts mid-engagement.

Why this topic matters for MSPs

Workspace handles SPF and DKIM in the admin console rather than in mail-server configuration files. That means the MSP value isn't in the technical setup — it's in the rollout discipline, the sender discovery, the ongoing monitoring, and the operational work of mapping non-Workspace senders into alignment. Same value model as M365, different admin paths.

For the single-tenant admin doing this for the first time, skip the multi-tenant orchestration sections; the per-tenant mechanics are identical.

The Google Workspace SPF baseline

Workspace's standard SPF:

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

For Workspace-only tenants, that's the whole record. For tenants with additional senders — the CRM, the marketing platform, the transactional service — add include: per sender, watching the 10-lookup limit defined in RFC 7208. Workspace's _spf.google.com itself consumes 2-3 lookups (it expands through nested includes), so your budget for other senders is a little better than M365's but still tight.

Workspace publicly recommends ~all (soft fail) rather than -all (hard fail). The rationale is operational — soft fail gives mailbox providers latitude to deliver borderline messages while you're still tuning. In practice, with DMARC enforcement at p=reject, the SPF terminal mechanism matters less because DMARC is the actual policy layer. If you're in monitoring mode, follow Workspace's ~all recommendation; once you're at p=reject, the difference is academic.

Publish at the apex domain as TXT.

Configuring DKIM in Google Workspace

DKIM signing is off by default, even on freshly provisioned Workspace tenants. Enabling it:

1. Admin console → Apps → Google Workspace → Gmail → Authenticate email.
2. Select the domain and click "Generate new record."
3. Choose key length — 2048-bit is recommended (1024-bit is the legacy default; many tenants have it set there and don't know).
4. Workspace provides a TXT record to publish at google._domainkey.yourdomain.com. The value is the public key plus the standard v=DKIM1; k=rsa; p=... framing.
5. Wait 24-48 hours for DNS propagation. This is longer than other platforms because Google verifies the key on its side before letting you activate signing.
6. Click "Start authentication" in the admin console.

Workspace uses a single selector (google) by default. Unlike M365's automatic dual-selector rotation, Workspace requires manual rotation: generate a new key, publish the new selector, switch the active selector in the admin console, retire the old. The standard cadence is annual; the full mechanics live in how to rotate DKIM keys safely.

A common pitfall: some tenants have a legacy 1024-bit key from years ago and don't realize it's still active. Modern mailbox providers (Gmail, Yahoo, Outlook.com) are increasingly skeptical of 1024-bit keys; rotate to 2048-bit during any DMARC rollout so this doesn't become a deliverability issue later.

Publishing the DMARC record

A standard starting record:

“text v=DMARC1; p=none; rua=mailto:[email protected] “

Published at _dmarc.yourdomain.com as TXT. The rua= address routes aggregate reports — point it at a DMARC platform's RUA endpoint rather than a raw mailbox; the XML payloads aren't human-readable.

Move through the policy phases over 8-12 weeks. The safe rollout sequence is universal: the difference for Workspace is in the discovery work (Workspace's audit logs surface senders differently than M365's) and the configuration paths, not in the DMARC mechanics. The full playbook lives in how to move from monitoring to enforcement safely.

The full step-by-step rollout

1. Audit current state. SPF, DKIM, DMARC records for the domain. Check the DKIM key length — 1024-bit legacy keys are still common.
2. Enable Workspace DKIM at 2048-bit. If a 1024-bit key is already in use, plan a rotation rather than a hot-swap.
3. Inventory non-Workspace senders. The CRM, marketing platforms, transactional services, ticketing tools, billing, finance systems. Workspace's audit logs can help you find unexpected outbound senders, but most discovery comes from the aggregate reports once p=none is published.
4. Configure custom DKIM at each non-Workspace sender. Each platform has its own admin path; the pattern is identical — generate a key, publish the public part at a selector, enable signing.
5. Publish DMARC at p=none with aggregate reporting enabled. Observe, don't enforce yet.
6. Monitor for 2-4 weeks. Read the reports. Workspace tenants tend to have fewer surprises than M365 tenants because the platform routing is simpler, but the long tail of shadow senders is real.
7. Fix the gaps. For each legitimate sender failing authentication, either add SPF / enable DKIM at the sender or document why the failure is expected.
8. Move through quarantine to reject. Phased pct rollout; rollback windows.

For MSPs, the work templatizes the same way it does on M365: per-tenant discovery, universal mechanics, scaled monitoring.

Google Workspace-specific gotchas

DKIM setup is TXT, not CNAME

Different DNS workflow than M365. The published value is the full TXT string including the public key, which is a single long line. Some DNS providers truncate or wrap long TXT values incorrectly — paste-verify before activating.

24-48 hour propagation wait

Longer than the typical DNS TTL because Google verifies the key on its side before letting you activate signing. Plan the rollout calendar accordingly; you can't enable signing the same day you publish the record.

Single selector by default

No automatic dual-selector like M365. Rotation is manual: generate a new key at a new selector name, publish both, switch the active selector in the admin console, then retire the old selector after a grace period. Document the rotation cadence in the client runbook.

Multi-domain tenants

Workspace can host multiple primary domains in a single tenant. Each domain needs DKIM enabled separately — the admin-console UI shows them per-domain, but it's easy to enable on the main domain and miss the aliases. Worth a checklist item.

Relay routing and inbound gateways

Tenants routing outbound through a third-party gateway (a security appliance, a legacy mail relay) need careful SPF design. The third-party IPs must be included in SPF and the DKIM signing has to happen at the right point in the relay chain — typically before the third-party hop, so the signature survives the relay.

App-specific senders

Workspace has a long tail of "send-as" configurations, group-aliased senders, and OAuth-app integrations (Google Calendar invites, Drive share notifications, etc.) that send mail with your domain in the From header. Most go through Workspace's signing pipeline, but the legacy SMTP relay (used by some on-prem systems) does not — those need separate authentication.

BIMI prerequisites

If the client is interested in BIMI (the logo-in-the-inbox feature), Workspace supports BIMI display in Gmail with a published BIMI record, a Verified Mark Certificate, and DMARC at p=quarantine or p=reject. Workspace is a good BIMI candidate because Gmail is one of the most BIMI-friendly receivers; build BIMI rollout into the Tier 3 hardening conversation.

Best practices

• Test DKIM after enabling. Send to a Gmail account, verify dkim=pass and that the signing domain aligns with the From header.
• Rotate DKIM keys annually. Workspace's single-selector model means rotation is a planned event, not automatic.
• Mind the SPF lookup budget. Workspace's _spf.google.com uses 2-3 lookups; budget the rest. SPF flattening is the usual escape hatch when you approach the cap.
• Document selectors and rotation history. When you rotate, the old selector stays in DNS during the grace period and then gets removed. Track this in the client runbook.
• Pair with MTA-STS for inbound transport security. Workspace publishes MTA-STS for incoming Gmail; publishing your own MTA-STS policy hardens inbound to your domain.

Recommended next step

Audit your Workspace client domains for DKIM and DMARC posture — most tenants have DKIM off entirely or running on 1024-bit keys. That audit alone is usually enough to justify the rollout to a client. For new Workspace client tenants, add DMARC to the onboarding checklist. For single-tenant admins running this once, plan for a calendar week of propagation buffer.

FAQ

Does Google Workspace sign all mail with DKIM by default?

No. DKIM must be explicitly enabled in the admin console; default tenants ship unsigned. This is one of the most common audit findings on Workspace tenants.

What if the client has multiple domains in Workspace?

Each domain needs DKIM enabled separately in the admin console. Multi-domain tenants are an easy place to miss configuration; check every domain individually.

Why does Workspace DKIM take 24-48 hours?

DNS propagation plus Google's own verification process. The wait is in the design — you publish the key, then Google verifies it before letting you activate signing.

Can I use a custom selector name instead of google?

google is the default. Some Workspace configurations allow custom selectors via admin SDK or API; for most tenants, stick with the default.

What about Workspace's ~all (soft fail) recommendation for SPF?

Workspace recommends soft fail in their docs. DMARC enforcement is the actual policy layer that blocks spoofing; SPF's terminal mechanism (~all vs -all) is less critical once DMARC is at p=quarantine or p=reject. During monitoring, follow Workspace's recommendation. After enforcement, the difference is operational rather than security-relevant.

How long does a full Workspace DMARC rollout take?

8-12 weeks from start to p=reject, plus the 24-48 hour DKIM propagation buffer at the start. The bottleneck is monitoring, not configuration.

Can I use a third-party DMARC platform with Workspace?

Yes — point rua= at any DMARC platform's RUA endpoint. This is the recommended setup; XML aggregate reports aren't human-readable.

Final thoughts

DMARC for Google Workspace clients runs the same playbook as Microsoft 365 with different admin-console mechanics and a longer propagation calendar. The MSP value is the rollout discipline, the monitoring, and the work of bringing non-Workspace senders into alignment. The recurring revenue from a Workspace DMARC service line looks identical to an M365 service line — same tier model, same cadence, same operational rhythm.

Standard process, predictable timeline. Productize once and run it across the portfolio.