Microsoft 365 SPF Setup

If your organization uses Microsoft 365 for email, receivers expect your SPF record to authorize Microsoft's sending network. Microsoft documents a single include macro that covers Exchange Online datacenter IPs.

Setup is straightforward when Microsoft is your only sender. Complexity appears when you also send through HubSpot, Mailchimp, or custom SMTP relays. Each additional service must coexist in one SPF policy without duplicates or lookup overload.

Microsoft 365 does not replace SPF with DKIM. You should implement both plus DMARC for meaningful reporting and protection against header From spoofing.

The standard Microsoft 365 SPF contribution is include:spf.protection.outlook.com. That hostname expands to Microsoft's current outbound IP ranges via nested includes maintained by Microsoft. Do not hard-code Microsoft IPs unless you have an exceptional compliance requirement; the include is the supported method.

Hybrid environments using on-premise Exchange with Exchange Online must include both Microsoft and any remaining on-premise ip4 mechanisms. Connectors and third-party journaling solutions may send mail using different envelope domains—confirm which domains appear in SMTP MAIL FROM before publishing TXT records.

Microsoft Defender and anti-spoofing policies do not remove the need for public SPF at your custom domain. They protect recipients inside your tenant; SPF, DKIM, and DMARC protect how the broader internet evaluates mail claiming to be from your domain.

Incorrect Microsoft 365 SPF configuration affects every employee email and many workflow notifications. External recipients may reject or spam-folder internal alerts, invoices, and customer communication even when Microsoft 365 admin consoles show healthy mail flow.

Because Microsoft is often the first include teams add, duplicate or outdated Microsoft macros also push domains toward lookup limits that block later marketing integrations.

- Using deprecated include:spf-a.outlook.com or include:spf2.outlook.com macros from old documentation
- Publishing SPF on onmicrosoft.com while custom domains send MAIL FROM elsewhere
- Forgetting third-party Microsoft 365 connectors that send from non-Microsoft IPs