SPF Record Examples for Google Workspace, Microsoft 365, Zoho, SendGrid and Multiple Email Senders

If you are looking for SPF record examples, the most important rule is simple: publish one SPF TXT record for each sending domain and make sure it authorizes every legitimate service that sends email using that domain.

For example, Google Workspace commonly uses include:_spf.google.com, Microsoft 365 uses include:spf.protection.outlook.com, Zoho Mail uses include:zohomail.com, and Twilio SendGrid can use include:sendgrid.net depending on the sending configuration.

This page provides ready-to-copy SPF record examples for common email setups, including domains that use multiple email senders.

Important: Do not blindly copy an SPF record simply because it contains your email provider. Your final record must represent every service actually authorized to send mail for your domain.

Quick Answer: Common SPF Record Examples

Here are several commonly used SPF records.

Google officially documents v=spf1 include:_spf.google.com ~all for domains sending only through Google Workspace and also provides a combined Google Workspace and Microsoft 365 example. Microsoft states that most Microsoft 365 organizations need include:spf.protection.outlook.com. Zoho currently documents include:zohomail.com, while SendGrid documents include:sendgrid.net.

Never create a separate SPF record for every provider. If several services send mail using the same domain, their authorization mechanisms normally need to be combined into one SPF record.

Table of Contents

1. What Is an SPF Record?
2. How an SPF Record Works
3. SPF Record Syntax Explained
4. Google Workspace SPF Record Examples
5. Microsoft 365 SPF Record Examples
6. Zoho Mail SPF Record Examples
7. SendGrid SPF Record Examples
8. SPF Records for Multiple Email Senders
9. SPF Records With IP Addresses
10. ~all vs -all vs ?all
11. How to Add an SPF Record to DNS
12. The SPF 10 DNS Lookup Limit
13. Common SPF Record Mistakes
14. How to Check an SPF Record
15. SPF, DKIM and DMARC
16. Frequently Asked Questions

What Is an SPF Record?

SPF stands for Sender Policy Framework.

An SPF record is a DNS TXT record that specifies which mail systems are authorized to send email for a domain.

When a receiving mail server gets a message, SPF allows it to evaluate whether the server responsible for the relevant envelope sender is authorized by the domain's SPF policy.

A simple SPF record might look like this:

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

This record essentially tells receiving systems that the sending infrastructure authorized through Google's SPF policy is permitted and that other sources should receive a soft-fail result.

SPF is primarily designed to help prevent unauthorized use of domains in email and is commonly deployed alongside DKIM and DMARC.

How Does an SPF Record Work?

Imagine your company owns:

example.com

Employees send normal business email through Google Workspace, but your website also sends transactional emails through SendGrid.

You therefore have two legitimate sending services.

If your SPF record authorizes only Google:

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

the SendGrid mail path may not receive the SPF authorization you intended.

Instead, if your setup specifically requires both services in the SPF record for the same sending domain, you could combine them:

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

The key concept is:

Your SPF policy should accurately describe your real email infrastructure.

Adding unnecessary providers is not helpful because it expands the infrastructure authorized by your SPF policy.

SPF Record Syntax Explained

Consider this example:

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

It contains several components.

v=spf1

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

An SPF record begins with:

v=spf1

include:

The include mechanism evaluates another domain's SPF policy as part of determining whether a sender is authorized.

For example:

include:_spf.google.com

is used for Google Workspace.

ip4:

This mechanism authorizes an IPv4 address or network.

Example:

ip4:192.0.2.10

A network can also be represented with CIDR notation when appropriate.

ip6:

The ip6 mechanism performs the equivalent function for IPv6 addresses.

a

The a mechanism can authorize addresses associated with a domain's A or AAAA records.

mx

The mx mechanism can authorize addresses associated with the domain's MX hosts.

all

The all mechanism matches everything and is normally placed at the end of an SPF record with a qualifier.

Common endings include:

~all

and:

-all

These endings have different enforcement implications, which we will cover below.

Google Workspace SPF Record Examples

Google Workspace is one of the most common business email platforms.

Google Workspace Only

If Google Workspace is the only relevant sender for the domain, Google's documented SPF example is:

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

