If your organization uses Google Workspace for business email, configuring an SPF (Sender Policy Framework) record is an important part of protecting your domain and improving email authentication.

SPF tells receiving mail servers which systems are authorized to send email on behalf of your domain.

Without a correctly configured SPF record, legitimate messages may:

• Go to the recipient's Spam/Junk folder
• Fail email authentication
• Be treated as suspicious
• Experience deliverability problems
• Be rejected by some receiving servers

An SPF record also makes it more difficult for unauthorized servers to impersonate your domain.

However, SPF should not be treated as a complete anti-spoofing solution by itself. A professionally configured business domain should normally use:

SPF + DKIM + DMARC

This guide explains how SPF works, how to configure it for Google Workspace, how to include additional email services, how to verify it, and how to troubleshoot common SPF problems.

1. What Is SPF?

SPF stands for Sender Policy Framework.

It is an email authentication mechanism based on DNS.

The domain owner publishes an SPF policy in DNS as a TXT record. When a receiving email server receives a message, it can check the SPF policy associated with the relevant sending domain and determine whether the sending mail server is authorized.

For example, if your organization uses Google Workspace, your SPF policy can authorize Google's mail infrastructure to send messages for your domain.

2. Why Is SPF Required?

Consider a business domain:

example.com

Employees use addresses such as:

• accounts@example.com
• sales@example.com
• support@example.com

Without appropriate email authentication, an attacker may attempt to send fraudulent messages that appear to originate from your organization.

Examples include:

• Fake payment requests
• Fake invoices
• CEO impersonation
• Password-reset scams
• Vendor payment fraud
• Phishing messages
• Fake quotation emails

SPF provides receiving systems with information about which mail systems your domain authorizes.

3. Standard Google Workspace SPF Record

If Google Workspace is the only service sending email for your domain, the commonly used Google Workspace SPF record is:

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

It is normally published as a DNS TXT record for the root domain.

Typical configuration:

DNS Setting	Value
Type	TXT
Host/Name	@
Value	v=spf1 include:_spf.google.com ~all
TTL	3600 or provider default

Some DNS providers do not use @. They may require the root domain, or they may require the Host/Name field to be left blank.

Always follow the syntax required by your DNS provider.

4. Understanding the Google Workspace SPF Record

Let's examine:

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

v=spf1

This identifies the TXT value as an SPF version 1 policy.

include:_spf.google.com

This tells receiving mail servers to evaluate Google's SPF policy and therefore authorize the appropriate Google mail infrastructure.

~all

This is commonly called SoftFail.

It indicates that systems not otherwise authorized by the SPF policy should be treated as probably unauthorized.

The receiving server ultimately decides how it handles the message.

5. Where Is the SPF Record Added?

A very common misunderstanding is that SPF is configured inside Gmail.

Normally, it is not.

SPF is published in the DNS zone of your domain.

Therefore, you need access to whichever service currently manages your authoritative DNS.

This might be:

• Domain registrar
• Web hosting provider
• DNS hosting company
• Cloud DNS service
• Corporate DNS provider

The important point is:

Add the SPF record where your domain's authoritative DNS is managed.

It does not necessarily have to be the company where the domain was originally purchased.

6. How to Find Where Your DNS Is Managed

Check your domain's authoritative nameservers.

For example:

ns1.exampledns.com
ns2.exampledns.com

These nameservers generally indicate which provider is responsible for publishing your DNS records.

Do not modify DNS randomly at the registrar if your nameservers point somewhere else.

Changes made in the wrong DNS control panel will have no effect.

7. Step-by-Step: Configure SPF for Google Workspace

Step 1 – Identify All Systems Sending Email

Before changing SPF, make a list of every system that sends email using your domain.

Examples:

• Google Workspace
• Website contact forms
• CRM software
• Accounting software
• Helpdesk
• Newsletter system
• ERP
• Marketing automation platform
• Cloud applications
• SMTP relay
• Transactional email provider
• Application server

This is extremely important.

If you authorize only Google while another legitimate service also sends mail using your domain, those messages may fail SPF.

Step 2 – Log In to Your DNS Provider

Open the control panel responsible for your domain's DNS.

Look for sections named:

• DNS
• DNS Zone
• DNS Management
• Manage DNS
• Zone Editor
• Advanced DNS

Step 3 – Search for an Existing SPF Record

