SPF for Microsoft 365 and Google Workspace: the setup that works

Microsoft 365 and Google Workspace power most organizations, and their SPF configuration is often the first one you set up. Yet it's also where many records start off on the wrong foot: a mis-copied include, two platforms mixed without method, or a lookup limit reached fast. This guide gives the correct SPF setup for each, for both together, and above all the strategy for adding your other providers without breaking your SPF.

The Microsoft 365 include

If your organization sends through Microsoft 365 (Exchange Online), your SPF must include Microsoft's record:

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

That's the official include, maintained by Microsoft. You don't list IPs by hand: Microsoft keeps the record up to date behind that include, which is exactly the point of the mechanism. End in -all if Microsoft 365 is your only sending source.

The Google Workspace include

For Google Workspace (business Gmail), the official include is:

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

As with Microsoft, Google maintains the IP ranges behind that record. Watch out for a classic mistake: you sometimes see legacy includes or hand-copied Google IP ranges — always prefer the official include:_spf.google.com, more stable and self-maintained.

Both together

Many organizations migrate, merge, or run both in parallel. In that case, a single SPF record combines both includes:

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

Remember the golden rule: one v=spf1 record per domain. If you publish a record for Microsoft and another for Google, you create a duplicate record, a source of PermError — and many receivers will ignore both. Best practice is to combine everything in a single line.

The lookup-count trap

Here's what surprises teams: these two includes, on their own, consume a lot of DNS resolutions. include:_spf.google.com unfolds into several sub-includes (_netblocks, _netblocks2, _netblocks3), about four resolutions. include:spf.protection.outlook.com consumes two or three. Put both together, and you're already at six or seven resolutions before adding a single third-party provider.

But the limit is ten. So you have only three or four resolutions left for your marketing router, your billing, your support tool… You can see why so many records tip into PermError: Microsoft and Google already occupy half the budget.

The strategy for adding your other providers

Since the budget is tight, method matters. In order of preference:

1. Split by subdomain. Keep Microsoft 365 or Google Workspace on your root domain (human email), and send marketing from news.your-domain.com and transactional from notif.your-domain.com, each with its own SPF. Each subdomain starts from an intact ten-resolution budget. It's by far the most durable strategy.
2. Favor DKIM alignment for third parties. A router that signs with aligned DKIM (d=your-domain.com) satisfies DMARC without consuming an SPF resolution. It's often the best way to integrate a provider without bloating your SPF.
3. Freeze stable-IP providers as ip4:, as a last resort, watching that they don't change.

Avoid at all costs stacking includes on the root domain "because it's simpler": it's the direct path to PermError.

A complete, real record

Take a typical company: email on Microsoft 365, marketing via a router (Brevo), billing via a business app, and a support tool that sends notifications. The temptation is to write a single catch-all line:

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com
  include:_spf.billing.com include:_spf.support.com -all

Unfold it: Microsoft ≈ 3, Brevo ≈ 1-2, billing ≈ 1, support ≈ 1, plus any sub-includes. You're at six or seven resolutions, maybe more. It "works" today, but with no margin, and the fifth tool will tip it into PermError.

The durable configuration splits the streams by subdomain:

• Root domain (company.com): v=spf1 include:spf.protection.outlook.com -all — only human email.
• news.company.com: v=spf1 include:spf.brevo.com -all — marketing, with DKIM aligned on the subdomain.
• notif.company.com: v=spf1 include:_spf.support.com -all — notifications.
• Billing, which has a single fixed IP, moves to aligned DKIM without touching SPF.

Each record stays tiny, far from the limit, and each stream can grow without threatening the others. It's more work up front than a catch-all line, but it's exactly what prevents the PermError six months later, when a fifth tool arrives unannounced.

And DMARC in all this

Configuring the Microsoft or Google include makes SPF pass, but that's only half the picture. For your domain to be genuinely protected, you also need to enable DKIM signing (in the Microsoft 365 or Google Workspace console) and publish a DMARC record. It's alignment — SPF or DKIM aligned with your From: — that makes the protection, not SPF alone. Both platforms offer their DKIM in a few clicks; don't stop at SPF. Once all three building blocks are in place, aim for p=reject on the DMARC side, so impersonation of your domain is actually refused and not merely observed.

During a migration: both, temporarily

Switching from Google Workspace to Microsoft 365 (or the reverse) is a risky moment for your SPF. During the transition, you send from both platforms: your record must therefore include both includes simultaneously.

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

Two pitfalls lurk. First, do not create two separate records "for the duration of the migration" — that's a guaranteed duplicate record, and the PermError that comes with it. Second, don't forget to remove the old platform's include once the migration is done: an orphan include consumes resolutions for nothing, and if the old service eventually closes its record, it becomes a void lookup. A clean migration therefore ends with a record cleanup, not just the mailbox switch. The right reflex: from the start, note the planned date to remove the old include, so you don't leave it lingering for months and wake up one day in PermError.

There's a subtler angle too: during the overlap, both platforms may sign with DKIM, and you'll want both aligned so DMARC stays satisfied whichever platform a given message left from. Check your aggregate reports across the migration window — they're the clearest way to confirm that neither stream silently dropped out of alignment while you were busy moving mailboxes.

The platform-specific pitfalls

A few mistakes recur with these two platforms:

• Hand-copying Google or Microsoft IPs. You break the self-maintained link and expose yourself to failures when ranges change. Stick to the official includes.
• Forgetting sending subdomains. If you send from mail.your-domain.com, that subdomain needs its own SPF — the root's SPF doesn't automatically apply to subdomains.
• Confusing SPF with DKIM/DMARC. Setting the include isn't enough: remember to enable DKIM signing on the Microsoft or Google side (via their console), and to publish your DMARC record.
• Mixing tenants. If you have several Microsoft tenants or several Google domains, each has its own configuration; don't mix their includes without checking what you're actually authorizing.

Verify your setup

Once your record is in place, check it: a single v=spf1, valid syntax, resolution count under ten, -all qualifier. Our free analyzer does all that in seconds and unfolds the Microsoft and Google includes to show you their real cost. The full process is in how to check your record. And don't forget the essential: the terminal qualifier should aim for -all (see the -all and ~all mechanisms).

Frequently asked questions

Should I use -all or ~all with Microsoft 365 / Google Workspace? Aim for -all once all your sources are listed. Microsoft and Google sometimes recommend ~all out of caution at the start, but it's not a target: a controlled domain ends in -all.

Is the Google/Microsoft include enough for DMARC? No. It makes SPF pass for the platform's email, but DMARC requires alignment with your From:. For human email, alignment is usually good; for third parties sending "in your name" through these platforms, check alignment in your reports.

Why does my SPF overflow when I only have Microsoft and a router? Because spf.protection.outlook.com plus a router that unfolds can already approach ten resolutions. Split the router onto a subdomain, or move it to aligned DKIM.

Can I put Microsoft 365 and Google Workspace on the same domain? Yes, by combining their includes in a single record. Just watch the count, since the two together already consume a good half of the budget.

Do I need to configure SPF if I already use DKIM? Yes, the two are complementary. SPF and DKIM cover different cases, and DMARC relies on one or the other aligned. Configure both — see how the three protocols work together.

Let Thomas compose your record

Combining Microsoft, Google and your third parties under the ten-lookup bar is a puzzle. Thomas, your virtual CISO, reads your real sources, composes the optimal SPF record (root and subdomains), tells you what to keep as an include, what to move to aligned DKIM, and what to isolate on a subdomain — for a clean SPF, under the limit, and aligned with DMARC.

Analyze your domain for free → or create an account for an SPF setup that holds up.