How to Set Up Google Workspace SPF Records

What is a Google Workspace SPF record?

A Google Workspace SPF record is a DNS TXT record that uses the Sender Policy Framework to tell receiving mail servers which systems are allowed to send email for a domain. In simple terms, it helps a receiving server check whether the sending IP address is authorized to use your domain in the message path.

How Google Workspace Uses SPF

In Google Workspace, the SPF record authorizes Gmail and any other approved sending services to send mail for the domain. If Google Workspace is the only system sending mail, Google’s documented baseline value is v=spf1 include:_spf.google.com ~all. 

That is the actual SPF syntax to publish. Informal versions like spf1 include spfgooglecom, include spfgooglecom, or vspf1 include spfgooglecom are not valid live values on their own.

Why Organizations Should Set Up SPF

Organizations should set up SPF in Google Workspace because it helps reduce domain spoofing by making it harder for unauthorized senders to impersonate the domain. 

SPF does not stop every email threat on its own, but it helps receiving servers evaluate whether a sending source is expected. Google also recommends using SPF with DKIM and DMARC to strengthen authentication and support more consistent email delivery.

How Google Workspace SPF Works

SPF works by comparing a message’s sending source against the live SPF policy published in DNS for the domain. That policy lists Google’s authorized mail infrastructure and any other approved senders, allowing the receiving server to check whether the sending IP address is permitted.

For Google Workspace, the policy typically includes Google’s mail systems through include:_spf.google.com along with any other approved sources. SPF terms are evaluated in order, so the structure of the record matters just as much as the sender list.

The usual results are:

• Pass — The sending IP address is authorized to send email for the domain.
• Fail — The source is not authorized, which can indicate spoofing or a policy gap.
• Softfail — The source is not authorized, but the policy tells the receiver to treat the message as suspicious rather than reject it outright. Google’s standard recommendation for Workspace uses ~all, which produces softfail behavior for non-authorized sources.
• Neutral — The domain does not make a clear assertion about whether the source should pass or fail SPF.
• No SPF record found — No applicable SPF policy is available for that hostname in DNS, so the receiver has no SPF guidance from the domain.

Steps to Set Up Google Workspace SPF

Setting up a Google Workspace SPF record is straightforward when you follow the right order. The key is to identify all approved senders first, then publish and validate one accurate SPF policy.

Step 1: Identify All Email Senders for Your Domain

Start SPF setup with a sender inventory before making any DNS changes. Google Workspace is the core sender, but it may not be the only one. You also need to account for vendors that send mail on behalf of your domain, including:

• Third-party platforms
• Relay services
• Scanners
• Internal apps
• Web forms
• Ticketing tools

This step matters because SPF should reflect your full outbound mail environment. If even one legitimate sender is missing, messages from that source may fail SPF, get flagged as suspicious, or hurt deliverability. In more complex environments, it is worth reviewing both internal systems and external vendors before publishing any change. 

Step 2: Build the Correct Google Workspace SPF Record

After identifying all senders, build one consolidated SPF record. If Google Workspace is the only authorized sender, Google’s recommended value is v=spf1 include:_spf.google.com ~all.  This baseline record authorizes Google’s infrastructure through include:_spf.google.com and applies a softfail to sources that are not approved, making it a clean starting point for domains that send mail only through Gmail.

If other senders exist, they need to be added to the same SPF policy. The main rule is consolidation: a domain should have one SPF policy per hostname, not multiple SPF records. Publishing separate standalone SPF entries for Google Workspace and other platforms can cause SPF validation to fail because receivers do not treat them as separate valid policies.

Step 3: Add the SPF Record to Your DNS

SPF is published as a DNS TXT record through your domain host or DNS provider, not through the Google Admin console. The exact interface depends on the provider, but the process is generally the same: go to your DNS settings, create or edit the TXT entry, place it on the correct hostname, and save the change.

Before publishing, make sure you are updating the correct domain and hostname. Wrong placement is a common source of SPF issues. It is also important to remember that SPF is separate from your MX record, since MX controls inbound mail routing while SPF defines which sources can send outbound mail for the domain.

Step 4: Combine Google Workspace with Third-Party Senders Carefully

Many organizations use Google Workspace for user mail while also relying on other tools to send outbound messages. These can include marketing platforms, ticketing systems, SMTP relays, billing tools, CRM platforms, and multifunction devices.

When those tools exist, they need to be merged into the same SPF policy rather than added as separate SPF entries. This matters even more in larger organizations, where different teams may manage different senders. Without coordination, SPF policies can become incomplete or conflicting, so SPF should be treated as an ongoing maintenance task rather than a one-time DNS change.

Step 5: Check SPF Syntax and Lookup Limits

Once the record is built, the next step is to make sure it is structured correctly and can be processed without errors. That means checking both SPF syntax and DNS lookup usage before treating the setup as complete.

Check SPF Record Syntax

Syntax validation is a required part of SPF setup. A record can include the right sources and still fail if the formatting is wrong. Reviewing SPF record syntax helps confirm that the policy starts correctly, uses only the intended terms, and does not contain errors that break evaluation. 

Each SPF mechanism also needs to be used carefully, since the structure of the record affects how receiving servers process it.

Watch DNS Lookup Limits

Teams also need to watch DNS lookup usage. RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms and modifiers, and going over that limit can return a permanent error. 

This often becomes a problem in larger environments where multiple vendors add nested includes, so it is worth simplifying the record, retiring old senders, and reviewing any inherited SPF logic that no longer reflects real mail flow.

Step 6: Validate That the SPF Record Is Published Correctly

After publishing, verify that the live SPF record is visible in DNS and matches the intended policy exactly. DNS changes can take time to propagate, so saving the update does not always mean the setup is complete.

Teams often use an SPF checker or Google Admin Toolbox tools such as Check MX and Messageheader for this step. The goal is to confirm that the SPF TXT record appears on the correct hostname and matches the value you meant to publish.

Step 7: Test Authentication Results and Troubleshoot Issues

Once the record is live, confirm that SPF is working in practice by reviewing sent message headers or mail logs. Google Admin Toolbox Messageheader can help analyze SMTP headers and surface SPF outcomes in Authentication-Results or Received-SPF lines.

If messages are not passing as expected, start with the most common causes:

• duplicate policies
• syntax errors
• missing third-party senders
• wrong record placement
• DNS publication mistakes

For ongoing visibility into Gmail-facing sending performance, Postmaster Tools can also help by showing dashboards for spam rate, reputation, message authentication, and delivery errors.

Common SPF Record Mistakes to Avoid for Google Workspace

Setting up SPF correctly is not just about adding a DNS entry. It also requires a complete sender inventory, a clean policy structure, and ongoing review as your mail environment changes.

Leaving Out Legitimate Sending Sources

One frequent mistake is forgetting to include all approved sending sources. A domain may have Google Workspace covered but still miss a ticketing platform, marketing tool, scanner, relay, or app that sends as the domain. That kind of gap can create SPF failures even when the main Workspace setup looks correct.

Using Multiple SPF Records

Another common issue is publishing multiple SPF records instead of one consolidated TXT policy. Google Admin Toolbox Check MX warns that there must be no more than one SPF record. If a domain publishes multiple separate policies, SPF evaluation can break.

Creating Syntax and Formatting Errors

Syntax problems also show up often. That includes broken formatting, incorrect qualifiers, invalid mechanisms, wrong hostname placement, or trying to bolt new entries onto an outdated existing SPF record without cleaning it up first. Even small errors in SPF record syntax or a misused SPF mechanism can disrupt authentication.

Allowing an Overly Broad Policy

Overly broad policies are another risk. Allowing too many sources may seem convenient, but it weakens protection by making spoofing easier if one authorized source is compromised or abused. 

SPF should reflect only the systems that truly need to send on behalf of the domain. This matters even more when you are also maintaining a DMARC record, because DMARC misconfiguration can create downstream authentication and delivery problems.

Ignoring Lookup Limits and Edge Cases

There are also technical limits and operational edge cases to account for. The 10-query SPF lookup limit can cause evaluation problems when too many nested includes are stacked together. Forwarding can also break SPF, even when the original sender was properly configured, because SPF evaluates the path used during final delivery rather than the original intent alone.

Treating SPF as a One-Time Task

SPF records should be reviewed regularly. Vendors change, new tools get added, and old services get retired. Google’s guidance explicitly says to update the policy when new mail servers or third-party senders are introduced. That ongoing review helps protect both email deliverability and email authentication as the environment changes.

Getting Google Workspace SPF Setup Right

A Google Workspace SPF record is only as strong as the sender inventory behind it. Identifying every approved mail source before making DNS changes helps prevent gaps that can lead to SPF failures, suspicious message handling, or inconsistent deliverability.

For organizations that want better visibility into sending sources, stronger policy oversight, and more support in reducing email-driven risk, Mimecast can help extend control beyond native setup alone.