Google explicitly provides this value in its Workspace SPF setup documentation.

Typical DNS configuration:

The exact interface and host-name format depend on your DNS provider.

Google Workspace and Microsoft 365

A domain using both platforms may require:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Google itself lists this combination as an example for organizations using Google Workspace and Microsoft 365.

This situation can occur during:

• Microsoft 365 migrations
• Google Workspace migrations
• Hybrid email environments
• Organizations with multiple outbound systems

Google Workspace and SendGrid

If Google handles employee mail while SendGrid sends application or transactional mail, an example is:

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

However, check your SendGrid domain-authentication configuration before publishing it. Modern SendGrid configurations can use delegated records and a separate return-path subdomain rather than requiring you to modify the SPF record at your organizational domain.

Microsoft 365 SPF Record Examples

Microsoft 365, including Exchange Online, commonly uses:

include:spf.protection.outlook.com

Microsoft states that most Microsoft 365 organizations require this include in their SPF TXT record.

Microsoft 365 Only

A common example is:

v=spf1 include:spf.protection.outlook.com -all

Before using strict -all, confirm that Microsoft 365 is genuinely the only infrastructure that needs authorization under that SPF policy.

Microsoft 365 With an Additional Server

Microsoft provides syntax supporting IP addresses and third-party services alongside its own include.

For example:

v=spf1 ip4:192.0.2.10 include:spf.protection.outlook.com -all

Replace the documentation/example IP with the real public IP address of your authorized sending server.

Never copy an example IP address into production DNS.

Microsoft 365 and SendGrid

An example for a domain whose SPF policy genuinely needs to authorize both is:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Use this only after verifying how SendGrid is authenticated for your domain.

Zoho Mail SPF Record Examples

Zoho currently documents the following for Zoho Mail:

v=spf1 include:zohomail.com -all

Zoho also explains that ~all can be used instead of -all where a soft-fail policy is appropriate.

Zoho Mail Only

v=spf1 include:zohomail.com -all

Zoho Mail With Another Authorized Sender

Suppose Zoho handles normal email while another service sends application messages.

The mechanisms should be combined into one policy rather than creating multiple SPF records.

For example:

v=spf1 include:zohomail.com include:example-sender.com ~all

Replace example-sender.com with the actual SPF include supplied by your provider.

Multiple Zoho Services

Zoho's current documentation also mentions:

include:one.zoho.com

for organizations using multiple Zoho services, specifically as a way to help avoid SPF lookup problems.

Because email-provider infrastructure can change, verify the correct Zoho value for your account and region before changing production DNS.

SendGrid SPF Record Examples

Twilio SendGrid documentation gives this typical example:

v=spf1 include:sendgrid.net -all

for allowing SendGrid to send for a domain.

SendGrid Only

Example:

v=spf1 include:sendgrid.net -all

SendGrid With Google Workspace

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

SendGrid With Microsoft 365

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Important SendGrid Domain Authentication Note

Do not assume that every SendGrid customer needs to put include:sendgrid.net directly into the SPF record at example.com.

With SendGrid domain authentication, the platform can provide account-specific DNS records and use a branded return-path or sending subdomain. SendGrid's current documentation shows configurations where SPF is published for an em... subdomain as part of domain authentication.

Therefore, use the exact DNS records shown in your SendGrid account when setting up domain authentication.

SPF Record Examples for Multiple Email Senders

This is where many SPF configurations go wrong.

Suppose a company sends:

• Employee email through Google Workspace
• Transactional email through SendGrid
• Marketing email through another platform

A common mistake is creating three records:

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

v=spf1 include:sendgrid.net ~all

v=spf1 include:marketing-provider.example ~all

That is not the correct way to publish SPF for the same domain.

Instead, authorized sources belonging in the same SPF policy should be consolidated into a single record.

For example:

v=spf1 include:_spf.google.com include:sendgrid.net include:marketing-provider.example ~all

Zoho explicitly warns that multiple SPF records for the same domain cause conflicts and recommends consolidating authorized senders into one record. Google likewise instructs administrators to add other senders to the existing SPF policy rather than creating separate SPF records.

