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

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

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

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

The golden rule holds: one v=spf1 record per domain. A record for Microsoft and another for Google make 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 the count already sits at six or seven resolutions before a single third-party provider joins.

But the limit is ten. That leaves only three or four resolutions for the marketing router, the billing, the support tool… Hence the number of records that tip into PermError: Microsoft and Google already occupy half the budget.

The strategy for adding the other providers

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

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

Stacking includes on the root domain "because it's simpler" is to be avoided at all costs: it's the direct path to PermError.

A complete, real record

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

Unfolded: Microsoft ≈ 3, Brevo ≈ 1-2, billing ≈ 1, support ≈ 1, plus any sub-includes. That's 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. Genuine protection also requires enabling DKIM signing (in the Microsoft 365 or Google Workspace console) and publishing a DMARC record. It's alignment — SPF or DKIM aligned with the From: — that makes the protection, not SPF alone. Both platforms offer their DKIM in a few clicks; stopping at SPF leaves the job half done. Once all three building blocks are in place, the target is p=reject on the DMARC side, so impersonation of the 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 the SPF. During the transition, mail goes out from both platforms: the record must therefore carry both includes simultaneously.

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

Two pitfalls lurk. First, two separate records "for the duration of the migration" are a guaranteed duplicate record, and the PermError that comes with it. Second, the old platform's include has to go 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: noting the planned removal date from the start, so the old include doesn't linger for months until a PermError surfaces one morning.

There's a subtler angle too: during the overlap, both platforms may sign with DKIM, and both signatures need to align so DMARC stays satisfied whichever platform a given message left from. The aggregate reports across the migration window are the clearest way to confirm that neither stream silently dropped out of alignment while the mailboxes were moving.

The platform-specific pitfalls

A few mistakes recur with these two platforms:

• Hand-copying Google or Microsoft IPs. That breaks the self-maintained link and invites failures when ranges change. The official includes are the safe route.
• Forgetting sending subdomains. Mail leaving from mail.example.com needs its own SPF on that subdomain — the root's SPF doesn't automatically apply to subdomains.
• Confusing SPF with DKIM/DMARC. Setting the include isn't enough: DKIM signing still has to be enabled on the Microsoft or Google side (via their console), and the DMARC record published.
• Mixing tenants. Several Microsoft tenants or several Google domains each carry their own configuration; their includes don't mix without a check of what's actually being authorized.

DNS propagation, not to be forgotten

An operational detail that's easy to overlook: an SPF change isn't instantaneous. Resolvers around the world cache the TXT record until its TTL expires — the change can take anywhere from a few minutes to several hours to be seen everywhere, and during that window some receivers still evaluate the old version. Before a planned change (adding an include, a migration cutover), lowering the record's TTL some time in advance makes propagation that much faster, and a rollback with it. Once things have settled, the TTL goes back to a normal value. And a change never "isn't working" in the first minute: querying several resolvers comes before touching the record again, otherwise corrections stack on top of what was merely cache delay.

Verifying the setup

Once the record is in place, four things call for a check: 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 expose their real cost. The full process is in how to check an SPF record. And the essential doesn't get forgotten: the terminal qualifier should aim for -all (see the -all and ~all mechanisms).

Frequently asked questions

-all or ~all with Microsoft 365 / Google Workspace? -all, once every source is 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 the From:. For human email, alignment is usually good; for third parties sending "in the domain's name" through these platforms, the reports are where alignment gets checked.

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. The router moves onto a subdomain, or over to aligned DKIM.

Can Microsoft 365 and Google Workspace share the same domain? Yes, by combining their includes in a single record. The count is what needs watching, since the two together already consume a good half of the budget.

Is SPF still needed when DKIM is already in place? Yes, the two are complementary. SPF and DKIM cover different cases, and DMARC relies on one or the other aligned. Both deserve configuring — see how the three protocols work together.

Thomas composes the record

Combining Microsoft, Google and the third parties under the ten-lookup bar is a puzzle. Thomas, the virtual CISO, reads the real sources, composes the optimal SPF record (root and subdomains), indicates 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 a domain for free or create an account for an SPF setup that holds up.