HHostWithSheryWebsite & Domain Troubleshooting ToolsCheck a domain
Menu
Provider repair guideReviewed 2026-08-07By HostWithShery technical editorial

Set up SPF, DKIM and DMARC for Google Workspace

Publish a single SPF policy, enable DKIM with the Admin-console selector and deploy DMARC deliberately.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Email Health Check

This page is preconfigured with the Email Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Checks MX routing plus SPF, DKIM discovery, DMARC, BIMI, MTA-STS and TLS-RPT public signals.

No account · Public configuration only
On this page

Set up SPF, DKIM and DMARC for Google Workspace: when this repair path applies

Publish a single SPF policy, enable DKIM with the Admin-console selector and deploy DMARC deliberately. Use these steps when authentication is incomplete even though mail delivery works, but first run the embedded diagnostic so the business-email DNS and mail authentication evidence supports this provider-specific path rather than a neighboring DNS, TLS, application or mail cause.

Find the authoritative setting before editing

Google Admin console for service/verification values and the authoritative DNS provider for MX, SPF, DKIM and DMARC publication. For Set up SPF, DKIM and DMARC for Google Workspace, confirm the active nameservers and exact service owner before changing validate SPF. A DNS-looking screen at google-workspace has no public effect when another provider is authoritative for the zone.

Evidence to save for Set up SPF, DKIM and DMARC for Google Workspace

Record the current public state for validate SPF, enable/publish DKIM, start DMARC reporting. This gives the repair a before/after comparison and prevents a cached answer or a separate working service from being confused with the configuration that produced the symptom.

  • Validate SPF — Inspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
  • Enable/publish DKIM — Use the selector configured by the sender or found in a DKIM-Signature header. Selector guessing is only a convenience and an empty guessed result is not proof that DKIM is absent.
  • Start DMARC reporting — Query _dmarc, validate the policy tags and distinguish publication from message-level alignment; a published record does not by itself prove every message passes DMARC.
  • Tighten policy after evidence — Verify tighten policy after evidence from the public Internet and compare it with the value the responsible provider says should be live.

Repair steps in google-workspace

Publish a single SPF policy, enable DKIM with the Admin-console selector and deploy DMARC deliberately.

  • 1. Validate SPF. After this step, check the public value tied to validate spf before changing another unrelated setting.
  • 2. Enable/publish DKIM. After this step, check the public value tied to enable/publish dkim before changing another unrelated setting.
  • 3. Start DMARC reporting. After this step, check the public value tied to start dmarc reporting before changing another unrelated setting.
  • 4. Tighten policy after evidence. After this step, check the public value tied to tighten policy after evidence before changing another unrelated setting.

Why this order matters for google-workspace

The sequence begins with the provider/authority decision, then moves through validate SPF, enable/publish DKIM, start DMARC reporting. That keeps the change scoped to the failed business-email DNS and mail authentication path and avoids replacing nameservers, mail authentication or another healthy service just to make a provider dashboard indicator change.

Verify Set up SPF, DKIM and DMARC for Google Workspace

The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. Compare the same validate SPF and enable/publish DKIM evidence used before the change; a repair is complete when the public result agrees, not merely when the google-workspace interface reports that a save succeeded.

If google-workspace and the public result disagree

Check whether the edited zone is authoritative, whether the exact root/www/subdomain was changed, whether a proxy state alters the visible endpoint, and whether a prior TTL can still exist in recursive caches. Do not add a second conflicting validate SPF value to force validation.

Mistakes to avoid for this repair

Do not copy tenant-specific or region-specific values from another account, delete working email records during a website repair, change nameservers as a shortcut, or alter SSL/proxy modes without evidence from the origin. Set up SPF, DKIM and DMARC for Google Workspace should change only the settings required by this diagnosis.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.