Google Workspace SPF Record for B2B Teams: Step by Step, With the Failure Modes

The SPF record for Google Workspace is one line, and Google publishes it verbatim: v=spf1 include:_spf.google.com ~all. Almost nobody gets that wrong. What breaks, reliably, is what happens to that line over the following two years, as a CRM, an invoicing tool, a marketing platform and an outbound sending stack each ask you to add something to it.

Every one of those additions is small. The limits they run into are hard, they are set by the specification rather than by Google, and crossing one turns SPF off completely without any error appearing anywhere.

The record itself

An SPF record is a DNS TXT record on the domain that sends mail. Google's documentation states the constraint that governs everything else: "Each domain can have one SPF record, but the record can specify additional servers and third parties that are allowed to send email from your domain."

One record. Not one per sender. Publishing a second SPF record alongside the first does not add a sender, it makes the domain's SPF evaluation ambiguous, and receivers are entitled to treat the result as an error. When a vendor's onboarding tells you to add an SPF record and you already have one, the correct action is to merge their include: into the record you have.

The mechanisms are worth knowing by name because vendor instructions assume them. v=spf1 must come first. ip4: and ip6: authorise servers by address. include: authorises a third party by domain and is what almost every vendor hands you. a and mx authorise by the domain's own records. And all sets the default for everything not matched.

Google is explicit about where all goes: "This must be the last mechanism in the SPF record. Any mechanism that comes after the all mechanism in an SPF record is ignored." That single sentence explains a whole class of silent failures, because appending a new include: to the end of an existing record puts it after ~all, where it is ignored. The record looks longer, the vendor is not authorised, and nothing reports an error.

Correctv=spf1 include:_spf.google.com include:vendor.example ~all

• New include sits before the all mechanism
• Both senders are authorised
• One record for the domain

Ignoredv=spf1 include:_spf.google.com ~all include:vendor.example

• Anything after all is ignored
• Vendor mail fails SPF
• No error is reported anywhere

AmbiguousTwo separate TXT records, one per vendor

• A domain may publish only one SPF record
• Evaluation can return an error
• Both senders can end up failing

Soft fail or hard fail

Google's own guidance on the final qualifier is measured, and it is the right default for most companies: "When an SPF record includes ~all (soft fail qualifier), receiving servers typically accept messages from senders that aren't in your SPF record, but mark them as suspicious. When an SPF record includes -all (fail qualifier), receiving servers may reject messages from senders that aren't in your SPF record. If your SPF record isn't set up correctly, the fail qualifier might cause more messages from your domain to be sent to spam."

The reason to stay at ~all while you are still discovering who sends as you is contained in that last sentence. Hard fail is a commitment that your record is complete, and most records are not complete on the day they are written. DMARC gives you the evidence to know when it is, which is what aggregate reports are for.

The three limits, and which one you will hit

Ten DNS lookups. Google states it as "Your TXT record for SPF shouldn't include more than 10 references to other domains or servers", and RFC 7208 sets it as an "overall limit of 10 mechanisms/modifiers that cause DNS lookups". Each include: costs at least one, and a vendor's include can itself contain includes that count against your budget. Cross the limit and evaluation returns permerror, which means SPF contributes nothing at all. This is the limit that catches most companies, and our page on the ten-lookup limit and multi-domain sending covers counting and fixing yours.

255 characters in a string. Google's documentation states that "SPF records can have up to 255 characters." A record longer than that has to be published as multiple concatenated strings, and DNS panels differ on whether they do that for you or truncate.

512 bytes for the record. Google adds that "The TXT record file size should be no larger than 512 bytes." Well before you get there, a record that long is a sign the domain is authorising more senders than any one domain should.

Before you edit the SPF record again

• ✓Yes: There is exactly one SPF record on this domain
• ✓Yes: The new include sits before the all mechanism
• ✓Yes: The lookup count after this edit is still under ten
• ✓Yes: You know which senders in the record are still in use
• ✕No: A vendor asked for a second SPF record and you added one

Publishing it, and the three things that go wrong at the DNS panel

The record goes on the domain that appears in your From address, as a TXT record with the host set to the domain itself rather than to a subdomain. Google's setup guidance for records of this kind notes that providers differ here: "Some domain providers populate your domain name automatically. If not, manually enter your domain." Getting that wrong publishes the record at a name nothing queries, which presents exactly like having no record.

The second is the one nobody checks. A domain registered with one company and resolved by another has two DNS panels, and only the one the nameservers point at is live. Editing the wrong one produces a record you can see and no receiver can. Confirm the nameservers before editing anything, particularly on domains bought in bulk where the defaults may not match your main domain.

The third is impatience. A record has a time-to-live, and the previous answer can be served until it expires. Checking thirty seconds after saving tells you almost nothing, and a failed check at that point tempts people into a second edit that creates the duplicate-record problem above.

After the record is live, verify it from outside the panel. Query the domain's TXT records and read what actually comes back, then send a message to an account you control and read the Authentication-Results header, which states whether SPF passed and for which domain. The MXToolbox deliverability guide covers the lookups worth running.

What Google Workspace does not cover

The _spf.google.com include authorises Google's servers to send for your domain. It says nothing about anything else, and two cases catch people out.

Mail sent through a third party using your From address is not covered by Google's include, even when the third party is connected to your Workspace account. Anything sending as you needs its own authorisation in the record.

And SPF authorises the envelope sender rather than the visible From address, which is why an SPF pass alone does not satisfy DMARC. DMARC requires alignment between the domain SPF checked and the domain your recipient sees, and RFC 9989 narrowed that further: DMARC "relies solely on SPF validation of the MAIL FROM identity", with no fallback. Our guide to SPF, DKIM and DMARC together shows how the three records interlock.

The outbound-specific part

Teams running B2B outbound usually send from domains separate from the main company domain, and that architecture solves the SPF problem almost by accident.

A dedicated sending domain authorises one or two senders, so its lookup count stays in single figures for its whole life. The primary company domain, which accumulates a sender every time a department buys software, is the one that reaches ten. Keeping outbound off it protects both.

The trade is that each sending domain is a real domain needing its own records, with no inheritance from the parent. That is thirty SPF records for thirty domains, plus DKIM and DMARC on each. Email sending limits by provider covers what Google Workspace itself allows per account, which is the other constraint shaping how many domains and mailboxes a programme needs.

We authenticate every domain before it sends anything and run one message per campaign, so a domain failing SPF does not get a second attempt at the same person under a different pretext. Getting the record right is launch work. It is also why we maintain more sending infrastructure than a campaign consumes, so a domain with a problem is replaced rather than repaired while it is live.

If you would rather not maintain DNS across a portfolio, we run the sending stack as part of the engagement.

Parked domains deserve a mention while you are in the DNS panel, because they are the cheapest win available. A domain that sends no mail at all should say so, and Google's documentation gives the pattern for it: an SPF record authorising nothing, so a receiver has an explicit statement that no server is entitled to send as that name. Defensive registrations and old brand domains are a standing spoofing surface otherwise, and they cost one record each to close.

The short version

Publish v=spf1 include:_spf.google.com ~all, one record per domain, and merge every later vendor into that same record rather than adding another. Keep new includes in front of the all mechanism, because anything after it is ignored silently. Watch the ten-lookup budget, which is the limit you will actually hit. Stay on soft fail until DMARC reports tell you the record is complete, and keep outbound on separate sending domains so the primary domain never has to carry every sender you have ever bought.

Vendor guidance verified as of August 2026 against Google Workspace's published SPF documentation, and specification behaviour against RFC 7208 and RFC 9989. Verify current terms with the vendor before relying on them.