Before creating anything, search your TXT records for:

v=spf1

Important

Do not simply create another SPF record if one already exists.

A domain should normally publish one SPF policy for the same hostname.

If multiple services need authorization, their mechanisms should generally be combined into that single SPF policy.

8. Example: Google Workspace Only

If Google Workspace is your only email-sending system:

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

Create:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all
TTL: 3600

Then save the DNS record.

9. What If an SPF Record Already Exists?

Suppose your DNS already contains:

v=spf1 include:mail.exampleprovider.com ~all

Do not normally add a separate record:

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

Instead, if both services legitimately send mail for the domain, they need to be incorporated into a single SPF policy.

Conceptually:

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

The exact record depends on the services actually being used.

Never add an include: value merely because you found it on the Internet. Obtain the required SPF mechanism from the service provider.

10. Google Workspace + Third-Party Email Services

Modern organizations often use several email-sending platforms.

For example:

Google Workspace
       |
       +---- Employees
       |
       +---- CRM
       |
       +---- Website
       |
       +---- Marketing Platform

Each legitimate sender may need appropriate authorization.

An SPF record might conceptually look like:

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

Again, thirdparty.example is only an illustration.

Use the actual SPF configuration supplied by your provider.

11. Website Contact Forms Are Frequently Forgotten

This is one of the most common real-world SPF mistakes.

A business uses Google Workspace for email, but its website is hosted elsewhere.

The website sends messages such as:

From: sales@example.com

through the web hosting server.

Now there are two potential sending environments:

Google Workspace
       +
Web Hosting Server

If the website sends mail directly rather than through an authenticated/authorized mail service, SPF and DMARC alignment problems can occur.

A better design is often to configure the website or application to use an authenticated SMTP or transactional email service rather than relying on generic PHP mail() delivery.

12. What Does SPF Actually Check?

SPF is frequently misunderstood.

It does not simply ask:

"Does the visible From address match?"

SPF authentication is based on the SMTP sending path/domain and the connecting server.

This distinction becomes particularly important with:

• Email forwarding
• Mailing lists
• Third-party platforms
• CRM systems
• SMTP relays
• DMARC alignment

This is one reason SPF alone is insufficient for comprehensive email authentication.

13. SPF vs DKIM vs DMARC

These technologies complement one another.

Technology	Main Purpose
SPF	Authorizes sending infrastructure
DKIM	Cryptographically signs email
DMARC	Defines authentication/alignment policy and reporting

A strong business email configuration generally uses all three.

SPF

Answers approximately:

Is this sending system authorized by the domain's SPF policy?

DKIM

Answers:

Does the message contain a valid cryptographic signature associated with the signing domain?

DMARC

Evaluates authentication and domain alignment and allows the domain owner to publish a policy for handling messages that fail.

14. SPF Alone Does Not Completely Prevent Spoofing

A common statement is:

"SPF prevents spoofing."

This is an oversimplification.

SPF contributes to anti-spoofing protection, but SPF alone does not completely protect the visible From address.

For stronger domain protection, configure:

SPF
+
DKIM
+
DMARC

15. SoftFail (~all) vs Fail (-all)

You may encounter SPF policies ending with:

~all

or:

-all

~all

SoftFail.

Unauthorized sources are marked as probably unauthorized.

-all

Hard Fail.

The domain explicitly states that non-authorized sources should fail SPF.

A strict -all policy should not be implemented casually.

Before using it, confirm that every legitimate sending source has been identified and authorized.

16. Other SPF Qualifiers

SPF mechanisms can use qualifiers such as:

+
-
~
?

They represent:

Qualifier	Meaning
+	Pass
-	Fail
~	SoftFail
?	Neutral

In most configurations, you will not manually use all of these.

17. Common SPF Mechanisms

You may see mechanisms such as:

include:
ip4:
ip6:
a
mx
all

Example:

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

This could authorize a specific IPv4 address plus Google.

The IP address above is only an example.

18. The SPF 10-DNS-Lookup Limit

This is an important technical limitation.

SPF evaluation permits a limited number of DNS-query-causing mechanisms.

Complex SPF policies containing many nested include, a, mx, redirect, or similar mechanisms can exceed the permitted lookup limit.

This can produce:

PermError

or errors such as:

Too many DNS lookups

Therefore, do not keep adding third-party services indefinitely without reviewing the resulting SPF structure.

