schedule 3-min read

DMARC for Google Workspace Clients: MSP Implementation Guide

A complete DMARC rollout guide for MSPs managing Google Workspace clients — SPF includes, DKIM setup, and the Workspace-specific gotchas.

01

Introduction

Google Workspace is the other major tenant platform for MSP clients. This article is the parallel implementation guide to the Microsoft 365 version — Workspace-specific SPF, DKIM, DMARC setup with the gotchas to watch.

02

Why this topic matters

Workspace handles SPF and DKIM in the admin console rather than mail-server config. The MSP value is the rollout discipline, monitoring, and the work of mapping non-Workspace senders.

03

The Google Workspace SPF baseline

Workspace's standard SPF: v=spf1 include:_spf.google.com ~all.

For Workspace-only tenants, that's the record. For tenants with additional senders, add include: per sender, watching the 10-lookup limit.

04

Configuring DKIM in Google Workspace

  1. Admin console → Apps → Google Workspace → Gmail → Authenticate email.
  2. Select the domain and click "Generate new record."
  3. Choose key length (2048-bit recommended).
  4. Workspace provides a TXT record to publish at google._domainkey.yourdomain.com.
  5. Wait 24-48 hours for DNS propagation.
  6. Click "Start authentication" in the admin console.

Workspace uses a single selector (google) by default. For rotation, generate a new key, switch the active selector, retire the old.

05

Publishing DMARC

Standard starting record:

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

Published at _dmarc.yourdomain.com. Move through the policy phases over 8-12 weeks.

06

Step-by-step approach for the rollout

  1. Audit current state. SPF, DKIM, DMARC published or not.
  2. Enable Workspace DKIM.
  3. Inventory non-Workspace senders. Marketing, CRM, transactional platforms.
  4. Custom DKIM at each non-Workspace sender.
  5. Publish DMARC at p=none with reporting.
  6. Monitor 2-4 weeks.
  7. Move to enforcement.
07

Google Workspace-specific gotchas

  • DKIM setup is TXT, not CNAME. Different DNS workflow than M365.
  • 24-48 hour propagation wait before enabling.
  • Single selector by default. Rotation requires generating a new key + switching, no automatic dual-selector like M365.
  • Routing through Workspace for outbound is automatic; on-prem hybrid is rarer.
08

Best practices

  • Test DKIM after enabling. Send to Gmail, verify dkim=pass and signing domain.
  • Use DKIM rotation annually.
  • Mind the SPF lookup budget. Workspace alone uses 2-3 lookups.
  • Document selectors and rotation history.
  • Pair with MTA-STS and the rest of the stack.
09

Audit your Workspace client domains for DKIM and DMARC posture. Most haven't enabled DKIM by default — that's the first fix.

10

FAQ

Does Google Workspace sign all mail by default?

No, DKIM must be explicitly enabled.

What if the client has multiple domains in Workspace?

Each domain needs DKIM enabled separately.

Why does Workspace DKIM take 48 hours?

Propagation + Google's verification process. The wait is in the design.

Can I use a custom selector name?

Workspace defaults to google. Some Workspace configurations allow custom selectors.

What about Workspace's SPF Soft Fail recommendation?

Workspace recommends ~all (soft fail). DMARC enforcement is the actual policy layer; SPF's terminal mechanism is less critical.

11

Final thoughts

DMARC for Google Workspace clients runs the same playbook as Microsoft 365 with different admin-console mechanics. The MSP value is the rollout, the monitoring, and the work of bringing non-Workspace senders into alignment.

Standard process, predictable timeline. Productize once.

Ready to Implement?

Get authenticated mail moving in minutes — start free, book a guided demo, or talk to the team about your stack.