SPF Record for Gmail That Actually Works in 2026

Do not index

A Google Workspace campaign can look perfect in the editor and still collapse into Spam the moment a third-party sending platform is added. Reply rates fall, conversions disappear, and the domain owner often blames content or reputation before checking the DNS record that Gmail evaluates first.

The correct SPF record for Gmail is usually:

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

For a Google Workspace-only domain, publish that value as one DNS TXT record at the root of the domain. If other services send mail for the domain, merge their authorized mechanisms into the same record, keep the complete evaluation path at or below 10 DNS-querying terms, and verify the result in Gmail headers.

Table of Contents

Why Your Gmail Senders Are Landing in Spam The SPF Record Google Workspace Actually Wants Reading the record from left to right The One SPF Record Rule That Breaks Most Domains Adding Third-Party Senders Without Hitting the 10-Lookup Limit Count the complete evaluation path Flatten only with change control Softfail or Fail for Google Workspace Senders Why softfail is safer during discovery When hardfail becomes reasonable Verifying Your SPF Record After the Change Run the DNS and lookup checks Inspect a real Gmail header Common SPF Mistakes on Google Workspace Domains and What Comes Next

Why Your Gmail Senders Are Landing in Spam

A Workspace administrator often discovers the problem after connecting a marketing platform or outbound system. Messages sent from Gmail may still appear normal, while messages from the new platform begin landing in Spam. The campaign content hasn't changed, but the authentication path has.

Gmail evaluates several signals when handling an incoming message. The receiving system examines the SMTP conversation, including the HELO identity, then checks SPF, DKIM, and DMARC before weighing sender reputation, complaints, engagement, and content. A malformed or incomplete SPF record can undermine that first authentication signal before the message's copy gets meaningful consideration.

The most common Workspace failure isn't an exotic blacklist event. It is a duplicated SPF record, an incorrect sender include, or a PermError caused by excessive DNS lookups. These mistakes often appear after a team adds a new sender without reviewing what already exists in DNS.

SPF doesn't operate alone. DKIM supplies a signature, and DMARC uses authentication results and alignment to apply a domain policy. Google requires bulk senders, meaning domains sending 5,000 or more messages per day to Gmail addresses, to use SPF and DKIM, publish DMARC with at least p=none, keep spam complaints below 0.3%, and provide one-click unsubscribe for marketing messages. These requirements were announced in October 2023 and enforced starting in February 2024, as documented in Gmail's sender requirements.

By reading the record, identifying every authorized sender, and checking the lookup path, a domain administrator can determine whether Gmail is likely to receive a valid SPF result from the next message.

The SPF Record Google Workspace Actually Wants

For a domain that sends only through Google Workspace, Google documents this SPF value:

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

Publish it as a DNS TXT record for every domain used to send mail. The host or name is commonly the root symbol used by the DNS provider, although each provider labels that field differently.

Reading the record from left to right

v=spf1 tells the receiving server that the TXT value uses SPF version 1 syntax. It must appear at the beginning of the record.

include:_spf.google.com delegates authorization to Google's published SPF policy. It isn't a list of manually maintained Google IP addresses. The receiving server follows that delegation and evaluates the mechanisms Google publishes for its outbound Workspace infrastructure.

~all applies to senders that don't match an authorized mechanism. The tilde means softfail, so the receiving server can treat an unauthorized source as suspicious without the domain requesting outright rejection. Google documents this Workspace-only value and also notes that SPF records can be up to 255 characters, that the TXT record file should be no larger than 512 bytes, and that the record shouldn't contain more than 10 references to other domains or servers in the relevant evaluation path. See SPF, DKIM and DMARC explained for the relationship between these authentication layers.

A Google-only domain doesn't need to add unrelated provider records. Adding mechanisms for services that never send mail creates unnecessary complexity and consumes lookup capacity.

The record belongs in DNS, not in the Google Admin console. Google Workspace sends through the authorized Google infrastructure, but the domain owner publishes the policy wherever the domain's DNS is managed.

The One SPF Record Rule That Breaks Most Domains

Publishing a second SPF record feels logical when a new sending service is introduced. It is also one of the fastest ways to make SPF fail.

A domain must have one SPF record, meaning one TXT entry beginning with v=spf1. Two separate SPF policies don't combine automatically. A receiving server can return a PermError when it finds multiple applicable SPF records, so neither Google Workspace nor the additional service gets a reliable authorization result.

