SPF record examples for Google Workspace, Microsoft 365 and your sending service

The short version

1. One record, many senders. If your staff mail runs on one provider and your application mail runs through a sending service, both must be authorised in the same SPF record.
2. Google Workspace only. Google documents include:_spf.google.com for Workspace.
3. Microsoft 365 only. Microsoft documents include:spf.protection.outlook.com for Exchange Online.
4. Google Workspace plus a sending service. Add the sending service's include next to Google's.
5. Microsoft 365 plus a sending service. The same idea applies.
6. Adding your own server by IP address. If you run a server that sends mail, such as a web application or an old mail server, list its address with ip4.

One record, many senders

If your staff mail runs on one provider and your application mail runs through a sending service, both must be authorised in the same SPF record. Each one adds an include, and you keep a single v=spf1 at the start and a single all at the end.

The examples below use the include values published by Google and Microsoft. Providers occasionally change these, so confirm against their current documentation before you publish.

Google Workspace only

Google documents include:_spf.google.com for Workspace. A domain that sends only through Google would publish this record.

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

This is also the right starting point if you use Gmail with your own domain.

Microsoft 365 only

Microsoft documents include:spf.protection.outlook.com for Exchange Online. A domain that sends only through Microsoft 365 would publish this.

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

If you use both providers during a migration, combine them as shown further down, and remove the old one once the move is finished.

Google Workspace plus a sending service

Add the sending service's include next to Google's. Keep a single record, with both includes before the ending.

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

Replace YOUR_SPF_HOST with the value from your MigoSMTP dashboard, or with the value from whichever service you use.

Microsoft 365 plus a sending service

The same idea applies. Two includes, one record.

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

Authenticate the sending service with DKIM as well, so DMARC can pass on the DKIM signature when SPF does not align.

Adding your own server by IP address

If you run a server that sends mail, such as a web application or an old mail server, list its address with ip4. You can add a range in CIDR form.

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

Use only addresses you control, and remove them when the server is retired.

Other mailbox providers

Other providers, such as Zoho, publish their own include values, and some have different values for different data centres. Always copy the value from the provider's own help page for your region, not from a blog post.

The pattern does not change: one record, one include per sender, one ending.

Check your lookup count

Every include counts as a lookup, and a provider's include can itself contain more includes. Google's and Microsoft's records each use several lookups internally, so combining them with a few services can reach the limit of ten faster than you expect.

Our free checker and most SPF testing tools count the lookups for you. If you are close to the limit, drop senders you no longer use, and consider sending different types of mail from different subdomains, each with its own record.

Sending from a subdomain

Many teams send marketing or transactional mail from a subdomain such as mail.yourdomain.com. The subdomain has its own SPF record, separate from the root, which keeps each record short and keeps the root clean.

Remember that DMARC applies to subdomains too, so check alignment for the subdomain's mail.

Look up a record from the command line

You can read any domain's SPF record with a DNS query. On Linux and macOS use dig, and on Windows use nslookup. Either shows the TXT records at the root, and the SPF one begins with v=spf1.

dig +short TXT yourdomain.com

If you see two records beginning with v=spf1, merge them. If you see none, publish one. Re-run the query after every change, because your DNS panel may show a value that has not spread yet.

A worked lookup count

Suppose a record contains include:_spf.google.com, include:YOUR_SPF_HOST and ip4:203.0.113.10. The ip4 costs nothing. Each include costs one lookup, plus whatever lookups sit inside that provider's own record. A provider whose record contains three further includes therefore costs four in total.

Add the totals for each include. If you land at ten or less you are fine. If you land above ten, SPF fails for everyone, so cut senders or move some mail to a subdomain before you publish.

Changing providers without a gap

When you move from one sending service to another, keep the old include in the record while you add the new one, send a small share through the new service, and remove the old include only when the old service sends nothing.

Removing it too soon means any message still going through the old service fails SPF. Our migration guides cover the same overlap approach for DNS, keys and templates.

When SPF is not enough

SPF only checks the envelope sender and breaks on forwarding, so receivers also look at DKIM and DMARC. A record that passes SPF but has no DKIM signature and no DMARC record is only partly authenticated.

Set up all three. Our DMARC guide shows how to publish a record safely and read the reports.

Further reading and sources

• RFC 7208: Sender Policy Framework (SPF)
• Google Workspace: Define your SPF record
• Microsoft: Set up SPF to help prevent spoofing

Related guides and tools

• How to create an SPF record: Syntax, examples and common errors.
• Check SPF, DKIM and DMARC: Test your domain's records.
• How to set up DMARC: Start with p=none and move to reject safely.