Google Workspace SPF record: setup and verification

The current Google Workspace SPF record is:

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

Publish it as a TXT record at the root domain when Google Workspace is your only sender:

Field	Value
Type	TXT
Host / Name	@
Value	v=spf1 include:_spf.google.com ~all

That value comes from Google’s current SPF setup documentation. We verified it in August 2026. The same value applies when an older configuration or search result calls the service G Suite.

From the DMARC reports we process, the Google record is rarely the difficult part. The common failure is an old second SPF record or a third-party sender that uses the same From domain but was never added or authenticated with DKIM.

Before you start

You need DNS access for the domain in your From address. For example, if users send as [email protected], update DNS for example.com.

You also need a sender inventory. Google Workspace might be your mailbox provider, but your domain may also send from Stripe, HubSpot, Mailchimp, Zendesk, Salesforce, SendGrid, or an invoicing system. SPF is one record, not one record per vendor.

Run your domain through the DMARCTrust domain checker before editing DNS. If an SPF record already exists, edit it instead of creating a second one.

Step 1: check for an existing SPF record

In your DNS provider, look for TXT records at the root domain, usually shown as @.

If you see a TXT value that starts with v=spf1, that is your SPF record. Keep it and edit the value. Do not add another SPF TXT record.

Two SPF records return PermError. Edit the existing record.

Step 2: publish the Google Workspace SPF value

If Google Workspace is your only sender, add or edit this TXT record. Our SPF record generator builds the value for you and counts DNS lookups so you stay under the limit:

Field	Value
Type	TXT
Host / Name	@
Value	v=spf1 include:_spf.google.com ~all
TTL	Default

Some DNS providers want the host to be blank instead of @. Use the format your DNS provider expects.

Google recommends ~all in its examples. A hard fail (-all) can be reasonable later, but use it only after you know every sender is covered.

Step 3: merge other senders into the same record

If another service uses this domain as its SPF identity, merge that provider’s documented mechanism into the same SPF value. Do not add a provider only because it appears in the visible From address.

For example, Google Workspace plus Microsoft 365:

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

For SendGrid, inspect the return-path first. Current SendGrid domain authentication normally uses a dedicated branded subdomain. See the SendGrid SPF guide before adding include:sendgrid.net at the root.

Google Workspace plus Zendesk:

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

Keep the full evaluation within SPF’s 10 DNS-querying-term limit. This is not only a count of visible include: terms. Nested includes, a, mx, redirect, and exists can also consume the limit.

Step 4: verify SPF

Run the domain through our SPF checker: include:_spf.google.com brings its own nested lookups into the count, and the checker shows exactly how much headroom is left against the limit of 10 before your next sender tips the record into permerror.

DNS changes can take time to propagate. Google’s docs say SPF authentication can take up to 48 hours to start working.

Use the DMARCTrust domain checker to confirm:

• There is exactly one SPF record.
• The record includes _spf.google.com.
• The lookup count is below 10.
• The syntax starts with v=spf1.

Then send a test email from Google Workspace to a Gmail or Outlook mailbox and inspect the authentication results. SPF should pass for mail sent through Google.

Common mistakes

Adding a second SPF record. SPF must be one TXT record. Merge Google into the existing record.

Putting SPF on the wrong host. For normal Google Workspace mail from example.com, publish SPF at @, not _spf, _dmarc, or mail.

Forgetting non-Google senders. Google Workspace does not cover your CRM, helpdesk, marketing platform, or payment provider.

Assuming SPF is enough for DMARC. SPF must align with the visible From domain for DMARC. Forwarding and third-party tools often make DKIM the more reliable path.

What about DKIM and DMARC?

Google says bulk senders need SPF, DKIM, and DMARC. SPF is only one path. Set up Google Workspace DKIM so Gmail signs mail with your domain.

SPF passing is not enough for DMARC. The envelope sender domain must align with the visible From domain. Check a real delivered message, not only the DNS record.

After SPF and DKIM are working, publish a DMARC record with reporting:

v=DMARC1; p=none; rua=mailto:[email protected];

Use the DMARC generator to create the record and add your DMARCTrust reporting address.

FAQ

What is the SPF record for Google Workspace?

For a domain that sends only with Google Workspace, use v=spf1 include:_spf.google.com ~all.

Should I use gmail.com in my SPF record?

No. For Google Workspace custom domains, use _spf.google.com.

What is the G Suite SPF record?

Use the current Google Workspace value: v=spf1 include:_spf.google.com ~all. Do not copy an old Google Apps hostname from a legacy guide.

Can I have Google Workspace and SendGrid in the same SPF record?

Only when SendGrid instructs you to publish include:sendgrid.net at the same hostname. Current SendGrid domain authentication usually places SPF on a branded return-path subdomain. Publish the generated SendGrid records instead of adding the include to the root by default.

How do I know SPF is working?

Check your domain with DMARCTrust, then inspect a test message’s authentication results. SPF should pass for mail sent through Google Workspace.