Multiple Sender Examples

These are templates. Your actual record should contain only the systems that legitimately need SPF authorization for that specific domain.

SPF Record Examples With IP Addresses

Not every mail server uses a third-party include.

Organizations running their own mail infrastructure may authorize public IP addresses directly.

Single IPv4 Address

v=spf1 ip4:192.0.2.10 -all

Multiple IPv4 Addresses

v=spf1 ip4:192.0.2.10 ip4:192.0.2.20 -all

Google Workspace and a Custom Server

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

Microsoft 365 and a Custom Server

v=spf1 include:spf.protection.outlook.com ip4:192.0.2.10 ~all

Microsoft's documentation explicitly supports combining IP mechanisms and include mechanisms in one SPF policy.

The IP addresses above are examples only. Replace them with your actual authorized public sending addresses.

What Is the Difference Between ~all and -all?

Two SPF endings appear frequently.

~all: Soft Fail

Example:

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

The tilde indicates a soft fail for senders that do not otherwise match the policy.

Google recommends ~all in its Workspace SPF setup guidance.

-all: Fail

Example:

v=spf1 include:spf.protection.outlook.com -all

The minus qualifier indicates that nonmatching senders should produce an SPF Fail result.

?all: Neutral

Example:

v=spf1 include:example.com ?all

The question-mark qualifier produces a neutral result.

It generally provides less meaningful enforcement than a properly planned soft-fail or fail policy.

Which One Should You Use?

Do not select the qualifier simply because another website says one is universally "best."

Use an SPF policy that accurately represents your infrastructure and follows your provider's current recommendations.

Before moving to a stricter policy, inventory every legitimate sender. Missing a billing platform, CRM, help desk, web application, scanner, server, or marketing platform can create authentication problems.

How to Add an SPF Record to DNS

The exact interface differs among DNS providers, but the process is generally similar.

Step 1: Identify Every Email Sender

Create an inventory of every system that sends email associated with your domain.

This might include:

• Google Workspace
• Microsoft 365
• Zoho Mail
• Transactional email services
• Marketing platforms
• CRM systems
• Help-desk software
• Website contact forms
• E-commerce platforms
• Application servers
• On-premises mail servers

Google specifically recommends identifying all senders before determining your SPF record.

Step 2: Check Existing SPF Records

Open your DNS manager and look for TXT records containing:

v=spf1

If one already exists, do not automatically add another one.

Modify the existing SPF policy to incorporate the necessary sender where appropriate.

Step 3: Obtain the Provider's Official SPF Value

Use your email provider's current documentation.

For example:

Google Workspace:
include:_spf.google.com

Microsoft 365:
include:spf.protection.outlook.com

Zoho Mail:
include:zohomail.com

SendGrid:
include:sendgrid.net

Your account-specific setup may differ, particularly for specialized domain-authentication configurations.

Step 4: Combine Required Senders

Suppose your domain uses Google Workspace and SendGrid and your configuration requires both in the same SPF policy.

You could create:

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

Step 5: Create or Update the TXT Record

A typical root-domain configuration looks like:

Some DNS providers represent the root domain differently, so follow your host's instructions.

Step 6: Save and Allow DNS to Propagate

DNS updates are not always visible everywhere immediately.

Do not repeatedly add new records because the change does not appear instantly.

Step 7: Validate the Published Policy

After propagation, check:

• Whether the TXT record is visible publicly
• Whether there is exactly one applicable SPF policy
• Whether the syntax is valid
• Whether all legitimate sending sources are covered
• Whether the DNS lookup limit is exceeded
• Whether real messages pass authentication

What Is the SPF 10 DNS Lookup Limit?

SPF has an important technical restriction: evaluation is limited to 10 DNS-query-causing terms under the SPF specification.

This matters because mechanisms such as include, a, mx, exists, and redirect can cause DNS queries.

A record may look simple:

v=spf1 include:provider1.example include:provider2.example include:provider3.example ~all

but each included provider can reference additional DNS-based mechanisms.

Therefore, three visible include mechanisms do not necessarily mean only three total DNS lookups during evaluation.

Why the Limit Matters