Configuration	Example	Gmail Result
Valid Google-only record	`v=spf1 include:_spf.google.com ~all`	Google Workspace is authorized
Broken duplicate setup	`v=spf1 include:_spf.google.com ~all` plus `v=spf1 include:mail-service.example ~all`	SPF evaluation can return PermError
Valid merged setup	`v=spf1 include:_spf.google.com include:mail-service.example ~all`	One policy evaluates all listed senders

The repair is straightforward, but it must happen in the existing record. Identify the policy that belongs at the root, add each legitimate sender's approved mechanism to that single line, then remove the duplicate v=spf1 entry.

The problem isn't solved by placing the records in the same DNS panel, using similar TTL values, or copying one policy beneath the other. Receivers don't interpret separate SPF records as a combined allowlist.

This matters beyond the authentication report. If Gmail sees an SPF error, messages can receive a negative filtering signal, and mail from a legitimate campaign may miss the inbox. That costs more than a technical cleanup, because missed messages reduce responses, conversions, and confidence in the sending brand.

Adding Third-Party Senders Without Hitting the 10-Lookup Limit

A Google Workspace domain may send from marketing automation, transactional email, customer relationship systems, support platforms, and outbound tools. Each service can introduce another authorization path, and the record that looks correct at a glance can still fail after DNS expansion.

Add only approved mechanisms to the existing Google policy:

v=spf1 include:_spf.google.com include:marketing.example include:transactional.example ~all

The names above are placeholders. Use the mechanisms supplied by services that send mail for the domain, and keep them on the same SPF record.

Count the complete evaluation path

The SPF ceiling applies to the entire evaluation path, including nested include statements. Under the SPF specification, one SPF evaluation permits 10 DNS-querying mechanisms or modifiers. The count includes include, a, mx, ptr, exists, and redirect. ip4, ip6, and all do not perform DNS lookups and do not count toward that limit.

An include may appear as one term in the visible TXT record while expanding into several queries. If the full path exceeds the ceiling, the receiver can return PermError, so SPF fails even though the record exists.

Setup	Typical Includes	Lookup Impact	Action
Workspace only	Google authorization	Depends on expansion	Inspect the full path
Workspace plus one sender	Google and one approved service	Depends on the provider	Check before publishing
Workspace plus several senders	Google and multiple service policies	May approach the ceiling	Simplify or flatten if needed

Provider policies can change. A record that passes today may exceed the limit after a nested mechanism is added, so count the expanded path rather than the visible include terms.

Flatten only with change control

Flattening replaces provider include statements with direct ip4 and ip6 mechanisms. That reduces DNS queries, but it also turns a maintained delegation into an address list your team must update. If the list becomes stale, it can authorize retired infrastructure or omit a provider's new sending range.

Use this process:

Inventory every system that sends with the domain.

Add only mechanisms documented by those services.

Count nested lookups, not just visible include terms.

Flatten when the expanded path is approaching the ceiling.

Recheck after any provider or infrastructure change.

A neutral DNS analysis service can expose the expansion and identify syntax or lookup problems. It cannot determine whether an unfamiliar sender still operates in the business. That decision requires an ownership review of the sending stack.

Softfail or Fail for Google Workspace Senders

The final qualifier controls how receiving systems interpret a sender that doesn't match the authorized mechanisms. The two practical choices for Workspace domains are ~all and -all.

~all is a softfail. It signals that an unmatched sender isn't authorized, while allowing the receiving system to apply its own treatment. -all is a hard fail. It states that unmatched senders aren't authorized and can be rejected.

Google's documented Google-only example ends with ~all, which makes it the sensible starting point while a domain owner is still discovering legitimate sending paths. A migration can involve old relays, forgotten applications, or a newly adopted platform that hasn't yet been added to the inventory.

Qualifier	Gmail Treatment	Recommended For
`~all`	Marks unmatched sources as suspicious and leaves final handling to Gmail	New or changing Workspace configurations
`-all`	Declares unmatched sources unauthorized and supports rejection	Audited, stable sending infrastructure
`+all`	Authorizes every sender	Never appropriate for a production domain
`?all`	Makes no useful authorization assertion	Not appropriate as a production posture

Why softfail is safer during discovery

A softfail doesn't make an unauthorized message legitimate. It gives the receiver a negative signal while reducing the chance that a legitimate transitional sender is explicitly rejected because the inventory is incomplete.