19. Do Not Create Multiple SPF Records

Incorrect:

TXT  v=spf1 include:_spf.google.com ~all
TXT  v=spf1 include:another-provider.example ~all

This can cause SPF evaluation problems.

If both services are legitimate senders, they generally need to be combined into a single SPF policy.

Example concept:

v=spf1 include:_spf.google.com include:another-provider.example ~all

20. DNS Propagation

After saving the SPF TXT record, the update may not become visible everywhere immediately.

How quickly it becomes available depends on:

• DNS provider
• TTL
• Recursive DNS caching
• Previous record TTL
• Nameserver infrastructure

Some changes appear within minutes, while cached data can remain visible for considerably longer.

Avoid repeatedly deleting and recreating the record simply because a checker does not immediately see it.

21. How to Verify an SPF Record in Windows

You can query TXT records from Command Prompt.

Example:

nslookup -type=txt example.com

Look for a result containing:

v=spf1

For Google Workspace-only sending, you would expect a policy containing:

include:_spf.google.com

22. Verify SPF Using PowerShell

Windows administrators can use:

Resolve-DnsName example.com -Type TXT

Look through the TXT results for:

v=spf1

This is useful when troubleshooting DNS propagation or verifying the published policy.

23. Verify Using Google Admin Toolbox

Google Admin Toolbox provides DNS diagnostic utilities that can help administrators inspect publicly published DNS records.

You can use DNS lookup tools to inspect:

• TXT
• MX
• CNAME
• A
• AAAA
• NS

For SPF troubleshooting, query the domain's TXT records and confirm that the expected SPF policy is publicly visible.

24. Verify Authentication from an Actual Gmail Message

One of the best tests is to send a real email.

Send a message from your Google Workspace account to a Gmail mailbox.

Open the received message.

In Gmail, open the message menu and select:

Show original

Look for authentication results such as:

SPF: PASS
DKIM: PASS
DMARC: PASS

Ideally, a properly configured business domain should eventually achieve:

SPF = PASS
DKIM = PASS
DMARC = PASS

25. Understanding Authentication-Results Headers

Advanced administrators can inspect raw email headers.

You may see something similar to:

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

This is valuable when diagnosing deliverability or authentication problems.

26. Common SPF Errors

Error 1 – No SPF Record Found

Possible causes:

• SPF record was never created
• Record was created in the wrong DNS provider
• DNS propagation is incomplete
• Incorrect Host/Name was used

Solution

Check authoritative nameservers and verify the TXT record at the correct DNS provider.

Error 2 – Multiple SPF Records

Example:

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

and another separate:

v=spf1 include:provider.example ~all

Solution

Determine which systems legitimately send mail and consolidate their required mechanisms into one valid SPF policy.

Error 3 – SPF Does Not Include Google

The SPF policy exists but does not authorize Google Workspace.

Solution

If Google Workspace legitimately sends mail for the domain, make sure the SPF policy appropriately includes Google's sending infrastructure.

Error 4 – SPF PermError

Possible causes include:

• Invalid SPF syntax
• Excessive DNS lookups
• Broken nested include
• Multiple SPF policies
• Malformed mechanisms

Solution

Validate the SPF structure and inspect every included provider.

Error 5 – SPF PASS but Email Still Goes to Spam

SPF is only one factor in email deliverability.

Also check:

• DKIM
• DMARC
• Domain reputation
• Sending IP reputation
• Spam complaints
• Message content
• Link reputation
• Sending volume
• Recipient engagement
• Reverse DNS where applicable
• Mailing practices

An SPF PASS does not guarantee Inbox placement.

27. SPF and Email Forwarding

Traditional forwarding can create SPF complications because the forwarding server may become the server connecting to the final recipient.

That server may not be authorized by the original sender's SPF policy.

Modern email ecosystems use additional mechanisms and DKIM to improve authentication handling for forwarded mail.

This is another reason not to rely exclusively on SPF.

28. SPF and Subdomains

SPF policies are DNS-name specific.

For example:

example.com

and:

mail.example.com

are different DNS names.

If a subdomain is used as an independent email-sending domain, review its authentication configuration separately.

Do not automatically assume the root domain's SPF policy covers every possible subdomain configuration.

29. SPF and Google Workspace Aliases

If users send email using domain aliases or additional domains, administrators should review authentication for those domains as well.

