ESP guide

DMARC for Google Workspace: enabling DKIM the right way

Google Workspace DKIM is opt-in per domain. Until you turn it on, every message signs only with google.com — which never aligns with your From. Most other gotchas come from the SPF include and from Groups.

TL;DR

  • 1 _spf.google.com is 1 DNS lookup. The full include chain is around 4 lookups.
  • 2 DKIM signing is OFF by default. Turn it on at admin.google.com → Apps → Gmail → Authenticate email.
  • 3 Google enforces DMARC on inbound mail at p=reject as of Feb 1 2024 for bulk senders (5K+/day to Gmail).

What it does

Google Workspace ships with SPF (via the include) ready to go, but DKIM signing for your custom domain has to be explicitly enabled. Until then, outbound mail is unsigned for your domain — Google still signs with google.com but that d= won't align with your visible From.

Once enabled, Workspace signs with the selector you pick (default: google). The selector becomes part of the DNS record name: google._domainkey.yourdomain.com.

How it works

  1. 1

    Publish SPF including _spf.google.com. Keep it under 10 total lookups.

  2. 2

    In admin.google.com → Apps → Google Workspace → Gmail → Authenticate email, select your domain.

  3. 3

    Click 'Generate new record'. Choose 2048-bit key (Google's default). Copy the displayed TXT value.

  4. 4

    Publish at google._domainkey.yourdomain.com as a TXT record. Note: the value is long; many DNS providers split it automatically.

  5. 5

    Wait ~1 hour for DNS, then click 'Start authentication' in the admin UI. Status flips to Authenticating.

  6. 6

    Verify by sending a test message and checking the Authentication-Results header for dkim=pass with d=yourdomain.

Common pitfalls

  • Google Groups rewrite sender addresses by default. A message sent to engineering@yourdomain by a Workspace user goes out from the group address, breaking alignment for whoever the group forwards to externally. Set the Group to 'Don't display' from external members or use modern-style Collaborative Inbox.

  • Calendar invites sent from a personal alias or delegated account use a different DKIM signing path. Always test calendar.ics flow specifically.

  • Routing mail through a third-party (Mimecast inbound filtering) and then to Workspace breaks DKIM if the filter strips body whitespace. Configure the inbound gateway as a 'mail flow' Connector with strict header preservation.

  • Sub-account or aliased senders: an alias like sales@yourdomain that points to a Workspace user signs with that user's domain, not the alias. Use a routing rule, not a simple alias.