If SPF evaluation exceeds the permitted lookup limit, the result can become a permanent error rather than a normal pass.

This can undermine email authentication even when the record appears syntactically correct.

How to Reduce SPF Lookups

First, remove providers you no longer use.

Second, avoid unnecessary mechanisms.

Third, determine whether a service can authenticate using a dedicated sending subdomain.

Fourth, review nested includes instead of counting only the includes visible in your top-level TXT record.

Finally, do not casually "flatten" SPF records without understanding the operational consequences. Provider IP ranges can change, which means a manually flattened policy can become outdated.

Common SPF Record Mistakes to Avoid

1. Publishing Multiple SPF Records

Incorrect:

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

and:

v=spf1 include:sendgrid.net ~all

for the same SPF identity.

Instead, consolidate the required mechanisms into one policy.

2. Forgetting Third-Party Senders

Your mailbox provider may not be your only email sender.

Website forms, CRMs, ticketing systems and transactional platforms can all send email associated with your domain.

3. Copying an Example Without Understanding It

A record from another website may authorize systems you do not use or omit systems you do use.

Treat SPF examples as templates, not universal DNS values.

4. Copying Documentation IP Addresses

Never use sample IP addresses simply because they appear in an SPF tutorial.

Use the real public addresses of your authorized servers.

5. Exceeding the DNS Lookup Limit

A long chain of include mechanisms can create SPF PermError conditions.

6. Using Outdated Provider Values

Email services can change infrastructure and recommended DNS settings.

Check current official documentation before changing production DNS.

7. Assuming SPF Protects the Visible From Address by Itself

This is an important distinction.

SPF authentication is based on the SMTP identity used during message delivery rather than simply validating whatever address a recipient sees in the visible From: header.

DMARC adds alignment requirements that connect SPF or DKIM authentication with the visible From domain.

That is one reason SPF should be deployed together with DKIM and DMARC.

How Do You Check an SPF Record?

You can perform several checks after publishing your SPF policy.

Check the DNS TXT Record

Query your domain's TXT records and confirm the expected SPF value appears.

Look for Multiple SPF Policies

Search for multiple TXT values beginning with:

v=spf1

If multiple SPF policies apply to the same domain, fix the configuration instead of assuming receiving servers will merge them.

Validate the Syntax

Check that:

• The record starts with v=spf1
• Mechanisms are correctly formatted
• Provider names are correct
• The record has an appropriate ending
• There are no accidental duplicate SPF policies

Check DNS Lookup Usage

Remember to evaluate nested lookups.

The visible number of include mechanisms is not necessarily the final SPF DNS lookup count.

Send a Real Test Message

Send email to an account where you can inspect authentication results.

Look for results showing:

spf=pass

You should also inspect DKIM and DMARC results.

SPF vs DKIM vs DMARC

SPF is only one component of modern domain-based email authentication.

SPF

SPF asks, in simplified terms:

Is this sending system authorized by the SPF policy for this identity?

DKIM

DKIM adds a cryptographic signature to an email.

The receiving system retrieves a public key from DNS and uses it to validate the signature.

DMARC

DMARC builds on SPF and DKIM.

For DMARC to pass, at least one qualifying authentication method must pass with appropriate domain alignment.

A mature email authentication setup therefore normally includes:

SPF + DKIM + DMARC

rather than SPF alone.

Recommended SPF Setup Checklist

Before considering your SPF configuration finished:

1. Inventory every legitimate email sender.
2. Find the SPF policy currently published.
3. Confirm you do not have conflicting SPF records.
4. Verify every provider's current official authorization instructions.
5. Combine mechanisms only when they belong in the same SPF policy.
6. Remove obsolete senders.
7. Check the 10 DNS lookup limit.
8. Validate the final DNS record.
9. Send test messages and inspect authentication results.
10. Configure DKIM.
11. Configure DMARC.
12. Monitor authentication after infrastructure changes.

SPF Record Examples FAQ

What is an SPF record example for Google Workspace?

Google's documented Google Workspace-only example is:

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

It authorizes the sending infrastructure covered by Google's SPF policy.

What is the SPF record for Microsoft 365?