That distinction matters when a domain has recently moved systems. An old billing application may still send receipts, or a form handler may use the domain without appearing in the marketing team's vendor list. With ~all, those messages can expose the gap for investigation. With -all, they may fail more decisively.

When hardfail becomes reasonable

A domain can move to -all after its owner has:

Documented every legitimate sending service.

Confirmed each service's authorization mechanism.

Checked nested lookups.

Tested Gmail authentication headers.

Reviewed authentication results through a stable operating period.

The hardfail posture is stricter because it turns an incomplete inventory into a delivery problem. It also gives receiving systems a clearer instruction when an unauthorized server attempts to send as the domain.

The record examples make the difference obvious:

Record	Problem or strength	Likely consequence
`v=spf1 include:_spf.google.com ~all`	Valid Google Workspace starting policy	Unmatched sources receive a softfail
Two separate TXT entries, one for Google and one for a marketing service	Duplicate SPF policies	SPF can return PermError
`v=spf1 +all`	Every sender is authorized	SPF provides no meaningful protection
`v=spf1 include:_spf.google.com include:marketing.example include:transactional.example -all`	One merged policy with explicit senders	Unlisted sources receive a hardfail

The last example is production-ready only if the mechanisms are real, approved, and within the lookup limit. The qualifier can't compensate for an incomplete sender inventory.

Verifying Your SPF Record After the Change

Publishing a TXT record does not prove that Gmail can authenticate your messages. Verification must confirm that the policy is visible, unique, syntactically valid, complete, and effective on a real message.

Run the DNS and lookup checks

Query the root domain with the administrator's command-line DNS utility, or use the DNS provider's lookup function. Check each point:

Only one TXT value begins with v=spf1.

The Google mechanism authorizes Workspace sending.

Every additional mechanism belongs to an approved sender.

The qualifier reflects the intended policy.

The DNS interface has not split, truncated, or altered the value.

Then trace the complete include chain. SPF permits 10 DNS-querying terms, and nested policies consume that same allowance. A record that looks short in DNS can still fail when its includes expand. Breaker's guide to SPF explains the record structure and lookup constraint in more detail.

Inspect a real Gmail header

Send a controlled message from Google Workspace to a Gmail mailbox. Open the message's original source and find the Authentication-Results header. A healthy result resembles:

Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass

Header syntax varies by receiving system. Verify the authentication result itself, rather than treating a public DNS lookup as proof that delivery authentication works.

Before closing the change, confirm a rollback path, inspect every mechanism for typographical errors, and test each sending application. MailAdept's spf checker can identify published-record and lookup issues, but it cannot replace header review. SPF depends on the actual envelope sender and sending IP.

If SPF passes while DKIM or DMARC fails, investigate those authentication paths separately. Header inspection confirms whether the record works in practice, not just in DNS.

Common SPF Mistakes on Google Workspace Domains and What Comes Next

Five errors appear repeatedly during Workspace reviews.

Duplicate policies are the most damaging. An administrator adds a second TXT value for a marketing service instead of merging it into the Google record. Receivers can return PermError, and legitimate messages lose an authentication signal.

Incorrect formatting is less dramatic but just as real. Quoting the value incorrectly, breaking mechanisms across unsupported entries, or placing text in the wrong DNS field can make the published policy differ from the intended one.

Unrelated provider mechanisms create false confidence. A record intended for another mail platform doesn't authorize Google Workspace. Copying a provider's example without mapping it to the actual sending infrastructure leaves the domain's real messages unauthenticated.

Excessive lookup depth appears after several services are added. Nested includes consume the same protocol budget, and exceeding the limit produces PermError rather than a partial pass.

An unsafe qualifier can erase the security value of the record. +all authorizes every sender, while ?all makes no useful policy assertion. Neither belongs on a production Workspace domain.

SPF is only one part of domain authentication. After the record is stable, the logical next work is DKIM signing in Google Admin, then DMARC reporting with a policy beginning at p=none where appropriate, followed by a measured move toward stricter enforcement. Each layer helps receivers distinguish authorized mail from spoofed mail, protect sender reputation, and reduce the revenue loss that follows when legitimate campaigns disappear into Spam.

MailAdept combines subscription-based deliverability consulting with AI agents and human experts who review authentication, sending sources, and inbox failures. For a Google Workspace domain with recurring SPF errors, a Mailadept review can identify duplicate records, unauthorized senders, and lookup-limit risks before they disrupt campaigns.