Each domain used in the organization's email architecture should be properly configured according to how mail is actually sent.

30. SPF and SMTP Relay

Some organizations use Google Workspace together with:

• On-premises mail servers
• Printers
• Scanners
• ERP systems
• Accounting applications
• Monitoring systems
• CRM
• Legacy applications

These systems may use an SMTP relay.

Their authentication and SPF requirements depend on the actual outbound architecture.

Before changing SPF, determine:

Application
    ↓
SMTP Server / Relay
    ↓
Internet
    ↓
Recipient

The system that ultimately delivers the message externally is particularly relevant to SPF.

31. Recommended Email Authentication Architecture

For a typical Google Workspace business domain:

Domain DNS
│
├── MX
│     └── Google Workspace
│
├── SPF
│     └── Authorized sending systems
│
├── DKIM
│     └── Google Workspace signing key
│
└── DMARC
      └── Authentication policy + reporting

This provides much stronger email authentication than SPF alone.

32. Recommended Implementation Sequence

A practical implementation sequence is:

Phase 1 – Inventory

Document all email-sending systems.

Phase 2 – SPF

Publish a correct SPF policy.

Phase 3 – DKIM

Enable DKIM signing in Google Workspace and publish the required DNS record.

Phase 4 – DMARC

Deploy DMARC carefully, usually beginning with monitoring/reporting before moving to stronger enforcement.

Phase 5 – Monitor

Review:

• SPF failures
• DKIM failures
• DMARC reports
• Deliverability
• Spam complaints
• Unauthorized sending sources

33. SPF Troubleshooting Checklist

When SPF does not work, check the following:

1. Are you editing the authoritative DNS zone?
2. Is the record type TXT?
3. Does the SPF policy begin with v=spf1?
4. Does Google Workspace need to be authorized?
5. Is include:_spf.google.com present when appropriate?
6. Are there multiple SPF records?
7. Are third-party senders missing?
8. Is the syntax valid?
9. Has DNS propagation completed?
10. Has the SPF DNS-lookup limit been exceeded?
11. Are website forms sending independently?
12. Is an SMTP relay involved?
13. Is email being forwarded?
14. Does a test email show SPF PASS?
15. Are DKIM and DMARC also configured?

34. Example Troubleshooting Scenario

Suppose:

example.com uses:

• Google Workspace for employee email
• A CRM platform for customer notifications
• A website server for enquiry emails

The administrator publishes only:

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

Google Workspace messages may authenticate successfully through SPF.

However, messages originating through the CRM or web server may not.

The correct solution is not simply to add random DNS records.

Instead:

1. Identify how the CRM sends email.
2. Obtain the CRM provider's official authentication requirements.
3. Determine how the website sends mail.
4. Prefer authenticated SMTP/API delivery where practical.
5. Update the domain's single SPF policy as required.
6. Configure DKIM where supported.
7. Verify DMARC alignment.
8. Send test messages.
9. Inspect authentication results.

35. Security Best Practices

For business domains:

• Maintain only the SPF mechanisms you actually need.
• Remove obsolete email services from SPF.
• Do not authorize unknown servers.
• Do not copy another organization's SPF record.
• Do not create multiple SPF policies for the same hostname.
• Monitor DNS changes.
• Restrict access to the DNS control panel.
• Enable MFA on registrar/DNS accounts.
• Configure DKIM.
• Configure DMARC.
• Periodically review third-party email senders.
• Test authentication after major email infrastructure changes.

36. Important Warning Before Changing SPF

Do not replace an existing SPF policy blindly.

An existing SPF record may authorize:

• CRM systems
• ERP applications
• Web servers
• Newsletter platforms
• Helpdesk software
• Billing systems
• Transactional email platforms
• SMTP relay services

Deleting those authorizations can cause legitimate mail to fail SPF.

Always document your sending infrastructure before changing the policy.

37. Frequently Asked Questions (FAQ)

Q1. What is the SPF record for Google Workspace?

For a domain where Google Workspace is the only sending service, the commonly used policy is:

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

Q2. Is SPF added inside Google Admin Console?

The SPF policy itself is normally published as a TXT record in your domain's DNS.

Q3. Should the SPF DNS record type be SPF or TXT?

Modern SPF policies are published using a TXT DNS record.

Q4. What should I enter in the Host field?

