Email DNS Check

Google Workspace SPF Not Working – Fix include:_spf.google.com (2026)

Google Workspace SPF fails when include:_spf.google.com is missing, added on the wrong domain, or blocked by duplicate SPF records. This is common when teams migrate to Google Workspace but leave older SPF records untouched or publish changes on the wrong hostname. As a result, mail appears to come from your domain, but SPF does not authorize Google’s sending path correctly. Start with your SPF record status and then check for multiple SPF records if things still look off.

Last updated: 3/27/2026

If your SPF setup is complex, review the SPF lookup limit guide.

Learn the bigger picture in our Email Authentication Explained guide and compare SPF vs DKIM vs DMARC to understand how these protocols work together.

One-Minute Fix

Add include:_spf.google.com to your existing SPF record for the real sending domain, and do not create a new SPF record. Keep one v=spf1 policy only, merge all legitimate providers into that single record, and remove duplicates.

Correct Google Workspace SPF record
DNS TXT
example.com TXT "v=spf1 include:_spf.google.com -all"

This example authorizes only Google Workspace to send mail for example.com and fails all other sources. In real deployments you will often combine Google Workspace with other providers in one merged SPF policy.

Run free check

Free live DNS check. No signup required.

Wrong vs correct setup

Wrong setup

Wrong setup
DNS TXT
example.com TXT "v=spf1 include:spf.protection.outlook.com -all"
example.com TXT "v=spf1 include:_spf.google.com -all"

Here Google Workspace is present, but there are two separate SPF records, so receivers can return SPF permerror instead of a reliable pass/fail result. That ambiguity breaks authentication consistency.

Correct setup

Correct setup
DNS TXT
example.com TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

This merges Google Workspace and Microsoft 365 into one SPF policy so receivers evaluate a single clear authorization record. As long as include:_spf.google.com is in the active merged record, Google Workspace traffic can pass SPF.

Why this happens

Google Workspace setup instructions require adding include:_spf.google.com to the existing SPF policy, not creating another v=spf1 TXT record. SPF supports only one policy per domain, so multiple records cause evaluation errors. Failures are also common when SPF is edited on the wrong domain, syntax is malformed, or DNS propagation is incomplete after updates. This is especially common when multiple SPF records are published or when DNS lookup limits are exceeded.

Why this is a problem

When SPF fails for Google Workspace mail, receivers may treat messages as less trustworthy and apply stricter filtering. Business-critical traffic such as login alerts, invoices, and user notifications can drift into spam or face DMARC-related failures if SPF was expected to support alignment. For many senders the concrete symptom is a syntax error or a record that is too long for DNS to handle cleanly.

How this affects deliverability

SPF is one of the baseline authorization checks providers use before trusting sender infrastructure. If Google Workspace is not correctly represented, legitimate mail can lose trust signals, face higher spam-folder risk, and trigger DMARC alignment problems where SPF was expected to help provide a passing path. You can see this clearly in neutral SPF results or when softfail vs fail decisions tip borderline mail into spam.

Common causes

  • Duplicate SPF records were published instead of one merged SPF policy.
  • include:_spf.google.com was added on the wrong domain or hostname.
  • Recent DNS changes have not fully propagated across resolvers yet.
  • SPF syntax issues (extra spaces, bad mechanisms, or malformed qualifiers) broke evaluation.
  • The tested sending domain differed from the domain where SPF was updated.

What we checked

We looked for one active SPF TXT record on your sending domain that starts with v=spf1 and checked whether include:_spf.google.com is present. If multiple SPF records exist or the include is missing from the effective policy, Google Workspace mail will not authenticate reliably.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

Can I publish one SPF record for Google and another for other providers?

No. SPF allows only one v=spf1 record per domain. If you use Google Workspace plus other services, all mechanisms must be merged into one policy.

What does include:_spf.google.com do?

It tells receivers to evaluate Google’s published SPF authorization and treat those sending IPs as allowed for your domain.

Why is SPF still failing after I added Google include?

The most common causes are duplicate SPF records, publishing on the wrong hostname, DNS propagation delay, or syntax mistakes in the final merged policy.

Next steps

  • Check a real Google Workspace message header to confirm the exact sending domain being evaluated.
  • Update SPF on that domain by adding include:_spf.google.com to the existing v=spf1 record.
  • Merge providers into one SPF record and remove duplicate SPF TXT entries.
  • Validate SPF syntax and wait for DNS propagation across external resolvers.
  • Re-test SPF and verify DMARC alignment after Google Workspace mail passes.
  • Review the full troubleshooting guidance in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues