SPF setup guide for Google Workspace (2026)
I audited a Workspace setup last year where the founder had been on Google Workspace for two years, paying for it, using it every day, and wondering why their cold outreach was not getting replies. The domain had no SPF record. It had never had one. Google Workspace does not add SPF automatically when you set up your account.
That surprised him. It surprises most people. The assumption is that once you pay for a Google service, Google takes care of the deliverability. Google does not take care of SPF. You add it to your own DNS. Google publishes the record you need. You publish it. That is the arrangement.
The record itself takes about two minutes to add. What takes longer is understanding what you are doing and why, so you do not make the mistake of having two SPF records, or forgetting to include a third-party tool you added six months ago, or wondering six months from now why a new sending tool's emails are going to spam.
Key takeaways
- ✓Google Workspace does not add an SPF record to your DNS automatically; you must add it yourself
- ✓The official Google Workspace SPF record is v=spf1 include:_spf.google.com ~all
- ✓You can only have one SPF record per domain; a second one breaks both
- ✓If you use any third-party email tools (CRMs, marketing platforms, cold email sequencers), they need to be included in your SPF record too
- ✓SPF alone is not enough; you also need DKIM and DMARC for full email authentication in 2026
- ✓Google and Yahoo made SPF mandatory for bulk email senders in February 2024
- ✓A missing or broken SPF record is one of the most common causes of legitimate Gmail emails landing in spam
On this page
- 1.What is SPF?
- 2.Why Google Workspace needs SPF
- 3.How SPF works
- 4.Google Workspace SPF record example
- 5.Before you add SPF
- 6.Step 1: Check for existing SPF records
- 7.Step 2: Add SPF record to DNS
- 8.Step 3: Verify SPF is working
- 9.Common SPF errors
- 10.SPF soft fail vs hard fail
- 11.Google Workspace and third-party email tools
- 12.SPF best practices for 2026
- 13.One-minute SPF audit
- 14.Quick answers
- 15.Frequently asked questions
What is SPF?
SPF (Sender Policy Framework) is a DNS record that lists every mail server and IP address authorized to send email on behalf of your domain. When an email arrives at a receiving mail server claiming to be from your domain, the server looks up your SPF record and checks whether the sending IP is on the list. If it is, SPF passes. If it is not, SPF fails.
SPF exists because anyone can technically send an email claiming to be from any domain. Without SPF, there is no mechanism for a receiving server to verify whether an email from yourname@yourdomain.com actually came from a server you control. With SPF, the receiving server can check your published list and make a more informed decision.
The analogy that works: SPF is a guest list at the door. Your domain is the venue. When an email shows up claiming to be from your domain, the receiving server is the bouncer checking the list. If the sending server is on the list, it gets in. If not, it gets flagged or turned away, depending on your policy.
SPF does not encrypt email. It does not prove the email content was not modified. That is what DKIM does. What SPF specifically does is authorize the sending server. The two records work together, and DMARC ties them both to a policy and reporting layer. For Google Workspace, SPF is the starting point.
Why Google Workspace needs SPF
Without an SPF record, your Google Workspace emails look identical to potentially spoofed emails at the receiving server. Gmail and Outlook cannot tell the difference. They treat no-SPF emails with suspicion, and that suspicion shows up as spam folder placement.
Direct answer
Google Workspace requires SPF for reliable inbox placement. Without it, your emails fail a basic authentication check that Gmail, Outlook, and Yahoo Mail run on every incoming message.
| Without SPF | With SPF (v=spf1 include:_spf.google.com ~all) |
|---|---|
| Receiving servers cannot verify sending IP is authorized | Receiving servers confirm Google's servers are authorized to send for your domain |
| Emails treated as potentially spoofed | Emails pass first-level authentication check |
| Google/Yahoo bulk sender requirements not met | Meets SPF requirement for bulk senders |
| Higher spam filter scores | Lower spam filter scores at baseline |
| Domain vulnerable to IP spoofing | Unauthorized servers fail SPF check |
| Cold email tool emails may fail SPF if using your domain | All authorized tools pass SPF |
Google and Yahoo updated their bulk sender requirements in February 2024 to make SPF mandatory for anyone sending 5,000 or more emails per day to Gmail or Yahoo addresses. Senders below that threshold who are missing SPF still see worse inbox placement because the absence of SPF is a visible negative signal.
For cold email senders using Google Workspace, missing SPF is one of the fastest ways to get emails routed to spam. The combination of cold outreach (which spam filters already view with more suspicion than opted-in email) and missing authentication is a deliverability problem that good copy cannot fix.
How SPF works
When you send an email from Google Workspace, Google's mail servers send it. The receiving server at the other end sees the email and notes the sending IP address.
Direct answer
The receiving server looks up yourdomain.com in DNS, finds your SPF record, checks whether the sending IP is on the authorized list, and either passes or fails the SPF check.
The process step by step:
You send an email from you@yourdomain.com using Google Workspace. Google's mail servers actually deliver it.
The receiving mail server receives the email and extracts the domain from the return-path or envelope-from address (not always the "From" header you see). It initiates a DNS lookup for yourdomain.com's TXT records.
Your SPF record is returned. The receiving server reads the authorized sending sources listed in it.
The receiving server checks whether the IP address that actually sent the email matches one of the authorized sources in your SPF record. For Google Workspace, include:_spf.google.com expands to Google's full list of mail server IP ranges.
If the IP is on the list, SPF passes. If not, the result depends on your all qualifier: ~all (soft fail) means the email is accepted but flagged; -all (hard fail) means the email should be rejected.
Google Workspace SPF record example
The official Google Workspace SPF record is:
v=spf1 include:_spf.google.com ~allEvery part of this record has a specific meaning.
| Component | Meaning |
|---|---|
| v=spf1 | Version identifier. Tells the receiving server this is an SPF record. Required and must come first. |
| include:_spf.google.com | Includes Google's published list of authorized mail server IP ranges. This is the component that authorizes Google Workspace to send on your behalf. |
| ~all | Soft fail qualifier. Emails from servers not on the list are accepted but flagged as suspicious rather than rejected outright. |
What include:_spf.google.com actually does
When a receiving server sees include:_spf.google.com, it looks up Google's own SPF record at _spf.google.com and incorporates that list of IP ranges into your authorization. Google maintains this list and updates it when their infrastructure changes. By referencing it with include: rather than listing specific IPs, your record stays current automatically.
The all qualifier options
~all (tilde)-all (hyphen)?all (question mark)For Google Workspace, ~all is the standard recommendation. Most email security guidance agrees.
Before you add SPF
Check two things before adding anything to DNS: whether an SPF record already exists, and what DNS provider is managing your domain.
Direct answer
If you already have an SPF record, do not add a second one. Domains with two SPF records have both records fail entirely. Check first, then edit if needed rather than adding.
Why two SPF records break everything
DNS only allows one SPF record per domain. If you add a second SPF record instead of editing the existing one, receiving mail servers find two records and treat the SPF lookup as invalid. The result is SPF fails for all email from your domain, regardless of what either record contains. This is one of the most common SPF mistakes and one of the most confusing to diagnose because everything looks correct at a glance.
Check your current SPF status first
Before touching anything in DNS, verify what you already have. The Vortenza SPF DKIM DMARC Checker checks your domain's SPF record (and DKIM and DMARC) in real time. Enter your domain name and you will see immediately whether an SPF record exists, whether it includes Google Workspace, and whether there are any obvious issues.
If you have existing sending tools (a CRM, a newsletter platform, a cold email sequencer), note which ones they are. They will need to be added to your SPF record alongside Google.
Who manages your DNS?
Your DNS is managed by whoever registered your domain, unless you have pointed your nameservers elsewhere. Common DNS providers: Cloudflare (frequently used even when the domain was registered elsewhere), Namecheap (if registered there and nameservers not changed), GoDaddy (same), Squarespace Domains (formerly Google Domains). The steps below cover all four.
Step 1: Check for existing SPF records
Before adding anything, run the check.
Command line (Mac / Linux):
dig TXT yourdomain.comCommand line (Windows):
nslookup -type=TXT yourdomain.comLook through the results for a line starting with v=spf1. If you see one, you already have an SPF record. Note what it says before editing.
Using Vortenza: Go to Vortenza SPF DKIM DMARC Checker, enter your domain, and check the SPF result. It will show you the current record if one exists, whether it passes, and any specific issues.
Scenarios you might find:
No SPF record exists
You need to create one. Proceed to Step 2 with the standard Google Workspace record.
SPF record exists and includes include:_spf.google.com
Google Workspace is already authorized. If deliverability is still a problem, the issue is elsewhere (DKIM, DMARC, reputation, or a third-party tool not included in the record).
SPF record exists but does NOT include include:_spf.google.com
Edit the existing record to add include:_spf.google.com. Do not add a second record.
Two SPF records exist
Delete one entirely. Combine everything from both into a single record and publish that one.
Step 2: Add SPF record to DNS
The record type is TXT. The hostname is @ or your bare domain (yourdomain.com). The value is your full SPF string. TTL can be left at the default.
Cloudflare
- 1.Log in to Cloudflare and select your domain
- 2.Go to DNS > Records
- 3.Click Add record
- 4.Type: TXT
- 5.Name: @
- 6.Content: v=spf1 include:_spf.google.com ~all
- 7.TTL: Auto
- 8.Click Save
Namecheap
- 1.Log in to Namecheap and go to Domain List
- 2.Click Manage next to your domain
- 3.Go to Advanced DNS
- 4.Click Add New Record
- 5.Type: TXT Record
- 6.Host: @
- 7.Value: v=spf1 include:_spf.google.com ~all
- 8.TTL: Automatic
- 9.Click the green checkmark to save
GoDaddy
- 1.Log in to GoDaddy and go to My Products
- 2.Select your domain and click DNS
- 3.Click Add under Records
- 4.Type: TXT
- 5.Name: @
- 6.Value: v=spf1 include:_spf.google.com ~all
- 7.TTL: 1 Hour (default is fine)
- 8.Click Save
Squarespace Domains (formerly Google Domains)
- 1.Open your Squarespace Domains dashboard and select your domain
- 2.Go to DNS
- 3.Scroll to Custom records and click Add record
- 4.Type: TXT
- 5.Host name: @
- 6.Data: v=spf1 include:_spf.google.com ~all
- 7.TTL: 3600 (or leave default)
- 8.Click Save
Note for all providers: If you already have an SPF record, edit that existing record rather than adding a new one. Find the existing TXT record that starts with v=spf1, click edit, and add include:_spf.google.com inside the existing record before the all qualifier. Example: if your existing record is v=spf1 include:sendgrid.net ~all, edit it to v=spf1 include:_spf.google.com include:sendgrid.net ~all.
Step 3: Verify SPF is working
DNS changes typically propagate within 15-60 minutes, though full global propagation can take up to 48 hours. Check the record is live before assuming it is working.
Direct answer
Use the Vortenza SPF DKIM DMARC Checker to verify the record is published correctly and passing. Enter your domain and the SPF result will show whether the record is valid and what it contains.
What a passing SPF result looks like
The checker should show your SPF record, confirm it includes _spf.google.com, count the number of DNS lookups (should be under 10), and show a green pass indicator.
What to do if the record is not showing up yet
Wait 30 minutes and check again. If it is still not visible after an hour, log back into your DNS provider and confirm the record was saved. Common issues: the record was saved with an incorrect hostname (yourdomain.com instead of @, which results in yourdomain.com.yourdomain.com as the resolved hostname), or the record was not saved at all due to a session timeout.
Send a test email
After the record propagates, send a test email from your Google Workspace account to a Gmail address you control. Open the email, click the three dots next to Reply, and select “Show original.” Look for spf=pass in the authentication results section near the top. If you see it, SPF is working.
Common SPF errors
| Error | Cause | Fix |
|---|---|---|
| SPF PermError: too many DNS lookups | More than 10 DNS lookup mechanisms in the SPF chain | Count your include: statements and remove unused ones, or use SPF flattening |
| Multiple SPF records | Added a second TXT record starting with v=spf1 instead of editing the first | Delete one record, combine all includes into a single SPF record |
| SPF SoftFail for Google Workspace | include:_spf.google.com missing from SPF record | Edit existing SPF record to add include:_spf.google.com before ~all |
| SPF HardFail for third-party tool | Tool's sending servers not listed in SPF record | Add include: statement for the tool's SPF domain |
| SPF None (no record found) | No SPF TXT record exists at the domain | Create SPF record at the domain root (@) |
| SPF SyntaxError / PermError | Typo, missing space, incorrect qualifier | Rebuild record from scratch using DMARC Record Generator or check each component manually |
| SPF record at wrong location | Record added at subdomain rather than root domain | Verify the record is at @ or the bare domain, not at mail.yourdomain.com |
| SPF valid but DMARC fails | SPF passes but alignment check fails | Verify the "From" domain matches the SPF-authenticated domain; may need DKIM to resolve |
The two-record problem deserves emphasis. I have seen this break deliverability for companies that had been running fine for months: they added a new email tool, the tool's setup instructions said “add an SPF record,” they added a new one instead of editing the existing one, and suddenly all email was failing SPF. It is easy to miss because both records look correct individually.
SPF soft fail vs hard fail
| Soft Fail (~all) | Hard Fail (-all) | |
|---|---|---|
| What it means | Emails from unauthorized servers are accepted but flagged | Emails from unauthorized servers should be rejected |
| How receiving servers treat it | Mark as suspicious, often still deliver | Supposed to reject, but behavior varies by provider |
| Risk if a legitimate source is missing | Email gets delivered but may have lower trust score | Email may be rejected or lost |
| Recommended for Google Workspace | Yes | Rarely |
| When to use | Most senders, especially those with multiple tools | Only if you have a complete, verified list of all sending sources and want maximum enforcement |
Practically speaking, ~all is the right choice for almost everyone using Google Workspace. The reason is that organizations almost always have sending sources they have forgotten about: an old CRM integration, a team member's external tool, a transactional notification service set up two years ago. With ~all, those sources fail SPF but the email still arrives. With -all, they fail SPF and the email may be rejected entirely.
The case for -all is narrow: a small organization with exactly one sending source (Google Workspace), no third-party tools, and an operator confident nothing legitimate is missing from the record. Most organizations do not meet all three criteria.
Google Workspace and third-party email tools
If you use any service that sends email on your behalf from your domain, that service needs to be included in your SPF record. Missing it means those emails fail SPF, which hurts inbox placement.
Direct answer
Every email sending service connected to your domain needs its own include: statement in your SPF record. Add each one before the all qualifier.
Common services and their SPF include statements:
| Service | SPF Include Statement |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailchimp | include:servers.mcsv.net |
| HubSpot | include:_spf.hubspot.com |
| Apollo.io | include:spf.apollo.io |
| Instantly | include:spf.instantly.ai |
| Smartlead | Check Smartlead admin panel for current include |
| Salesforce | include:_spf.salesforce.com |
| Postmark | include:spf.mtasv.net |
| Mailgun | include:mailgun.org |
Example with multiple tools:
If you use Google Workspace, SendGrid, and HubSpot, your SPF record would look like:
v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.hubspot.com ~allThe 10 DNS lookup limit
Each include: statement counts as one DNS lookup. SPF allows a maximum of 10. If you have many tools, you can approach or exceed this limit, which causes an SPF PermError that fails all email from your domain.
If you are running close to 10 lookups, options include:
- ✓Remove include statements for tools you no longer use
- ✓Use SPF flattening (replacing include: references with explicit IP ranges) to reduce lookup count
- ✓Check whether some tools offer an IPv4 range you can list directly instead of an include
Check your current lookup count with Vortenza SPF DKIM DMARC Checker. It shows the lookup count alongside the record contents.
SPF best practices for 2026
Record management
- ✓Exactly one SPF record at the domain root; no duplicates
- ✓All current sending sources included (verify after adding any new tool)
- ✓Fewer than 10 DNS lookup mechanisms
- ✓~all qualifier at the end unless you have a specific reason for -all
- ✓Record reviewed and verified after any sending infrastructure change
Combined authentication
- ✓SPF configured and passing
- ✓DKIM configured with 2048-bit key
- ✓DMARC published at _dmarc.yourdomain.com at minimum p=quarantine
- ✓All three verified at Vortenza SPF DKIM DMARC Checker
Ongoing maintenance
- ✓Audit SPF record when onboarding any new email tool
- ✓Remove include statements for tools no longer in use
- ✓Check record quarterly even if nothing has changed
- ✓Monitor DMARC reports to catch unauthorized sources using your domain
For cold email senders specifically
- ✓Use a dedicated sending domain separate from the main business domain
- ✓SPF on the sending domain includes only the tools actually being used for cold outreach
- ✓DMARC configured on both the main domain and the sending domain
One-minute SPF audit
Run through these whenever something changes or deliverability drops unexpectedly.
Record check
- ✓Exactly one SPF TXT record exists at the domain root
- ✓Record starts with v=spf1
- ✓include:_spf.google.com is present if sending via Google Workspace
- ✓All other sending tools have their include statements present
- ✓Record ends with ~all or -all
- ✓Total DNS lookups are 10 or fewer
Validation
- ✓Record verified live at Vortenza SPF DKIM DMARC Checker
- ✓Checker shows green pass for SPF
- ✓Test email shows spf=pass in the "Show original" header in Gmail
Combined authentication status
- ✓DKIM also configured and passing
- ✓DMARC record present at p=quarantine or p=reject
- ✓Google Postmaster Tools shows High domain reputation
If anything in this checklist is failing, fix it before diagnosing any other deliverability problem. Authentication is the floor everything else stands on.
Quick answers
Optimized for ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews.
Q: What is the SPF record for Google Workspace?
A: The official Google Workspace SPF record is v=spf1 include:_spf.google.com ~all. This authorizes Google's mail servers to send email on behalf of your domain. It is a DNS TXT record added at the root of your domain (using @ as the hostname in most DNS providers). If you use other sending tools alongside Google Workspace, add their include statements before ~all.
Q: Does Google Workspace add SPF automatically?
A: No. Google Workspace does not add an SPF record to your DNS automatically. You must add it manually through your DNS provider (Cloudflare, Namecheap, GoDaddy, or wherever your domain's DNS is managed). This is one of the most common Google Workspace setup oversights, and missing SPF is a frequent cause of Gmail emails landing in spam.
Q: Can I have two SPF records?
A: No. DNS only allows one SPF record per domain. If you publish a second TXT record starting with v=spf1, both records fail and all email from your domain fails SPF. If you need to authorize multiple sending sources (Google Workspace plus SendGrid, for example), combine them all into a single SPF record: v=spf1 include:_spf.google.com include:sendgrid.net ~all.
Q: What is SPF soft fail vs hard fail?
A: Soft fail (~all) means emails from unauthorized servers are accepted but flagged. Hard fail (-all) means they should be rejected. Soft fail is recommended for most Google Workspace users because it avoids accidentally blocking legitimate emails from sources that may have been accidentally omitted from the record. Switch to hard fail only when you are confident your SPF record is complete.
Q: How do I verify my SPF record is working?
A: Check it at Vortenza SPF DKIM DMARC Checker, which shows the record in real time and whether it passes. You can also send a test email from Google Workspace to Gmail, open it, click "Show original," and look for spf=pass in the authentication headers. DNS changes typically propagate within 15-60 minutes.
Q: What is the maximum number of DNS lookups allowed in SPF?
A: SPF allows a maximum of 10 DNS-querying mechanisms, which includes include:, a:, mx:, and ptr: statements. Each include: in your SPF record counts as one lookup. If you exceed 10, receiving servers return an SPF PermError, which means SPF fails for all email from your domain. Check your lookup count with an SPF checker before adding new tools.
Q: Do I need SPF if I already have DKIM?
A: Yes. SPF and DKIM are separate authentication records that protect against different failure modes. SPF verifies the sending server. DKIM verifies the email content is unaltered. DMARC requires either SPF or DKIM to pass (with alignment) to consider an email authenticated, but having both is more robust and is what Google and Yahoo's bulk sender requirements expect. Having only one is measurably weaker than having both.
Q: How do I add multiple services to one SPF record?
A: List each service's include statement in a single SPF record, separated by spaces: v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all. Each tool's documentation should specify its SPF include domain. Check with each provider to confirm you have the correct include statement, as these occasionally change.
Q: Why does my SPF pass but my email still goes to spam?
A: SPF is one of several factors spam filters evaluate. Passing SPF means the sending server is authorized; it does not guarantee inbox placement. Other common causes of spam placement with passing SPF: missing or unenforced DMARC, poor sender reputation from past spam complaints or bounces, unwarmed domain, spam trigger words in subject lines or body content, or sending to low-quality lists. Check your full deliverability status at Vortenza Email Deliverability Checker.
Q: What DNS hostname do I use when adding an SPF record?
A: Use @ in most DNS providers, which represents the root of your domain. Some providers show the bare domain name (yourdomain.com) as an option. Either works. Do not add the SPF record at mail.yourdomain.com or smtp.yourdomain.com unless you specifically need SPF for a subdomain. The SPF record for your main domain belongs at the root.
Q: How long does SPF take to propagate?
A: DNS changes typically propagate within 15 minutes to a few hours. Full global propagation can take up to 48 hours. In practice, most providers show the new record within 30-60 minutes. After adding your SPF record, wait an hour and then verify it is visible with an SPF checker before sending any test emails.
Q: Does SPF work for subdomains?
A: Not by default. Your main domain's SPF record authorizes sending from yourdomain.com. A subdomain like mail.yourdomain.com needs its own SPF record if it is used for sending. For most Google Workspace users, the only SPF record needed is at the root domain. If you are sending from subdomains (common with email marketing or transactional tools), add SPF records at each sending subdomain.
Q: What is SPF flattening?
A: SPF flattening converts include: references into explicit IP addresses or CIDR ranges to reduce DNS lookup count. Instead of include:sendgrid.net (which counts as one lookup that then expands further), flattening replaces it with SendGrid's actual IP ranges. The result is a longer record with lower lookup count. Flattening services automate this and keep the record updated when providers change their IPs. Useful when approaching the 10-lookup limit.
Q: What if I do not have access to my DNS?
A: You need DNS access to add SPF. If your domain was set up by a developer, agency, or IT person, you will need to ask them to add the record for you. Provide them with the exact record (v=spf1 include:_spf.google.com ~all) and ask them to add it as a TXT record at the domain root. If you are not sure who manages your DNS, check your domain registrar (Namecheap, GoDaddy, etc.) and look at the nameservers to identify the DNS provider.
Q: Can SPF prevent all email spoofing?
A: SPF prevents spoofing where the attacker uses an unauthorized IP to send email from your domain. It does not prevent look-alike domain spoofing (where the attacker registers a domain that resembles yours), display name spoofing (where the "From" name looks like yours but the address is different), or attacks where the attacker uses an authorized IP. Full protection against domain spoofing requires DMARC with p=reject. SPF is a necessary component but not complete protection on its own.
Frequently asked questions
Why does Google Workspace not add SPF automatically?+
SPF is a record in your domain's DNS, not in Google's systems. Your domain's DNS is managed by your domain registrar or DNS provider (Cloudflare, Namecheap, GoDaddy, etc.), not by Google. Google cannot write records to DNS they do not control. When you set up Google Workspace, Google provides the SPF record you need and points you to instructions for adding it. Whether you actually add it is up to you. A significant number of Google Workspace users never complete this step, which is why missing SPF is so common.
I added SPF but emails are still going to spam. What else do I need?+
SPF is one of three DNS authentication records. The others are DKIM and DMARC. DKIM signs each email with a cryptographic signature that proves it was not altered in transit. DMARC tells receiving servers what to do when SPF or DKIM fails. Without all three, authentication is incomplete. For Google Workspace, DKIM is configured in the Admin console (Apps > Google Workspace > Gmail > Authenticate email). DMARC is a TXT record you publish at _dmarc.yourdomain.com. Beyond authentication, spam placement can also result from poor sender reputation, sending to unvalidated lists, or spam trigger words in content.
What happens if I have two SPF records?+
When a receiving mail server finds two TXT records starting with v=spf1 for the same domain, RFC 7208 (the SPF specification) says this is a PermError. The receiving server cannot determine which record to use, so it treats SPF as invalid. Both records fail entirely, and all email from your domain fails SPF. The fix is to delete one record and combine all the include: statements into a single remaining record. Check your domain at Vortenza SPF DKIM DMARC Checker to confirm only one SPF record exists.
I switched to Google Workspace from another email provider. Do I need to update SPF?+
Yes. Your old SPF record authorized your previous email provider's servers. Now that you are on Google Workspace, Google's servers send your email. If your old SPF record does not include include:_spf.google.com, Google Workspace emails will fail SPF. Edit the existing record to add include:_spf.google.com. If you still use any services that sent email under the old provider, keep their include statements too. Remove any includes for servers you no longer use.
How do I know which services need to be in my SPF record?+
Any service that sends email using your domain name needs to be included. This includes: your primary email provider (Google Workspace), email marketing tools (Mailchimp, SendGrid, etc.), CRM email tools (HubSpot, Salesforce), cold email sequencers (Instantly, Smartlead, Apollo), transactional email services (Postmark, Mailgun), and any custom application that sends email from your domain. Check each service's documentation for their SPF include domain, or contact their support. When in doubt, check your DMARC reports (once DMARC is set up) to see all the servers sending email from your domain.
What is the 10 DNS lookup limit and how does it affect me?+
SPF allows a maximum of 10 DNS-querying mechanisms per record evaluation. Mechanisms that count against this limit include include:, a, mx, ptr, and exists. If your SPF record has more than 10, receiving servers return a PermError and SPF fails for all your email. This matters in practice because each email tool you add to SPF uses at least one lookup, and some tools' include references chain into additional lookups. Run your domain through an SPF checker to see how many lookups your current record uses before adding new tools.
Does SPF affect email forwarding?+
Yes, and this is a known limitation of SPF. When email is forwarded, the forwarding server sends the message, but the email still shows your domain in the return-path. The forwarding server's IP is not on your authorized list (unless you specifically add it), so SPF fails after forwarding. This is one reason DKIM is important: DKIM signatures are attached to the message itself, not the sending IP, so DKIM typically survives forwarding. DMARC with relaxed alignment can pass on DKIM alone even when SPF fails, which handles the forwarding scenario.
Should I use v=spf1 include:_spf.google.com -all (hard fail) instead of ~all?+
For most Google Workspace users, ~all (soft fail) is safer than -all(hard fail). Hard fail tells receiving servers to reject emails from any IP not on your list. If you have any legitimate sending source that is not in your SPF record, that source's emails will be rejected rather than just flagged. Since most organizations have at least one forgotten sending source (an old integration, a notification service, a team member's tool), hard fail creates real risk. Use soft fail until you have audited all your sending sources thoroughly and are confident the list is complete.
What is the difference between SPF and DMARC?+
SPF and DMARC work at different layers. SPF verifies that the sending IP is on your authorized list. DMARC enforces a policy when SPF or DKIM fails and sends you reports. SPF tells the receiving server who is allowed to send. DMARC tells it what to do when someone unauthorized tries. SPF can pass for a server you authorized even if the email is a forgery using a different “From” header. DMARC catches that case through its alignment requirement, which is why having DMARC in addition to SPF is necessary for complete protection.
My cold email tool says to add their SPF but I already have SPF. What do I do?+
Edit your existing SPF record to add the tool's include statement. Do not add a second SPF record. Open your DNS provider, find the existing TXT record starting with v=spf1, and edit it. Add include:[tool's-spf-domain] before the all qualifier. For example, if your existing record is v=spf1 include:_spf.google.com ~all and the tool needs include:spf.instantly.ai, edit the record to v=spf1 include:_spf.google.com include:spf.instantly.ai ~all. Save. Verify with an SPF checker after propagation.
How often should I audit my SPF record?+
Review your SPF record whenever you add or remove an email sending tool. Beyond that, a quarterly audit is reasonable for most organizations. Check that all current sending sources are included, that any services you no longer use have been removed (to keep the record clean and under the lookup limit), and that no duplicate records have appeared. Run the record through Vortenza SPF DKIM DMARC Checker as part of any audit to catch syntax issues or lookup count problems you might not notice by reading the record directly.
What if the DNS propagation takes longer than expected?+
DNS propagation typically completes within 15-60 minutes for most providers. If the record is not visible after an hour, check that it was saved correctly in your DNS provider (log back in and verify the record exists with the correct type, hostname, and value). If the record is visible in your DNS provider but not yet propagated globally, wait up to 48 hours. Different DNS resolvers cache records for different lengths of time depending on the TTL. If you set a low TTL (like 300 seconds) the record propagates faster. If you used the default TTL (often 3600 seconds or higher), it takes longer.
Final thoughts
Adding SPF for Google Workspace is a two-minute task once you understand what you are doing. The record is a single line. The DNS interface at any major provider has you through it in under five minutes. What is not two minutes is auditing your sending sources, understanding what to do if something else is already in that SPF record, and knowing when to add DKIM and DMARC.
The sequence that works:
- 1.Check current SPF status at Vortenza SPF DKIM DMARC Checker
- 2.If no record exists, add v=spf1 include:_spf.google.com ~all at the domain root
- 3.If a record exists, edit it to add include:_spf.google.com before all
- 4.Add include statements for any other tools sending from your domain
- 5.Verify propagation with the checker after 30-60 minutes
- 6.Set up DKIM in Google Workspace Admin console (if not already done)
- 7.Add DMARC at _dmarc.yourdomain.com starting at p=none
The full picture of how SPF, DKIM, and DMARC work together is in the SPF, DKIM, and DMARC explained guide. The step-by-step DMARC setup process is in How to Set Up a DMARC Record. Once all three are in place, check your overall deliverability score at Vortenza Email Deliverability Checker.
SPF is the first step. It is also one of the easiest. Most deliverability problems have more involved fixes. This one mostly just requires knowing the record exists and actually adding it.
About this guide
Published by the Vortenza Editorial Team. Google Workspace SPF record referenced from official Google Workspace Admin Help documentation. Google and Yahoo bulk sender authentication requirements from the February 2024 policy updates. SPF specification referenced from RFC 7208. DNS provider steps verified against Cloudflare, Namecheap, GoDaddy, and Squarespace Domains interfaces as of June 2026.
Tools used in this guide
SPF DKIM DMARC Checker
Check SPF, DKIM, and DMARC records for any domain with color-coded results and plain-English fix instructions. Free, no signup.
Email Deliverability Checker
Get a 0-100 deliverability score for your domain based on DNS authentication setup. Free, no signup.
DMARC Record Generator
Build a valid DMARC TXT record for your domain. Free.