Provider guide

Google Workspace DMARC

By Adam W., founder of DMARCit · Last updated 2026-06

Google Workspace gives you DKIM signing in the admin console, a small SPF include, and Postmaster Tools for visibility. The basics are simple. The trouble starts when a marketing platform or a third-party SMTP relay sends as your domain without aligned authentication, and Gmail's February 2024 enforcement turns every misconfigured sender into a 550 5.7.26 rejection.

Setting up DKIM in the Admin console

Unlike Microsoft 365, Google Workspace does not enable DKIM automatically. Outbound Gmail is unsigned until you generate a key, publish the TXT record, and turn signing on. Until then, DMARC alignment depends entirely on SPF, and SPF breaks the moment a recipient forwards your mail.

Generate the key

In the Google Admin console: Apps → Google Workspace → Gmail → Authenticate email. Pick your domain. Click Generate new record. Choose 2048 bits if your DNS provider supports it (most do; the chunking of long TXT records is automatic at any modern DNS host). Use the default selector google unless you have a reason to choose another.

Publish the TXT record

The console shows the record to publish. The shape is:

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Some DNS providers still hide that they handle long TXT chunking under the covers. If you see length errors, drop to 1024 bits as a workaround, but 2048 is the right default. NIST has been pushing 2048-bit RSA as the minimum for new keys for years.

Start authentication

Back in the console, click Start authentication. Google says it can take up to 48 hours after the TXT record is in place before signing actually begins. In practice it's usually a few hours, but plan for the 48-hour window before you assume something's broken.

Confirm by sending a test message to a non-Google inbox (Outlook, Yahoo, ProtonMail) and viewing the original headers. The DKIM-Signature line should show d=yourdomain.com with s=google.

SPF for Google Workspace

The baseline SPF record:

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

The include:_spf.google.com mechanism resolves to roughly 4 DNS lookups. RFC 7208 caps a single SPF record at 10 lookups total. Google's include uses almost half your budget before you've added anything else.

Add Mailchimp (include:servers.mcsv.net), SendGrid (include:sendgrid.net, 4 lookups on its own), and a transactional sender, and you're over the limit. SPF returns permerror, every SPF check fails, and DMARC alignment now rests entirely on DKIM.

The ~all (softfail) qualifier is the Google-recommended default while you're still confirming your sender list. Move to -all (hardfail) once you're sure nothing legitimate is missing. The DMARC policy you publish matters more than the SPF qualifier in practice. SPF softfail with DMARC at p=reject still rejects mail. SPF hardfail with DMARC at p=none still delivers it.

When the lookup count gets close to 10, the standard tools are SPF flattening (resolving includes to IP mechanisms, which requires ongoing monitoring for upstream changes) or moving senders to a subdomain with its own SPF. SPF PermError walkthrough.

The Gmail February 2024 enforcement change

In February 2024, Google began enforcing authentication requirements for bulk senders to Gmail. The thresholds and rules:

• Bulk senders (5,000+ messages/day to Gmail): Must have either SPF or DKIM aligned with the From: domain, a DMARC record at minimum p=none, a one-click unsubscribe header (List-Unsubscribe-Post) for marketing mail, and a spam complaint rate under 0.3% in Postmaster Tools.
• All senders to Gmail: Must publish either SPF or DKIM (DMARC not strictly required at low volume, but the policy is converging on requiring it).

Failures are rejected with:

550 5.7.26 This message does not have authentication information or fails to
pass authentication checks (SPF or DKIM). To best protect our users from
spam, the message has been blocked.

The threshold is 5,000 messages per day to Gmail addresses, not total outbound. A B2B sender to mostly corporate domains can sit under the threshold for months and then trip it during a single campaign blast. Plan for the authentication requirements regardless of current volume. See 550 5.7.26 explained.

Google Postmaster Tools

Google Postmaster Tools (postmaster.google.com) is the only first-party window into how Gmail treats your domain. The data it exposes:

• Spam rate: The percentage of mail from your domain marked as spam by Gmail users. The 0.3% threshold from the 2024 enforcement is measured here.
• Authentication results: SPF, DKIM, and DMARC pass rates, broken out by IP range.
• Domain and IP reputation: Google's opinion of how trustworthy your sending is. Bad, Low, Medium, High.
• Delivery errors: Counts of mail rejected, deferred, or routed to spam.
• Encryption and feedback loop: TLS coverage and complaint feedback for mailing lists.

