Google Workspace SPF, DKIM & DMARC Setup Guide

Overview

Google Workspace (formerly G Suite) is the most widely deployed business email platform. Its SPF record is a single include:_spf.google.com directive that costs just 1 DNS lookup — one of the most efficient in the industry. However, most organizations pair Google Workspace with marketing platforms, CRMs, and transactional senders that stack additional lookups on top.

DKIM signing is not enabled by default in Google Workspace. Administrators must explicitly generate a DKIM key in the Admin Console and publish the corresponding DNS record before messages are signed. The default selector is google, and Google generates a 2048-bit RSA key. If your DNS provider doesn't support records that long, Google will fall back to a 1024-bit key.

DMARC alignment works well with Google Workspace because messages are sent from the organization's domain by default. Relaxed alignment is sufficient for most deployments. Organizations that also send through third-party services (marketing tools, transactional APIs) should verify that those services are properly configured for DMARC alignment before moving to a reject policy.

Additional Setup Notes

SPF Include Chain and Lookup Counting

Google's SPF includes chain through multiple nested records (_spf.google.com references _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com). While the initial include: costs only 1 lookup at the top level, SPF evaluators recursively resolve nested includes. This is handled within the Google lookup — you don't need to worry about the nested records when counting your lookup budget.

When transitioning from G Suite to Google Workspace, your SPF record does not need to change — the include mechanism is the same. If you're migrating from a legacy v=spf1 include:_spf.google.com ~all record, it still works. Just make sure DKIM is enabled in the new Admin Console, as the setting doesn't carry over automatically in all migration paths.

DKIM Activation and Key Length

Enabling DKIM in Google Workspace requires generating a key in the Admin Console under Apps > Google Workspace > Gmail > Authenticate email. After you generate the record, Google provides a TXT record value that you publish at google._domainkey.yourdomain.com. The record won't activate until Google detects the published DNS entry — propagation typically takes 15 minutes to an hour, but some DNS providers take up to 48 hours.

If you manage multiple domains under a single Google Workspace account (common for organizations that rebranded from their G Suite era or operate multiple brands), you must enable DKIM for each domain individually. DKIM configuration does not propagate across domains in a multi-domain setup. Each domain gets its own key and its own TXT record.

Google defaults to 2048-bit RSA keys, which produce TXT records around 380 characters. Some older DNS control panels truncate records at 255 characters, which silently breaks the key. If DKIM verification fails after publishing, check that your DNS provider stored the full record value. Cloudflare, Route 53, and most modern providers handle long TXT records correctly.

Migrating from G Suite or Gmail for Business

Organizations that originally set up email under the G Suite or Gmail for Business branding may have stale DNS records from that era. The SPF include (_spf.google.com) has remained consistent through every rebrand, so SPF records from the G Suite days still work. However, DKIM settings in the old G Suite admin panel did not always migrate cleanly to the current Google Workspace Admin Console. After migration, verify that DKIM is active by sending a test message and inspecting the DKIM-Signature header — the d= value should be your domain, and the s= value should be google.

If your organization was on G Suite's free tier (discontinued in 2022) and migrated to a paid Google Workspace plan, DNS records should carry over. But the Admin Console interface changed significantly, and DKIM settings may show as "not started" even if the DNS records are still published. Re-generate the key in the new console and verify the published record matches.

Troubleshooting

SPF PermError with Multiple Providers

The most common SPF issue with Google Workspace isn't Google itself — it's the accumulation of includes from other services. A typical mid-size organization might have Google Workspace, SendGrid or Mailchimp for marketing, a helpdesk tool, and a CRM that sends email. Each include: adds at least one lookup, and the SPF 10-lookup limit arrives fast.

Signs you've hit the limit: SPF checks return PermError, DMARC reports show SPF failures for legitimate mail, and deliverability drops without any configuration change on your end. Managed SPF can flatten all your includes into direct IP references, keeping you well within the lookup budget.

DKIM Shows "Not Authenticated" in Admin Console

If the Admin Console shows DKIM as not authenticated even after publishing the TXT record, check the following:

1. DNS propagation — Query the record directly with dig TXT google._domainkey.yourdomain.com and confirm the value matches what Google provided.
2. Record truncation — Ensure the full 2048-bit key is present. A truncated record will be syntactically invalid.
3. Conflicting records — Some domains have leftover DKIM records from previous providers at the same selector. Remove any stale google._domainkey records before publishing the new one.
4. Subdomain confusion — Make sure the record is published on the correct domain. If your Google Workspace uses company.com but you published the record on mail.company.com, it won't be found.

DMARC Alignment Failures with Third-Party Relays

Google Workspace handles alignment well for direct sends, but problems arise when messages route through third-party relays or gateways. If you use an outbound email gateway (e.g., Proofpoint, Mimecast, Barracuda, MailRoute) between Google Workspace and the internet, the relay may rewrite headers or modify the envelope sender, breaking alignment.

For relay configurations, ensure the gateway preserves the original Return-Path and does not strip or re-sign the DKIM signature. If the relay must re-sign, configure it to sign with your domain and a different selector — this preserves DKIM alignment even though the original Google signature may be invalidated by header modifications.

Google Workspace with Subdomains

Organizations that send from subdomains (e.g., notifications@app.company.com) need separate SPF and DKIM records for each subdomain. The SPF record on company.com does not cover app.company.com — SPF is evaluated per-domain. You'll need include:_spf.google.com in the SPF record for each sending subdomain, and a separate DKIM key generated and published for each one.