For the root domain, many DNS providers use:

@

Others may require the field to be blank or use the domain name. Follow your DNS provider's format.

Q5. What TTL should I use?

A TTL such as:

3600

is commonly used, but your DNS provider's default is normally acceptable unless you have a specific requirement.

Q6. Can I have two SPF records?

You should not publish multiple independent SPF policies for the same hostname. If multiple services send email, their required authorization mechanisms generally need to be incorporated into one SPF policy.

Q7. I already have an SPF record. Should I delete it?

Not automatically.

First determine what services the existing record authorizes.

Deleting it could break email authentication for another legitimate sending service.

Q8. Does SPF stop all spoofing?

No.

SPF helps authenticate sending infrastructure, but comprehensive domain protection normally requires SPF, DKIM, and DMARC working together.

Q9. Does SPF guarantee my messages will reach the Inbox?

No.

SPF improves authentication, but spam filtering considers many additional factors.

Q10. How can I check whether SPF is working?

Send a test message to Gmail and inspect Show original or the message headers.

Look for:

SPF: PASS

Q11. Should DKIM also be enabled?

Yes. Google Workspace administrators should configure DKIM in addition to SPF.

Q12. Do I also need DMARC?

DMARC is strongly recommended for professional domains because it adds domain alignment, policy, and reporting on top of SPF/DKIM.

Q13. Can SPF affect website enquiry emails?

Yes.

If your website sends email using your domain but sends through infrastructure that is not properly authenticated or authorized, those messages can experience authentication or deliverability problems.

Q14. What happens if Google is missing from SPF?

Messages sent through Google Workspace may fail SPF authentication for the relevant SPF identity, which can contribute to deliverability problems.

Q15. What does ~all mean?

It represents SPF SoftFail for sources that do not otherwise match the policy.

Q16. What does -all mean?

It represents a stricter SPF Fail result for non-authorized senders.

Use it only after carefully validating your email infrastructure.

Q17. What is an SPF PermError?

It means SPF evaluation encountered a permanent problem, such as invalid syntax or an SPF policy that cannot be evaluated correctly.

Q18. What does "too many DNS lookups" mean?

Your SPF configuration may require more DNS-query-causing evaluations than SPF permits.

This often happens with complicated policies containing many nested include mechanisms.

Q19. Can I copy the SPF record from another domain?

No.

Your SPF policy should represent your own domain's legitimate email-sending infrastructure.

Q20. How often should SPF be reviewed?

Review SPF whenever you:

• Change email provider
• Add or remove a CRM
• Change website email delivery
• Add marketing software
• Change SMTP relay
• Migrate Google Workspace
• Stop using a third-party email platform

A periodic security review is also recommended.

Conclusion

SPF is one of the fundamental components of modern email authentication.

For a straightforward Google Workspace environment where Google is the only authorized sender, the SPF policy is commonly:

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

However, professional SPF management involves much more than copying this value into DNS.

Administrators must identify every legitimate sending service, avoid multiple SPF policies, understand third-party senders, monitor DNS lookup limits, test authentication, and implement DKIM and DMARC alongside SPF.

A well-configured email domain should aim for:

SPF   = PASS
DKIM  = PASS
DMARC = PASS

Together, these technologies improve domain protection, reduce opportunities for impersonation, and support reliable email delivery.

 

#GoogleWorkspace #SPF #SPFRecord #GoogleSPF #GmailSPF #SenderPolicyFramework #EmailAuthentication #EmailSecurity #GoogleWorkspaceAdmin #WorkspaceAdmin #GmailAdmin #DNS #DNSRecords #TXTRecord #GoogleDNS #DKIM #DMARC #SPFDKIMDMARC #EmailDeliverability #GmailDeliverability #EmailSpoofing #AntiSpoofing #DomainSecurity #BusinessEmail #GmailBusiness #GoogleWorkspaceSecurity #EmailProtection #DNSManagement #SPFSetup #SPFConfiguration #SPFTroubleshooting #SPFPass #SPFFail #SPFSoftFail #SPFPermError #DNSLookup #SMTP #SMTPRelay #EmailServer #GoogleAdmin #GoogleAdminToolbox #EmailDNS #DomainAuthentication #DMARCAlignment #EmailHeaders #GmailSecurity #WorkspaceSecurity #EmailAdministrator #ITSupport #BisonKnowledgebase