Verify your domain in Postmaster Tools the same way you verify it in Search Console: publish a TXT record or upload a verification file. The data lags by a day, so trends matter more than any single day's number.

Failure modes specific to Google Workspace

Third-party SMTP relay setups

The most common alignment failure on Google Workspace tenants: a marketing platform (Mailchimp, Constant Contact, HubSpot) or a transactional sender (SendGrid, Postmark, Amazon SES) sending as marketing@yourdomain.com. The vendor signs DKIM with their own domain. The Return-Path is also under their domain. SPF passes for their domain, not yours. DKIM passes for their domain, not yours. DMARC fails because nothing aligns with yourdomain.com.

Every major SaaS sender supports both fixes: custom Return-Path (CNAME alias under your domain) for SPF alignment, and custom DKIM (TXT record under your domain) for DKIM alignment. Both need DNS records you control. Both should be in place before you move past p=none.

The Gmail-as-google.com confusion

A new admin sometimes assumes that because Gmail signs everything with d=gmail.com for personal accounts, Google Workspace must auto-sign for the custom domain too. It doesn't. Workspace mail is unsigned until you go through the admin console DKIM setup. The confusion costs the admin a few weeks before they realize alignment isn't happening.

Routing complexity: dual delivery and send-as

Workspace supports dual-delivery setups (where mail is also routed to a secondary system like an on-premise archive), send-as aliases (where users send from addresses on other domains), and split-domain routing. Each adds an alignment risk. Dual delivery may go through a relay that strips or modifies signatures. Send-as from a domain you don't control means DMARC alignment depends on that other domain's authentication, not yours. Split-domain routing where part of your mail flow goes through a non-Google MX can sign DKIM with whatever that intermediate system is set up to sign with, often not your domain.

Group delivery rewrites

Google Groups can rewrite the From: address on inbound mail before redistributing to members. The original DKIM signature stays intact, but the From: header it signed no longer matches. Members' DMARC verification then fails because the From: alignment domain is different from what was signed. The mitigation is to configure the group to preserve the original From: (which can cause its own issues with strict DMARC at the original domain) or to rewrite the From: to a group-owned domain you control DMARC for.

Forwarded mail breaking SPF

When a Gmail user forwards mail elsewhere, the Return-Path is preserved. SPF then fails at the next hop because the forwarding IP isn't in your SPF record. DMARC alignment via SPF is lost. The mitigation is the same as anywhere else: custom DKIM, which survives forwarding when the body isn't modified. Google also validates ARC (Authenticated Received Chain) signatures on inbound, reducing false DMARC failures on mail forwarded through trusted intermediaries.

The minimum DMARC record for a Google Workspace tenant

Once SPF is clean and custom DKIM is signing, publish DMARC. Start in monitoring mode:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; sp=none; adkim=r; aspf=r"

Watch the aggregate reports for at least two weeks. Identify every third-party sender that fails alignment. Fix them one at a time. Then move to p=quarantine with pct=10, ramp to pct=100, then move to p=reject.

The full path through enforcement is in What is DMARC? The provider-specific work above is what makes that path actually finish on Google Workspace.

Where Workspace tenants get stuck

• DKIM never enabled: The TXT record is published but Start authentication was never clicked in the admin console. Outbound Gmail is unsigned. SPF alone is the only path to DMARC, and forwarded mail breaks it.
• Third-party senders unaligned: Mailchimp, SendGrid, HubSpot, and similar tools send as your domain without custom Return-Path or custom DKIM. Aggregate reports show high DMARC failure rates from those sender IPs.
• SPF over the 10-lookup limit: Google's include alone is roughly 4 lookups. Adding 2 to 3 more senders pushes you over. SPF permerror wipes out SPF as a DMARC path. SPF PermError fix
• Spam rate over 0.3% in Postmaster Tools: Even with clean authentication, exceeding the spam threshold triggers Gmail's bulk-sender throttling and eventual rejection. Authentication is necessary but not sufficient.
• Group rewrites breaking external DMARC: Google Groups that forward to external members can break the From: alignment for the original sender's domain. Subtle and easy to miss until an external recipient reports rejections.

How Google Workspace connects to the rest of the stack

• DMARC is the policy layer that ties SPF and DKIM together. Read the policy mechanics first if they're unfamiliar.
• SPF authorizes sending IPs. Google's 4-lookup include is the part that eats most of your budget.
• DKIM cryptographically signs messages and survives forwarding. The default google selector is what the Workspace admin console publishes.

Related content