Setting up SPF for Google Workspace — Step-by-Step Guide (2026)

Last updated: July 2026

In short: After this guide your domain publishes a correct SPF record for Google Workspace — including combined records for newsletter services and CRM.

Prerequisites

A Google Workspace account with your own domain
Access to your domain’s DNS management — which is not at Google, but at your domain host

What is SPF?

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS. It lists which mail servers are allowed to send email with your domain as the sender. Receiving servers use the entry to check whether a message comes from an authorized server. Without SPF, any server can send mail in your name — and your legitimate mail lands in spam faster.

Google now makes this a hard requirement: senders of bulk email (more than 5,000 messages a day) must have SPF, DKIM, and DMARC set up, otherwise Gmail no longer reliably accepts their mail.

The starting point at Google Workspace

As with Microsoft 365: there’s nothing to do for SPF in the Google Admin console. The record is entered at the domain host — that is, where your DNS zone lives. How that works in each case is shown in our guides for IONOS, Strato, All-Inkl, Netcup, and Hetzner DNS.

Two notes from Google’s own docs: SPF may already be set up for your domain (e.g. if you registered the domain through a Google partner) — so check first, then change. And the record should contain all servers that send for your organization, not just Google.

Step-by-step guide

1. Check whether SPF is already active

Fastest via the terminal:

dig TXT example.com +short | grep spf1

Alternatively, drop your domain into the free MXAudit scanner — it checks the record for syntax and lookup limits at the same time.

2. Determine the record

Only Google Workspace sends (the normal case):

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

The include now points to a flat list of Google IP ranges (IPv4 + IPv6) and costs exactly one DNS lookup. Older guides still circulate the nested _netblocks includes — you no longer need to enter those.

Do other services send too? Google documents the combination itself, all sources in one record — e.g. with Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

With Salesforce:

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

Or running in parallel with Microsoft 365:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

3. Enter the record at the domain host

Log into your domain host and create the value as a TXT record on the main domain (host @) — or update the existing v=spf1 entry. There may be only one SPF record per domain.

4. Consider subdomains

According to Google, every subdomain that sends needs its own SPF entry — the main domain’s record doesn’t apply automatically.

5. Wait until the change is live

DNS changes take time: depending on TTL and caching it can take a few hours until every server worldwide sees the new record.

The components in detail

Component	Meaning
`v=spf1`	version identifier, always at the start
`include:_spf.google.com`	allows the Google sending infrastructure (flat IPv4/IPv6 list, 1 lookup)
`include:` (additional)	allows external services — 1 additional DNS lookup each
`~all`	softfail: Google’s default recommendation in the example record

An interesting contrast: Google shows ~all in all examples, while Microsoft recommends -all for 365 domains. Both are defensible — with clean DKIM and DMARC (which Google requires for bulk senders anyway) the all choice matters less, because DMARC takes over enforcement.

Verify the result

Check your configuration with the free MXAudit scanner — it shows immediately whether your SPF record is syntactically correct and how many DNS lookups it consumes (the limit is 10).

Or directly in the terminal:

dig TXT example.com +short | grep spf1

The output must contain exactly one record with v=spf1.

Common mistakes

Created a second SPF record instead of extending the existing one. Many domains already have a host record. The Google include belongs in it — two v=spf1 entries cause a permerror.

Not all senders captured. Google’s docs are clear: the record should contain the servers of all sending systems — CRM, invoicing tool, ticketing system. Whatever’s missing gets sorted out at the recipient.

Outdated _netblocks includes. Old guides list Google’s internal netblock records individually. Unnecessary: include:_spf.google.com suffices and stays current when Google changes its IP ranges.

Forgot subdomains. Every sending subdomain needs its own SPF entry.

+all at the end. A +all allows any server to send and makes the whole record useless — don’t copy it.

Forwarding fails. If a recipient auto-forwards your mail, SPF often fails at the final recipient — the forwarding server isn’t in your record. That’s a design weakness of SPF, not a configuration error; DKIM and DMARC catch this case.