Back to Learning CenterEmail Authentication

How do I set up SPF for Google Workspace?

By Samuel ChenardJuly 10, 20267 min read
How do I set up SPF for Google Workspace?

To set up SPF for Google Workspace, add a single TXT record at your domain's root with the value v=spf1 include:_spf.google.com ~all, published through your DNS host — not the Google Admin console. That one include authorizes every Google server that sends your mail. If other services send on your behalf, merge their mechanisms into the same record rather than publishing a second one, because a domain can only have one valid SPF record. Allow up to 48 hours for the record to take effect.

Quick Takeaways

  • The Google Workspace SPF record is v=spf1 include:_spf.google.com ~all, published as a TXT record.
  • Add it at the root of your domain — enter @ in the host/name field, or leave it blank if your DNS panel appends the domain automatically.
  • SPF is configured at your DNS provider (Cloudflare, GoDaddy, Namecheap, and so on), not inside the Google Admin console.
  • A domain may have only one SPF record. If you already have one, add include:_spf.google.com to it instead of creating a second.
  • ~all (softfail) is Google's recommended default; -all (hardfail) is stricter but riskier while you are still finding every sender.
  • SPF alone does not satisfy Google and Yahoo's sender rules — you also need DKIM and a DMARC policy.

What is the correct SPF record for Google Workspace?

For a domain that sends mail only through Google Workspace, Google's documentation specifies exactly one record:

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

Each part earns its place:

  • v=spf1 declares the record as SPF version 1. Every SPF record starts this way.
  • include:_spf.google.com tells receivers to also trust the IP ranges Google publishes for Workspace. That single include expands, behind the scenes, to Google's full set of sending servers, so you never have to list individual IP addresses.
  • ~all is a softfail: mail from any server not covered above should be accepted but marked as suspicious. Google recommends softfail so that a missed sender degrades gracefully instead of bouncing outright.
SPF works by letting the receiving server look up this record and check whether the server that delivered the message is on your authorized list. If it is, SPF passes. Google Workspace SPF record card showing a single-sender TXT record and a merged multi-sender example, both at the domain root. Publish one SPF record at the root — merge extra senders instead of adding a second record.

Where do you add the SPF record — Admin console or DNS?

At your DNS host, not in Google's Admin console. This trips up a lot of first-time admins: Google verifies and reports on your authentication inside the console, but the SPF record itself is a public DNS entry that lives with whoever manages your domain's zone.

  1. Sign in to your DNS provider (your domain registrar or wherever your nameservers point).
  2. Open the DNS records / zone editor for the domain.
  3. Create a new record with these fields:
Type:  TXT
Host:  @        (or leave blank for the root domain)
Value: v=spf1 include:_spf.google.com ~all
TTL:   3600     (one hour is fine)
  1. Save, then wait for propagation. Google notes changes can take up to 48 hours to take full effect, though most resolvers update far sooner.
If your panel requires the value in quotes, wrap it: "v=spf1 include:_spf.google.com ~all". Do not split it across multiple TXT strings unless it exceeds 255 characters — the Google-only record is well under that.

How do you merge Google with other senders?

The rule that breaks the most setups: one SPF record per domain. A second v=spf1 TXT record does not add senders — it makes SPF ambiguous, and receivers treat the result as a permerror, failing both records.

So if you send through Google Workspace and another platform — a marketing tool, a help desk, a transactional relay — combine every mechanism into one record. The order is: v=spf1, then all the include/ip4/ip6 mechanisms, then a single all at the end.

v=spf1 include:_spf.google.com include:servers.example-esp.com ip4:198.51.100.20 ~all

Note that _spf.google.com is not a single DNS lookup. It nests several further includes for Google's IP blocks, so it consumes multiple of the ten lookups SPF permits. Stack a few more third-party includes on top and you can quietly cross the limit — which is the subject of the most common failure below. When you send bulk mail through a separate provider, giving that provider its own subdomain (the pattern we walk through for Mailgun and Amazon SES) keeps your root SPF record short and your reputations separate.

How do you verify the record is working?

Do not trust your DNS panel's preview — query what public resolvers actually return. Palisade's free SPF checker parses the record, counts DNS lookups, and flags syntax errors in one pass; the DNS lookup tool shows the raw TXT value exactly as receivers see it, which catches typos and propagation lag.

You can also confirm end-to-end by sending a message to any Gmail address you control, opening the message, and choosing Show original. A healthy result reads SPF: PASS with your domain next to it. If it says softfail or none, the record has not propagated or the sending server is not covered.

Common issues with Google Workspace SPF

SPF still shows softfail or none after you added the record

Almost always propagation or a host-field mistake. Wait out the TTL, then verify from outside your network. The frequent typo: entering the full domain in the host field when the panel already appends it, producing yourdomain.com.yourdomain.com. If a lookup on the bare domain returns nothing, check for this double-domain first.

PermError: too many DNS lookups

SPF allows a maximum of ten DNS lookups when a receiver evaluates the record. Because _spf.google.com already uses several, adding multiple other include: mechanisms can push you over ten, and receivers return a permerror that fails SPF entirely — even though every sender is legitimate. Flatten or consolidate: remove services you no longer use, move a bulk sender to its own subdomain, or use a lookup-count check to see where you stand. Our guide to why phishing passes SPF and DKIM explains why a permerror is worse than it looks — it can leave you with no working authentication at all.

You accidentally have two SPF records

Two v=spf1 TXT records on the same host invalidate each other. Delete one and merge its mechanisms into the survivor. Watch for a hidden second record left over from a previous email provider — old include: values for a service you migrated away from are safe to remove.

Mail passes SPF but still lands in spam

SPF is necessary, not sufficient. Google and Yahoo also want a valid DKIM signature and a DMARC policy, plus a clean sending reputation. Turn on DKIM in the Admin console (Apps → Google Workspace → Gmail → Authenticate email), publish a DMARC record, and check your domain reputation. SPF fixes authorization; it does not fix a poor reputation.

Frequently asked questions

Should I use ~all or -all for Google Workspace?

Start with ~all (softfail), which is Google's recommendation. It authenticates your Google mail while treating unlisted senders as suspicious rather than forged, so a sender you forgot to add is flagged, not hard-rejected. Move to -all (hardfail) only once you are certain every legitimate source is in the record.

Do subdomains need their own SPF record?

Yes. SPF is not inherited by subdomains. If a subdomain like mail.yourdomain.com sends mail, it needs its own SPF record. A subdomain that never sends mail is best protected with an empty policy (v=spf1 -all) so it cannot be used to spoof you.

Does setting up SPF alone stop spoofing?

No. SPF authorizes servers, but it checks the hidden envelope sender, not the From address your recipients see — so on its own it does little against display-name spoofing. Only DMARC, which ties SPF and DKIM back to the visible From domain through alignment, closes that gap.

Is SPF enough to meet Google and Yahoo's sender requirements?

No. Both require SPF and DKIM, plus a DMARC policy of at least p=none with alignment for bulk senders. SPF is one of three pieces, not the whole checklist.

Palisade automates that whole checklist for the domains you manage — it generates the correct SPF, DKIM, and DMARC records, watches your reports for senders you missed, and warns you before a lookup-limit or alignment problem turns into blocked mail. Run your domain through the free Email Security Score tool to see where Google Workspace SPF sits today and what else Google and Yahoo expect.

Share this article

Samuel Chenard

Written by

Samuel Chenard

CEO & Co-Founder, Palisade

Samuel Chenard is the CEO and co-founder of Palisade, the DMARC automation platform for MSPs. He writes Palisade's guides on DMARC, SPF, DKIM and email deliverability.

More from Samuel

Related articles