How to Set Up DMARC for Google Workspace

Google Workspace sends authenticated mail for your primary domain once SPF and DKIM are correct. DMARC layers policy and reporting on top so you can monitor authentication outcomes before you ask receivers to quarantine or reject failures. This guide walks administrators through a sequence that minimizes downtime for legitimate mail while exposing gaps early.

Prerequisites and scope

You need super administrator access to the Google Admin console and the ability to create TXT and CNAME records at your DNS host. Confirm which domains and aliases actually send mail: primary domain, secondary domains, and any send-as configurations that might still originate from Google's infrastructure. If you use third-party systems that send as your domain but do not align DKIM or SPF with your organizational domain, they will surface as failures once DMARC tightens—capture them during monitoring, not after enforcement.

Workspace can coexist with other providers for specialized mail flows, but SPF cannot list unlimited includes. Map every service that uses your domain in the 5321 or 5322 identifiers so you can rationalize includes and avoid the ten-DNS-lookup practical limit for SPF evaluation.

Enable and publish DKIM

In Admin console, open Apps → Google Workspace → Gmail → Authenticate email. Generate a DKIM key for each sending domain and add the TXT record Google provides at the designated host (typically google._domainkey). DNS propagation can take time; after verification, rotate status to start authentication so outbound messages pick up aligned signatures. If you operate multiple regions or brands, repeat per domain rather than assuming a single selector covers everything.

DKIM alignment for DMARC requires the signing domain to align with the From domain users see. Messages sent through groups or aliases may need additional configuration so the visible From remains consistent with the key you publish.

Tune SPF for Workspace

Publish a TXT record at your apex or designated SPF host that authorizes Google's sending space. The common pattern includes include:_spf.google.com, but you must merge this carefully with other vendors. Use -all or ~all according to your risk posture; stricter endings expose misconfigured senders faster. Validate the record with a DNS scanner to catch typos and lookup explosions before you rely on it in production.

Remember that SPF checks the envelope sender. If a third-party uses its own bounce domain, SPF may pass for that domain while DMARC still fails on alignment—DKIM from an aligned domain becomes the saving signal, or you must adjust the bounce domain where the vendor allows it.

Publish the DMARC TXT record

Create a TXT record at _dmarc.yourdomain.com. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (replace the mailbox with an address that can receive attachments). Optional tags such as fo=1 can increase forensic detail in some receivers, but aggregate reports are your workhorse. Keep the record syntactically valid—parsers are strict, and a malformed TXT will be ignored silently by many providers.

If you operate subdomains, consider an explicit sp= policy once the root is stable, or publish organizational policy using DNS hierarchy that matches how mail actually flows from those hosts.

Read reports and remediate

Within days you should see aggregate files from major mailbox providers. Look for unexpected sources, countries, or failing combinations of SPF and DKIM. For each anomaly, determine whether it is a legitimate vendor that needs authentication help, a forgotten application, or abuse. Fix forwarding scenarios carefully: some forwards break DKIM while SPF may not survive either, which shows up as aligned failures even for mail you thought was internal.

Document baselines: expected volume bands per sender, known IP ranges, and approved DKIM selectors. When the unknown portion of traffic drops to a level your risk committee accepts, schedule policy escalation with rollback steps documented.

Stage quarantine and reject

Move to p=quarantine during a maintenance window after stakeholders sign off. Consider pct below 100 at first so a slice of traffic reveals edge cases. Monitor helpdesk tickets and marketing metrics closely. When quarantine is stable, evaluate p=reject for domains where spoofing risk outweighs the chance of false positives.

Workspace-specific tools like the Email Log Search and security dashboards complement DMARC XML; combine both views when investigating sudden spikes in authentication failures after a policy change.

Validate your live records anytime—SPF, DKIM, DMARC, and MX—in one scan before and after each DNS change.