Microsoft says most Microsoft 365 organizations require:

include:spf.protection.outlook.com

A common Microsoft 365-only policy is:

v=spf1 include:spf.protection.outlook.com -all

Your final policy can differ when other legitimate systems send mail for the same domain.

What is the SPF record for Zoho Mail?

Zoho currently documents:

v=spf1 include:zohomail.com -all

Zoho also explains that ~all can be used for soft-fail behavior.

What is the SPF record for SendGrid?

Twilio SendGrid documentation provides this typical example:

v=spf1 include:sendgrid.net -all

However, SendGrid domain authentication can use account-specific records and a separate return-path subdomain, so follow the DNS records generated for your account.

Can I have two SPF records?

You should not publish multiple SPF policies for the same domain and expect them to be combined.

If multiple services need SPF authorization, consolidate the required mechanisms into one SPF record.

How do I add multiple email providers to SPF?

Place the required mechanisms in one policy.

For example:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Google documents this exact Google Workspace and Microsoft 365 combination.

Should I use ~all or -all?

~all produces SoftFail for otherwise unmatched senders, while -all produces Fail.

Choose based on your verified sending infrastructure and your provider's recommendations. Do not move to a strict policy until you are confident all legitimate senders have been accounted for.

Does SPF improve email deliverability?

Correct SPF configuration supports email authentication and can contribute to a trustworthy sending setup, but SPF alone does not guarantee inbox placement.

Deliverability also depends on factors such as DKIM, DMARC, sender reputation, complaint rates, list quality, engagement and message practices.

Does SPF stop email spoofing completely?

No.

SPF is valuable, but SPF alone does not fully protect the domain shown in the visible From header. DKIM and DMARC are important additional layers for domain authentication and anti-spoofing protection.

Where do I add an SPF record?

SPF is normally published as a DNS TXT record for the relevant domain or subdomain.

For a root domain, many DNS providers use:

@

as the host/name, but interfaces differ between providers.

External Authority Suggestions

When maintaining this page, prioritize first-party documentation from:

• Google Workspace Admin Help for Google Workspace SPF
• Microsoft Learn for Microsoft 365 SPF
• Zoho Mail Admin documentation for Zoho SPF
• Twilio SendGrid documentation for SendGrid authentication
• RFC 7208 for the SPF protocol specification

Provider documentation should be rechecked periodically because recommended DNS configurations and infrastructure can change.

Conclusion

The correct SPF record depends on who actually sends email for your domain.

For Google Workspace, the commonly documented authorization mechanism is:

include:_spf.google.com

For Microsoft 365:

include:spf.protection.outlook.com

For Zoho Mail:

include:zohomail.com

And for SendGrid, one commonly documented mechanism is:

include:sendgrid.net

The biggest mistake is treating each service as if it needs an independent SPF record. When multiple sending systems belong in the same SPF policy, their required mechanisms must be consolidated into one valid SPF record.

Before changing DNS, inventory your senders, verify each provider's current instructions, check the SPF lookup limit, and test the final configuration. Then configure DKIM and DMARC so SPF operates as part of a complete email authentication strategy.

Editorial Policy

This content is written to provide practical, technically accurate guidance about SPF and email authentication. Provider-specific values are checked against official documentation where available rather than relying solely on third-party examples.

Because email platforms can change their infrastructure and DNS requirements, readers should verify provider-specific records against current official documentation before modifying production DNS.

Examples containing placeholder domains or IP addresses are educational examples and should not be copied into a live environment without replacing them with values appropriate to the actual infrastructure.

Content Transparency Statement

This article contains configuration examples intended to explain common SPF implementations. A ready-to-copy record is safe to use only when the services represented in that record match the domain's real sending infrastructure.

SPF configuration can affect email authentication and delivery. Before removing, replacing, or enforcing an SPF policy, verify all legitimate sending sources and test the resulting configuration.

About the Author

This article was prepared using current email-authentication standards and first-party documentation from major email providers, with an emphasis on practical DNS configuration, SPF troubleshooting, sender authorization, and secure email infrastructure.

For production environments, provider-specific requirements should always be verified against the email provider's current documentation before DNS changes are deployed.