DMARC Analyzer

TL;DR

• Canonical M365 SPF record: v=spf1 include:spf.protection.outlook.com -all published as a TXT record at the apex of the sending domain. Use -all (hardfail) rather than ~all (softfail) so receivers including Gmail apply DMARC enforcement uniformly.
• Microsoft maintains the IP list. The include:spf.protection.outlook.com mechanism delegates SPF evaluation to a Microsoft-managed TXT record at spf.protection.outlook.com, which lists the ip4 and ip6 ranges of the Exchange Online outbound servers. Operators ride the central record by publishing the single include — never hardcode individual IPs.
• Third-party senders go BEFORE the Microsoft include. If you send via Mailchimp, SendGrid, Mailgun, Salesforce, or any other relay that sends AS your custom domain, prepend their include / ip4 mechanism to the SPF record before include:spf.protection.outlook.com. Each include counts against the 10-lookup cap of RFC 7208 section 4.6.4.
• Hybrid deployments need both paths. Tenants with on-prem Exchange Server flowing through an Edge Transport server or perimeter SMTP gateway need an ip4:<onprem-edge-ip-range> mechanism alongside include:spf.protection.outlook.com. Centralized Mail Transport (CMT) topology routes through on-prem; Direct-Delivery uses both paths.
• The <tenant>.onmicrosoft.com SPF trap: Exchange Online routes outbound mail with the tenant's onmicrosoft.com MAIL FROM by default. SPF passes (Microsoft's own record authorises every M365 IP) but DMARC alignment fails because the From: header organisational domain is your custom domain, not onmicrosoft.com. The fix is to set the custom domain as the primary email domain and reassign mailbox routing.
• Stay under 10 lookups. RFC 7208 section 4.6.4 caps SPF DNS lookups at 10. A bare include:spf.protection.outlook.com consumes 1 lookup (the include itself; the inner record is flat ip4 / ip6); third-party includes cost between 1 and 5 each. Verify with dig +short or the Domain Security Checker before deploying.
• Verify with four channels: (1) dig +short txt example.com, (2) dig +short txt spf.protection.outlook.com, (3) Defender portal message trace at security.microsoft.com, and (4) the Email Header Analyzer on any received message.
• Detection in DMARC aggregate (RUA) reports: the Top Source IPs table in the DMARC Analyzer Dashboard surfaces every IP claiming to send AS your domain. Microsoft 365 outbound IPs from the spf.protection.outlook.com ranges should show spf=pass; any unfamiliar IP claiming MAIL FROM=<your-domain> with spf=fail is either a forwarded message, an unauthorised relay, or a third-party sender you forgot to add to your SPF record.

1. Overview: what this guide covers

Microsoft 365 / Exchange Online is the dominant enterprise mailbox provider — Microsoft reports over 400 million paid M365 commercial seats as of 2025, with Exchange Online carrying mail for the bulk of that base. The SPF configuration for an M365 tenant looks superficially trivial: publish v=spf1 include:spf.protection.outlook.com -all at the apex of every sending domain and you are done. In practice that is the right answer for the simplest deployments — a single domain sending only via Exchange Online with no third-party services and no on-prem mail infrastructure. Most enterprise tenants are not that simple.

This page documents the SPF-specific operational surface for Microsoft 365 / Exchange Online deployments at the level operators actually encounter in production: the canonical record and why -all over ~all, the spf.protection.outlook.com include chain and its realised lookup count, the third- party-sender addition pattern for Mailchimp, SendGrid, Mailgun, Salesforce, Marketo, and other relays sending AS your custom domain, hybrid SPF for on-prem Exchange Server + Exchange Online flows with Centralized Mail Transport and Direct- Delivery topology, the <tenant>.onmicrosoft.com SPF alignment gotcha that produces the symptom "SPF passes but DMARC fails for my custom domain", the RFC 7208 section 4.6.4 10-lookup cap risk on M365 deployments with many third-party senders, PowerShell-based verification with the Resolve-DnsName cmdlet and Defender portal message trace, and the common-mistake punch list operators routinely ship in production.

Differentiation from sibling guides: DMARC for Microsoft 365 covers SPF in Step 1 at the publish-the-record level alongside DKIM and DMARC deployment; SPF Explained is the protocol-agnostic SPF pillar; SPF Lookup Limit is the 10-lookup cap deep dive applicable to every SPF deployment; Forwarding Issues with SPF covers forwarding-breaks-SPF operationally; THIS page is the focused operator-implementation walkthrough for SPF on Microsoft 365 / Exchange Online.

This guide assumes operators are already familiar with basic SPF mechanics (SPF Explained) and DMARC fundamentals (DMARC Reference). For operators starting from zero, read those pages first; for operators with a running M365 tenant debugging an SPF-related symptom, start with the Troubleshooting decision matrix in Section 10.

2. The canonical Microsoft 365 SPF record

The canonical SPF record for a tenant sending mail ONLY via Exchange Online is a single TXT record at the apex of every sending domain:

example.com.    IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Every element of that record is intentional and documented in Microsoft Learn: Set up SPF to help prevent spoofing (the canonical primary-source Microsoft documentation for SPF on Exchange Online):

• v=spf1: the mandatory SPF version tag per RFC 7208 section 4.5. The receiver MUST find this prefix to recognise the record as an SPF record.
• include:spf.protection.outlook.com: the Microsoft-managed include that delegates SPF evaluation to the central spf.protection.outlook.com TXT record. Microsoft updates this record as it adds and retires outbound IPs; tenants ride the central record by publishing the single include.
• -all: the hardfail qualifier. Any sender whose IP is NOT on the authorised list (i.e., not in any ip4 / ip6 mechanism of spf.protection.outlook.com) receives spf=fail. Receivers including Gmail, Yahoo, Microsoft 365 itself, and Apple Mail apply DMARC enforcement (quarantine or reject) uniformly on fail verdicts.

Why -all rather than ~all? Microsoft recommends -all for Microsoft 365 domains and gives the reason: it also recommends DKIM and DMARC, and the DMARC policy tells receivers what to do with messages that fail. DMARC treats -all and ~all alike, as an SPF failure. The Feb 2024 Google and Yahoo bulk-sender requirements ask for SPF, DKIM and DMARC; they do not prescribe a qualifier. Operators migrating from a legacy ~all deployment can move to -all once aggregate reports collected at p=none no longer show unknown legitimate sources.

Where do I publish it? At the apex of every domain that appears as a From: header organisational domain in mail your tenant sends. If your users send AS alice@example.com and alice@subsidiary.example.com, BOTH example.com and subsidiary.example.com need their own SPF record at the apex. Subdomain inheritance does NOT apply to SPF — every From: domain stands alone. (Subdomain inheritance DOES apply to DMARC via the sp= tag, but that is a DMARC-specific feature.) If your tenant uses a common dotted parent domain (parent.com) and several active sending subdomains (marketing.parent.com, sales.parent.com, notifications.parent.com), publish SPF separately on each one.

Publication via DNS provider UIs: Most DNS providers accept the literal SPF record body in their TXT record form. Cloudflare, Route 53, Azure DNS, GoDaddy, Namecheap, and Google Domains all support this. Some legacy providers require the body to be wrapped in double quotes; check your providers TXT record syntax. The separate SPF record type (RFC 4408 type 99) was discontinued by RFC 7208; use the standard TXT record type universally.

3. The spf.protection.outlook.com include chain

The include:spf.protection.outlook.com mechanism delegates SPF evaluation to a Microsoft-managed TXT record. To understand the realised lookup count and the IP coverage, query the record directly:

$ dig +short txt spf.protection.outlook.com
"v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"

(The exact IP ranges rotate as Microsoft adds and retires datacenter capacity; the snapshot above was captured in 2026 and the operator should run their own live dig against spf.protection.outlook.com for the current authoritative list.)

The record is flat: it contains only v=spf1, a sequence of ip4 and ip6 mechanisms, and the -all terminator. There are no nested includes, no a / mx mechanisms, no redirect, and no SPF macros. It was not always so: the record used to point on to the records spfa.protection.outlook.com and spfb.protection.outlook.com, so it cost more than one lookup. Both names still resolve, but the current record no longer uses them.

Realised lookup count: when an operator publishes include:spf.protection.outlook.com in their own record, the receivers SPF evaluator counts:

1. 1 lookup for the include:spf.protection.outlook.com mechanism itself (per RFC 7208 section 4.6.4 each include is one DNS lookup).
2. 0 additional lookups inside the include — the spf.protection.outlook.com record contains only ip4 and ip6 mechanisms which do NOT consume lookup slots.

So the Microsoft include consumes a single realised lookup. The operators 10-lookup budget is therefore 9 remaining lookups for any other mechanisms they add to the record. This is the headroom available for third-party senders.

Historical complications: an inherited SPF record may contain direct references to spfa.protection.outlook.com or spfb.protection.outlook.com, entered by hand in place of the main name, or Microsoft address ranges copied as ip4 entries (see section 9.5). Replace them with the single include:spf.protection.outlook.com: it is the only name Microsoft documents for the commercial service, and the record behind it, spf.protection.outlook.com, is the one Microsoft keeps current.

Geo-specific includes: the spf.protection.outlook.com record covers ALL Exchange Online regions globally. Microsoft does not publish region-specific SPF records (no spf-eu.protection.outlook.com / spf-us.protection.outlook.com variants) because the same outbound IPs may be used from any region depending on routing. Do NOT attempt geo-specific SPF configurations — publish the universal include and rely on Microsoft to maintain the global IP list.

4. Adding third-party senders to your Microsoft 365 SPF

Most enterprise tenants do not send mail ONLY via Exchange Online. They also use third-party services that send AS the tenants custom domain: marketing automation (Mailchimp, HubSpot, Marketo, Eloqua), transactional email (SendGrid, Mailgun, Postmark, Amazon SES), CRM (Salesforce, Microsoft Dynamics 365), survey tools (SurveyMonkey, Qualtrics), and ticketing systems (Zendesk, ServiceNow, Freshdesk). Each of these services needs to be authorised in your SPF record OR they will produce spf=fail when receivers check messages sent through them.

The canonical addition pattern is to prepend each third-party senders include or ip4 mechanism BEFORE the include:spf.protection.outlook.com mechanism, separated by single spaces. Example record for a tenant using Mailchimp and SendGrid alongside Exchange Online:

example.com.    IN  TXT  "v=spf1 include:servers.mcsv.net include:sendgrid.net include:spf.protection.outlook.com -all"

Does the order matter? Not for the result, but for the cost: receivers evaluate the mechanisms from left to right and stop at the first match, as Microsoft notes in its documentation. Put the source that sends most of your mail first. Microsoft also recommends giving services you do not control directly a subdomain with its own SPF record instead of adding them to the main domain.

4.1 Mailchimp (Intuit Mailchimp)

Sender: Mailchimp / Intuit Mailchimp — the dominant marketing-automation platform sending transactional and bulk marketing mail AS the tenants custom domain.
Why it needs SPF: Mailchimp sends from Mailchimp-owned IP ranges (198.2.128.0/18 and others), not Exchange Online IPs — receivers checking MAIL FROM=<your-domain> against your SPF record will produce spf=fail unless Mailchimp is authorised.
Canonical fix: add include:servers.mcsv.net to the SPF record. The Mailchimp documentation prescribes this include and Mailchimp maintains the central servers.mcsv.net record. As of 2026 the include consumes 1 realised lookup.

4.2 SendGrid (Twilio SendGrid)

Sender: SendGrid / Twilio SendGrid — the dominant transactional-email platform.
Why it needs SPF: SendGrid delivers from its own IP ranges (167.89.0.0/17, 168.245.0.0/17, and others) independent of Exchange Online.
Canonical fix: add include:sendgrid.net to the SPF record. SendGrid maintains the central sendgrid.net record. Counts as 2 lookups: on 12 October 2026 the record contained one nested include.

4.3 Mailgun (Sinch Mailgun)

Sender: Mailgun / Sinch Mailgun — alternative transactional-email platform.
Why it needs SPF: Mailgun sends from mailgun.org-owned IP ranges.
Canonical fix: add include:mailgun.org to the SPF record. Counts as 5 lookups: on 12 October 2026 the record pointed to two further records, one of which pointed to two more.

4.4 Salesforce

Sender: Salesforce — CRM platform that sends notification mail, marketing mail (via Marketing Cloud / Pardot), and transactional mail (via Service Cloud) AS the tenants domain.
Why it needs SPF: Salesforce sends from Salesforce-owned IP ranges that depend on the customers instance (NA / EU / AP). The instance-routing makes static IPv4 enumeration impractical.
Canonical fix: add include:_spf.salesforce.com to the SPF record. Consumes typically 1-2 realised lookups depending on instance.

4.5 Marketo (Adobe Marketo Engage)

Sender: Marketo / Adobe Marketo Engage — enterprise marketing-automation platform.
Why it needs SPF: Marketo sends from Adobe-owned IP ranges separate from Exchange Online.
Canonical fix: add include:mktomail.com to the SPF record. Adobe maintains the central mktomail.com record.

4.6 Amazon SES

Sender: Amazon SES — AWS transactional-email service.
Why it needs SPF: SES sends from amazonses.com IP ranges that depend on the AWS region.
Canonical fix: add include:amazonses.com to the SPF record. Consumes 1 realised lookup. SES also supports a DKIM-only flow where the SPF addition can be skipped if DMARC alignment relies entirely on DKIM, but the canonical deployment publishes both SPF and DKIM authorisation.

4.7 Zendesk

Sender: Zendesk — customer support / ticketing platform that sends ticket-reply mail AS the tenants support@ address.
Why it needs SPF: Zendesk sends through SendGrid backend — without an SPF authorisation the ticket replies fail SPF at the customers receiving server.
Canonical fix: add include:mail.zendesk.com to the SPF record OR rely on the existing SendGrid include if Zendesk customers share the SendGrid backend (Zendesk Enterprise plans).

4.8 HubSpot

Sender: HubSpot — marketing- automation + CRM platform.
Why it needs SPF: HubSpot sends marketing mail from HubSpot-owned IP ranges.
Canonical fix: historical pattern was include:_spf.google.com (HubSpot ran on Google Workspace backend), modern pattern is include:hubspotemail.net after HubSpot migrated to its own infrastructure around 2020. Confirm the current canonical include against the HubSpot Help Center documentation for your portal.

The eight services above cover the bulk of enterprise third-party SPF additions, but the number of includes says nothing about the number of lookups. Added to one record in full, the eight would have cost 1 + 2 + 5 + 2 + 1 + 1 + 1 + 1 = 14 lookups on 12 October 2026, and 15 with include:spf.protection.outlook.com — well over the cap. Tenants needing many services should split them across subdomains, send through Exchange Online where possible, or consider SPF flattening. See the SPF Lookup Limit deep dive.

5. Hybrid Microsoft 365 + on-prem Exchange Server SPF

A hybrid Microsoft 365 + on-prem Exchange Server deployment routes mail through BOTH Exchange Online AND the on-prem Exchange organisation depending on:

• The recipients mailbox location (on-prem mailbox vs M365 cloud mailbox).
• The migration batch state during a Cloud-Onboarding migration.
• The chosen mail routing topology (Centralized Mail Transport / Direct- Delivery / Hybrid Modern Authentication).

5.1 Centralized Mail Transport (CMT)

Centralized Mail Transport (CMT) topology routes ALL outbound mail through the on-prem Exchange organisation first. Cloud mailboxes send via Exchange Online to the on-prem Hybrid Configuration Wizard receive connector, and the on-prem Edge Transport server (or perimeter SMTP gateway) sends the mail outbound. The canonical hybrid SPF record for a CMT deployment is:

example.com.    IN  TXT  "v=spf1 ip4:198.51.100.0/29 include:spf.protection.outlook.com -all"

Where 198.51.100.0/29 is the public IP range of the on-prem Edge Transport server or perimeter SMTP gateway. Technically the include:spf.protection.outlook.com is unnecessary in pure CMT (every outbound message comes from the on-prem range), but most operators keep it for migration-state safety — during the migration any cloud mailbox that has not yet been re-routed through CMT will send directly from Exchange Online and needs the Microsoft include.

5.2 Direct-Delivery

Direct-Delivery topology lets Exchange Online send mail for cloud-hosted mailboxes directly without routing through on-prem. Mail for on-prem mailboxes still uses the on-prem Edge Transport server. The canonical SPF record must authorise BOTH outbound paths:

example.com.    IN  TXT  "v=spf1 ip4:198.51.100.0/29 include:spf.protection.outlook.com -all"

The record is identical to the CMT case above — both topologies require both ip4:<onprem> and include:spf.protection.outlook.com. The difference is purely operational: CMT funnels all outbound through one IP range, Direct-Delivery uses both paths simultaneously.

5.3 The Hybrid Configuration Wizard and DNS

The Hybrid Configuration Wizard (HCW) is the Microsoft tool that configures the on-prem Exchange Hybrid Server + the Exchange Online receive / send connectors for the hybrid deployment. The HCW does NOT update the operators public DNS — it configures the on-prem Exchange organisation and the Exchange Online side of the trust relationship, but the SPF record at the operators DNS provider is a separate manual step the operator must perform. The most common hybrid SPF mistake is finishing the HCW and forgetting to update the SPF record; cloud-mailbox outbound mail then either fails SPF (if the operator removed include:spf.protection.outlook.com) or the on-prem Edge Transport sender fails SPF (if the operator never added the on-prem IP range).

5.4 Secondary on-prem mail flows

Enterprise tenants often have additional on-prem mail-sending infrastructure beyond Exchange Server: HR systems (Workday, SAP SuccessFactors), ERP systems (SAP, Oracle, NetSuite), monitoring systems (Nagios, PRTG, SCOM sending alerts), printer / scanner / MFD devices sending Scan-to-Email, and legacy SMTP relays. Each of these sources needs to be inventoried and authorised. The canonical pattern is to consolidate them all behind a single SMTP relay (the on-prem Edge Transport or a dedicated relay like Postfix at the perimeter) and authorise the single relays IP range in the SPF record. Authorising each legacy SMTP source individually with ip4: entries costs no lookups, but it lengthens the record, makes it harder to maintain, and leaves entries behind long after the device is gone.

6. The 10-lookup cap on Microsoft 365 SPF

RFC 7208 section 4.6.4 caps the number of DNS lookups an SPF evaluation can perform at 10. The cap exists to prevent denial-of-service via deeply nested SPF records that would otherwise force the receiver to perform arbitrary DNS work for every incoming message. The cap counts:

• Each include mechanism (1 lookup each).
• Each a mechanism (1 lookup each).
• Each mx mechanism (1 lookup each).
• Each ptr mechanism (1 lookup each, plus the reverse lookup — most operators avoid ptr as it is deprecated by RFC 7208 itself).
• Each exists mechanism (1 lookup each).
• Each redirect modifier (1 lookup each).

The ip4 and ip6 mechanisms do NOT consume lookup slots — they are literal IP comparisons. The all mechanism also does not consume a lookup.

The Microsoft 365 baseline: include:spf.protection.outlook.com consumes 1 lookup (the include itself) and 0 nested lookups (the inner record is flat ip4/ip6). The operators 10-lookup budget is therefore 9 remaining lookups after the Microsoft include.

Worked example — 9 third-party senders: a tenant using Mailchimp, SendGrid, Mailgun, Salesforce, Marketo, Amazon SES, Zendesk, HubSpot, and one custom relay publishes:

example.com.    IN  TXT  "v=spf1 include:servers.mcsv.net include:sendgrid.net include:mailgun.org include:_spf.salesforce.com include:mktomail.com include:amazonses.com include:mail.zendesk.com include:hubspotemail.net ip4:198.51.100.10 include:spf.protection.outlook.com -all"

Lookup accounting: 8 third-party includes (8 lookups) + 0 lookups for ip4 + 1 lookup for the Microsoft include = 9 top-level lookups. Plus the nested lookups inside the third-party includes: on 12 October 2026 there were 1 in the SendGrid record, 4 in the Mailgun record and 1 in the Salesforce record. Total 15. A receiver that has to walk the whole record returns spf=permerror, and that result does not count for DMARC. Because evaluation stops at the first match, mail from the sources listed first may still pass while mail from those listed later does not, which makes the fault look random.

How to verify your realised count:

1. Run a recursive SPF resolver tool. The Domain Security Checker at domain_checker.php on this site runs the full SPF chain via includes/DnsChecker.php and surfaces the realised lookup count.
2. Or run dig +short txt example.com and then recursively dig +short txt <each-included-domain> — counting every include, a, mx, ptr, exists, and redirect encountered.
3. Or do the same in PowerShell with Resolve-DnsName, name by name. Microsoft 365 has no cmdlet that manages or tests the SPF record of your domain; the record lives at your DNS provider, so query the TXT records directly:

PS> Resolve-DnsName -Type TXT -Name example.com | Where-Object {$_.Strings -like 'v=spf1*'}
PS> Resolve-DnsName -Type TXT -Name sendgrid.net | Where-Object {$_.Strings -like 'v=spf1*'}

Mitigations when over the cap:

• SPF flattening: replace third-party includes with direct ip4 / ip6 ranges. Tools like SPFLab and EasyDMARC automate the flattening; the trade-off is the operator must re-flatten regularly as senders update their IP ranges. Most operators avoid manual flattening because of the maintenance burden.
• Consolidate via Exchange Online as a relay: configure third-party services to send through Exchange Online via SMTP AUTH or via a connector. All outbound mail then comes from Exchange Online IPs and consumes only the single Microsoft include. Trade-off: operators must configure each third-party service to use Exchange Online as a relay, and Exchange Online receive connectors require a service account or certificate-based authentication.
• Subdomain partitioning: publish separate SPF records on different subdomains for different sending services. For example, marketing.example.com publishes v=spf1 include:servers.mcsv.net include:mktomail.com -all for marketing-mail-only senders and transactional.example.com publishes v=spf1 include:sendgrid.net include:amazonses.com -all. Each subdomain has its own 10-lookup budget. The operator must then configure each third-party service to use the correct subdomain in MAIL FROM.

See the SPF Lookup Limit deep dive for the full treatment of the cap and its mitigations.

7. The <tenant>.onmicrosoft.com SPF gotcha

Every Microsoft 365 tenant is assigned a default routing domain of the form <tenant>.onmicrosoft.com at tenant creation. The onmicrosoft.com parent domain is owned and operated by Microsoft; it publishes its own SPF record that authorises every M365 outbound IP. The <tenant>.onmicrosoft.com name inherits Microsofts SPF via the parent record. SPF passes for any message with MAIL FROM <user>@<tenant>.onmicrosoft.com.

The gotcha is that Exchange Online routes outbound messages with the <tenant>.onmicrosoft.com MAIL FROM by default, even when the user has added a custom domain (example.com) to the tenant and is sending mail with From: header alice@example.com. The symptoms operators see:

• SPF passes (Microsofts own record authorises every M365 IP).
• DKIM passes IF the tenant has configured DKIM for the custom domain.
• DMARC fails with spf-aligned=fail because the MAIL FROM domain (<tenant>.onmicrosoft.com) does NOT align with the From: header organisational domain (example.com).
• If DKIM is aligned, DMARC may still pass via DKIM alignment alone. If DKIM is NOT aligned, DMARC fails entirely.

The aggregate (RUA) report symptom is: spf=pass against <tenant>.onmicrosoft.com but aligned-spf=fail against the custom domain. The same source IP. The same message. SPF is "passing" but DMARC fails. This pattern is the dominant DMARC failure mode for tenants that have not properly configured the custom domain as the primary email domain.

7.1 Why does this happen?

Three causes converge:

1. The default routing domain assignment. Newly created mailboxes are assigned <user>@<tenant>.onmicrosoft.com as the primary email address until the custom domain is set as primary.
2. Service accounts and shared mailboxes. These often remain on onmicrosoft.com because they were created before the custom domain was added or because no operator explicitly switched them.
3. App-only authentication. Applications using OAuth or SMTP AUTH with service-account credentials may send AS the service accounts onmicrosoft.com address even when the application is configured to use a custom From: header.

7.2 How to fix it

The canonical fix is to set the custom domain as the primary email domain in the tenant AND reassign every mailboxs primary email address to the custom domain:

PS> Connect-ExchangeOnline
PS> Set-Mailbox -Identity alice@contoso.onmicrosoft.com `
        -PrimarySmtpAddress alice@example.com `
        -EmailAddresses @{Add="smtp:alice@contoso.onmicrosoft.com"}

This sets the custom domain (example.com) as the primary address while keeping the onmicrosoft.com address as an alias (so existing app integrations continue to work). After running this command, the mailbox sends with MAIL FROM alice@example.com and DMARC alignment succeeds.

For service accounts and shared mailboxes, repeat the same pattern. For app-only senders, verify the application is configured to use the custom domain as the From: address AND that any SMTP AUTH credentials use a mailbox whose primary address is on the custom domain.

7.3 How to detect the pattern in aggregate reports

The DMARC Analyzer Dashboard surfaces the per-source-IP / per-MAIL-FROM breakdown in the Top Source IPs table and the Auth Results column. The <tenant>.onmicrosoft.com pattern shows up as:

• Source IP in the spf.protection.outlook.com ranges (Microsoft outbound IPs).
• SPF result pass against <tenant>.onmicrosoft.com.
• SPF-aligned result fail against the published custom domain.
• DKIM result pass against the custom domain (if DKIM is configured).
• DMARC verdict depends on DKIM alignment — if DKIM aligns, DMARC passes; if not, DMARC fails.

Click any row in the dashboard to see the per-record breakdown showing the MAIL FROM domain explicitly.

8. Verification workflow

The canonical four-step verification for Microsoft 365 SPF works for any tenant regardless of size or topology:

8.1 Step 1: Verify the record is published

From any workstation with dig (Linux / macOS / WSL) or nslookup (Windows):

$ dig +short txt example.com
"v=spf1 include:spf.protection.outlook.com -all"

Or in PowerShell using the Resolve-DnsName cmdlet (Windows 10/11 and Windows Server):

PS> Resolve-DnsName -Type TXT -Name example.com | Where-Object {$_.Strings -like 'v=spf1*'}

Verify (a) exactly one SPF record exists (multiple SPF records on the same domain produce spf=permerror per RFC 7208 section 4.5), (b) the record contains include:spf.protection.outlook.com, and (c) the record terminates with -all (or ~all during migration).

8.2 Step 2: Verify Microsofts include chain

$ dig +short txt spf.protection.outlook.com
"v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"

Confirm the record resolves (no NXDOMAIN or SERVFAIL) and contains the expected flat ip4 / ip6 enumeration. Microsoft retires and adds ranges over time; the exact IPs you see may differ from the snapshot above.

8.3 Step 3: Microsoft 365 message trace

Send a test message from your tenant to an external mailbox (a Gmail or Yahoo account you control is ideal). Then in the Defender portal at security.microsoft.com:

1. Navigate to Email & collaboration > Exchange message trace.
2. Search for the test message by sender, recipient, or subject.
3. Click the message to open the detailed view.
4. Confirm that the message was delivered externally and by which route it left. The SPF result itself is recorded by the receiver: look for spf=pass smtp.mailfrom=<your-domain> in the headers of the received message (step 4).

8.4 Step 4: Email Header Analyzer

Inspect the actual message headers as the receiver saw them. Open the test message in Gmail / Yahoo / Apple Mail and view the raw source headers (View Original / Show Original). Paste the headers into the Email Header Analyzer at header_analyzer.php on this site — it parses the full Authentication-Results stack via includes/EmailHeaderParser.php and surfaces the SPF, DKIM, DMARC, and ARC verdicts in human-readable form. Confirm SPF passes against the expected MAIL FROM domain.

8.5 Step 5: Domain Security Checker (live lookup count)

The Domain Security Checker at domain_checker.php on this site runs the full SPF chain via includes/DnsChecker.php and surfaces the realised lookup count. This is the canonical way to check you remain under the 10-lookup cap of RFC 7208 section 4.6.4. The tool also detects multiple SPF records (the spf=permerror cause documented in SPF permerror vs temperror), missing -all terminators, and deprecated ptr mechanisms.

9. Common Microsoft 365 SPF mistakes

9.1 Multiple SPF records on the same domain

Publishing two TXT records both starting with v=spf1 on the same domain produces spf=permerror per RFC 7208 section 4.5. The most common cause is operators publishing one SPF record for Exchange Online and a second SPF record for a third-party sender, intending to "combine" them but creating two records instead of one merged record. The fix is to delete one record and merge all mechanisms into a single record. Verify with dig +short txt example.com — exactly one line beginning with v=spf1 should appear.

9.2 Using ~all when -all is required

Soft-fail (~all) asks receivers to accept mail from unauthorised sources but mark it; hard-fail (-all) asks them to reject it. What actually happens depends on the receiver. Microsoft recommends -all for Microsoft 365 domains and notes that DMARC treats both results as an SPF failure. The Feb 2024 Google and Yahoo bulk-sender requirements do not prescribe a qualifier. The mistake is therefore not ~all as such, but leaving it in place with no plan to move to -all and without the DKIM and DMARC that actually protect the domain.

9.3 Publishing the SPF record on the wrong name

The SPF record MUST be published at the apex of each From: domain (example.com), not on a subdomain intended for sending (e.g., mail.example.com — that would only authorise mail with MAIL FROM in the mail. subdomain). The most common variant of this mistake is publishing the SPF record at _spf.example.com or spf.example.com by analogy with DKIMs _domainkey convention. SPF does not use a label prefix — publish directly at the apex.

9.4 Improper TXT record quoting

Some DNS providers require the SPF body to be enclosed in double quotes; others apply quoting automatically. The dangerous form is "v=spf1" "include:spf.protection.outlook.com" "-all", three separate strings in one record. RFC 7208 joins such strings with no space between them, so the receiver sees one unbroken token and the record is no longer a valid SPF record. Publish a single quoted string: "v=spf1 include:spf.protection.outlook.com -all". If a record is longer than 255 characters and has to be split, the space must sit inside one of the strings.

9.5 Hardcoding Microsoft IP ranges in ip4:

Tempting shortcut: replace include:spf.protection.outlook.com with a hardcoded ip4:40.92.0.0/15 ip4:40.107.0.0/16 ... list to "save lookups." This breaks the moment Microsoft adds a new IP range — every legitimate Exchange Online message from the new range fails SPF. Never hardcode Microsoft IPs. The include mechanism delegates IP maintenance to Microsoft; that delegation is the entire point of the central spf.protection.outlook.com record.

9.6 Forgetting to add third-party senders

After deploying Mailchimp / SendGrid / Salesforce / etc. for a marketing campaign or transactional flow, operators commonly forget to update the SPF record. The senders mail deploys, the third-party service sends from its own IPs, and receivers return spf=fail — driving the marketing mail into spam folders. The fix is to add the include BEFORE the campaign launches. Use the Domain Security Checker to verify the SPF record contains the expected includes for every active third- party service.

9.7 Removing include:spf.protection.outlook.com during hybrid migration

During an on-prem-to-cloud migration, operators sometimes remove include:spf.protection.outlook.com "because all mail flows through on-prem now." But some cloud-hosted mailboxes are still delivering directly via Exchange Online (the HCW transition state). Their outbound mail starts failing SPF. The safe pattern is to keep include:spf.protection.outlook.com in the SPF record throughout the migration and only consider removing it years after 100% of mail flow has been confirmed routed through on-prem via aggregate (RUA) report analysis.

10. Troubleshooting decision matrix

Symptom-to-cause lookup table for the common Microsoft 365 SPF issues operators encounter:

For symptoms not covered above, start with the Email Header Analyzer on a representative failing message to see the full Authentication- Results stack, then drill into the matching section above.

11. Real-world examples

11.1 Startup with only Exchange Online (10 employees)

A 10-person startup uses Microsoft 365 Business Basic. All outbound mail flows through Exchange Online. No third-party senders. The canonical SPF record is simply:

example.io.    IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Realised lookup count: 1. Room for 9 more if needed. SPF deployment time: 5 minutes including DNS propagation verification.

11.2 SaaS company with marketing automation (200 employees)

A SaaS company uses Exchange Online for employee mail, Mailchimp for newsletters, SendGrid for transactional product notifications, and Salesforce for sales outreach. Canonical SPF record:

example.com.    IN  TXT  "v=spf1 include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com include:spf.protection.outlook.com -all"

Top-level lookups: 4. On 12 October 2026 the SendGrid record and the Salesforce record each added one nested lookup, bringing the total to 6. Under the 10-lookup cap, with room for a few more services.

11.3 Enterprise hybrid deployment (5000 employees)

A 5000-employee enterprise runs a hybrid Exchange Server 2019 + Exchange Online deployment with Centralized Mail Transport (CMT). Mail flows: cloud mailboxes send via Exchange Online to the on-prem Edge Transport server at 198.51.100.0/29, which delivers outbound. The company also uses Marketo for enterprise marketing, ServiceNow for ITSM ticket notifications, and Workday for HR notifications. Canonical SPF record:

example.com.    IN  TXT  "v=spf1 ip4:198.51.100.0/29 include:mktomail.com include:servicenowservices.com include:_spf.workday.com include:spf.protection.outlook.com -all"

Realised top-level lookups: 4 (one ip4 + three third-party includes + Microsoft include — ip4 does not count). Nested lookups inside the third-party includes typically add 3-5 more, bringing the total to 7-9. At the edge of the cap; the operator must monitor the lookup count quarterly and consider subdomain partitioning if any additional senders are added.

11.4 Migration: on-prem Exchange to M365 (Wave 5)

An organisation is migrating from on-prem Exchange Server 2016 to Microsoft 365. Wave 5 of the migration includes the Marketing team (50 mailboxes). Before the migration the SPF record was:

example.org.    IN  TXT  "v=spf1 ip4:203.0.113.0/29 -all"

After Wave 5 the SPF record must authorise BOTH the legacy on-prem IP range AND the Exchange Online range for the migrated mailboxes that may send directly:

example.org.    IN  TXT  "v=spf1 ip4:203.0.113.0/29 include:spf.protection.outlook.com -all"

After the migration is fully complete (all mailboxes confirmed cloud-hosted and on-prem Exchange decommissioned), the ip4:203.0.113.0/29 mechanism can be removed.

12. Frequently asked questions

What is the canonical SPF record for Microsoft 365?

The canonical SPF record for a Microsoft 365 / Exchange Online tenant that sends mail ONLY via Exchange Online is v=spf1 include:spf.protection.outlook.com -all published as a TXT record at the apex of the sending domain. The include:spf.protection.outlook.com mechanism delegates SPF evaluation to the Microsoft-managed spf.protection.outlook.com record, which currently expands to roughly six ip4 ranges and one ip6 range covering every Exchange Online outbound IP — Microsoft maintains the record and adds new IPs as the service grows, so the operator never has to track individual IP addresses. The -all qualifier hardfails any sender whose IP is not on the Microsoft list. Use -all rather than ~all (softfail) so receivers including Gmail apply DMARC enforcement uniformly; Microsoft itself recommends -all in the canonical Microsoft Learn documentation. Operators sending via third-party services (Mailchimp, SendGrid, Salesforce) must add those services BEFORE the include:spf.protection.outlook.com mechanism, watching the 10-lookup cap of RFC 7208 section 4.6.4.

Why does Microsoft 365 use include:spf.protection.outlook.com instead of an ip4 range?

Microsoft 365 / Exchange Online runs on a large and dynamic IP pool that changes as Microsoft scales the service, adds Azure regions, and migrates customers between datacenters. A hardcoded ip4 mechanism would require every tenant operator to manually update the SPF record every time Microsoft added or retired an outbound IP — an operational impossibility at the scale of hundreds of millions of M365 mailboxes. The include:spf.protection.outlook.com mechanism delegates SPF evaluation to a Microsoft-managed TXT record at spf.protection.outlook.com that Microsoft updates centrally. Tenants ride the central record by publishing a single include mechanism. The trade-off is that the spf.protection.outlook.com record currently consumes roughly 4 of the 10 RFC 7208 section 4.6.4 lookup slots (the include itself + the ip4/ip6 mechanisms inside expand to one lookup each up to the 10- lookup cap), so operators adding third-party senders must budget the remaining 6 slots carefully.

How do I add Mailchimp or SendGrid to my Microsoft 365 SPF record?

Add the third-party senders include BEFORE the include:spf.protection.outlook.com mechanism, separated by a single space. Example: v=spf1 include:servers.mcsv.net include:sendgrid.net include:spf.protection.outlook.com -all adds Mailchimp (servers.mcsv.net) and SendGrid (sendgrid.net) while keeping Exchange Online authorised. Each include costs at least one DNS lookup against the RFC 7208 section 4.6.4 10-lookup cap, and nested includes count as well: on 12 October 2026 servers.mcsv.net cost 1 lookup and sendgrid.net cost 2, so the record above cost 4 in total with the Microsoft include. Run the live SPF lookup count via dig +short or via the Domain Security Checker domain_checker.php tool BEFORE deploying to verify you remain under the 10-lookup cap. If the count exceeds 10 receivers including Gmail and Microsoft return spf=permerror and DMARC alignment fails.

What is the spf.protection.outlook.com lookup count?

The spf.protection.outlook.com record currently consumes approximately 4 of the 10 RFC 7208 section 4.6.4 lookup slots as of 2026 (the actual realised count varies as Microsoft updates the record). The chain is: the operator publishes include:spf.protection.outlook.com — that is 1 lookup. Microsoft resolves the spf.protection.outlook.com TXT record — that is the cost of the include itself (counted). The spf.protection.outlook.com record begins with v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 -all (the IP list rotates as Microsoft updates) and contains only ip4 / ip6 / -all mechanisms which do NOT consume additional lookups. So the M365 include itself is operationally close to a single- lookup cost. The record used to point on to the records spfa.protection.outlook.com and spfb.protection.outlook.com and cost more than one lookup; today it is flat. Operators should still run the live count via dig +short or domain_checker.php to verify current behaviour.

What is the onmicrosoft.com SPF problem?

Every Microsoft 365 tenant is assigned a default <tenant>.onmicrosoft.com routing domain. When operators add a custom domain (example.com) to the tenant but do not properly configure outbound mail to send AS the custom domain, Exchange Online routes outbound messages with MAIL FROM <user>@<tenant>.onmicrosoft.com — even though the visible From: header is <user>@example.com. The SPF check at the receiver authenticates the MAIL FROM domain, which is <tenant>.onmicrosoft.com — that lookup resolves to Microsofts onmicrosoft.com record which is permissive of all M365 IPs, so SPF passes. But DMARC alignment requires the MAIL FROM domain to align with the From: header organisational domain, and onmicrosoft.com does NOT align with example.com — DMARC fails with spf-aligned=fail. The symptom is "SPF passes but DMARC fails for my custom domain" in aggregate reports. The fix is to configure the custom domain as the primary email domain in the tenant and to set the default routing per-mailbox so MAIL FROM matches the From: header. Mailboxes assigned the onmicrosoft.com address by default require explicit reassignment via Set-Mailbox -EmailAddresses or the Exchange Admin Center.

How do I configure SPF for a hybrid Microsoft 365 + on-prem Exchange deployment?

A hybrid Microsoft 365 + on-prem Exchange Server deployment routes mail through both Exchange Online AND the on-prem Exchange organisation depending on the recipients mailbox location, the migration batch state, and the chosen mail routing topology (Centralized Mail Transport vs Direct-Delivery). The SPF record must authorise BOTH outbound paths. The canonical hybrid SPF record is v=spf1 ip4:<onprem-edge-ip-range> include:spf.protection.outlook.com -all where <onprem-edge-ip-range> is the public IP or /29 range of the on-prem Exchange Edge Transport server or perimeter SMTP gateway. Centralized Mail Transport (CMT) topology routes all outbound mail through the on-prem Exchange organisation first — in that case the on-prem IP range is the EXCLUSIVE sending source and the include:spf.protection.outlook.com is technically unnecessary, but most operators keep it for migration- state safety. Direct-Delivery topology lets Exchange Online send mail for cloud-hosted mailboxes directly without routing through on-prem — in that case BOTH ip4:<onprem> and include:spf.protection.outlook.com are required. The Hybrid Configuration Wizard does NOT update the operators public DNS; the SPF update is a manual step the operator must perform at the DNS provider.

How do I verify my Microsoft 365 SPF record is working?

Run a four-step verification: (1) dig +short txt example.com — confirms the record is published at the apex with v=spf1 include:spf.protection.outlook.com -all (or your hybrid variant). (2) dig +short txt spf.protection.outlook.com — confirms Microsofts include chain resolves and shows the current ip4 / ip6 ranges. (3) Microsoft 365 message trace via the Defender portal at security.microsoft.com > Email & collaboration > Exchange message trace, search for a message you sent, click the message, look for the SPF result in the Authentication-Results header in the message details — should show spf=pass smtp.mailfrom=<your-domain>. (4) PowerShell from a workstation with the ExchangeOnlineManagement module installed: Connect-ExchangeOnline; Get-AcceptedDomain — confirms the domain is registered to the tenant. The Domain Security Checker domain_checker.php tool runs the same DNS lookups through includes/DnsChecker.php and surfaces the live realised lookup count, helping you spot the 10-lookup cap risk early. The Email Header Analyzer header_analyzer.php parses any pasted Authentication-Results header and surfaces the SPF, DKIM, DMARC, and ARC verdicts in human-readable form.

Does Microsoft 365 support SPF macros like %{i} or %{s}?

Microsoft 365 / Exchange Online publishes a spf.protection.outlook.com record that does NOT use SPF macros — the record contains only literal ip4 and ip6 mechanisms. SPF macros (defined in RFC 7208 section 7) including %{i} (sending IP), %{s} (sender local- part), %{d} (sender domain), %{p} (validated domain name) are receiver-side evaluation features rather than sender-side authorisation features, and Microsoft as a sender publishes a macro-free record. Operators authoring their own SPF records for Exchange Online deployments should avoid SPF macros in the include chain — most third- party email reputation services and SPF-checking tools handle the basic macro set but compatibility is uneven and macros add operational complexity for limited benefit. The exception is the %{i} macro in the exists mechanism for catch-all senders, which is a niche pattern used by some forensic-SPF deployments but not recommended for general Exchange Online use.

What is the difference between -all and ~all on a Microsoft 365 SPF record?

The -all qualifier produces spf=fail for any sender whose IP is not on the authorised list — receivers including Gmail, Microsoft 365, Yahoo, and Apple treat -all the same as a hardfail and apply DMARC enforcement (quarantine or reject) accordingly. The ~all qualifier produces spf=softfail — receivers may accept the message with reduced trust, may quarantine, or may treat softfail equivalently to fail depending on the receivers spam- filter policy. Microsoft itself recommends -all in the canonical Microsoft Learn documentation for Exchange Online tenants because the spf.protection.outlook.com record covers every legitimate Exchange Online outbound IP — any other source is by definition not the tenants outbound mail and SHOULD be hardfailed. Tenants migrating from a legacy on-prem Exchange organisation or running a hybrid deployment may temporarily use ~all during migration to avoid hardfailing mail from unmigrated mail flows, but should graduate to -all as soon as all senders are inventoried and added to the SPF record. The Feb 2024 Google and Yahoo bulk-sender requirements ask for SPF, DKIM and DMARC and do not prescribe -all or ~all.

13. Related guides

• SPF Explained — the protocol-agnostic SPF pillar covering record syntax, all eight mechanisms, qualifiers, and the result-code semantics receivers apply.
• SPF mechanisms explained (per-directive reference) — the M365-TENANT-SEMANTIC-MECHANISM-INPUT companion documenting the eight RFC 7208 §5 SPF mechanisms (all, include, a, mx, ptr, ip4, ip6, exists) whose per-mechanism evaluation semantics determine how a Microsoft 365 tenant's canonical v=spf1 include:spf.protection.outlook.com ~all record actually resolves on the receiver side. Where THIS M365 deployment guide tells you the canonical posture (the include:spf.protection.outlook.com macro envelope Microsoft maintains covering Exchange Online Protection's per-region egress IP ranges, with ~all as the SoftFail- terminator EOP recommends) and the spf_qualifiers_explained sibling below tells you which +/-/~/? PREFIX to attach to each entry, the mechanisms reference tells you WHY each MECHANISM TOKEN evaluates the way it does: the include: mechanism is a recursive macro that imports the included domain's SPF record into the current evaluation scope (so include:spf.protection.outlook.com expands at evaluation time to whatever Exchange Online Protection's current per-region egress IP ranges are — Microsoft manages the macro's contents dynamically; the publishing tenant doesn't need to rotate when EOP adds an egress region); the ~all terminator's SoftFail semantics (RFC 7208 §2.6.5) — EOP's Connection Filtering treats SoftFail as SCL=5 (junk folder) rather than SCL=9 (hard reject the -all Fail terminator triggers); the a / mx / ip4 / ip6 mechanism semantics for M365 hybrid tenants supplementing the EOP-managed include with on-prem Exchange Server or third-party ESP egress IPs; the ptr mechanism's deprecation (RFC 7208 §5.5 SHOULD NOT — M365 tenants must never use ptr); and the exists mechanism's macro-expansion semantics for advanced per-sender SPF policies. Read the mechanisms reference when REASONING about the EOP macro envelope's per-mechanism resolution path — distinct from the qualifiers reference below (which documents the +/-/~/? PREFIX grammar determining EOP's enforcement strength per entry) and the dns_syntax reference further below (which documents the byte-level TXT-record encoding rules).
• SPF qualifiers explained (+, -, ~, ?) — the focused deep dive on the four RFC 7208 §4.6.2 qualifier prefixes whose choice determines how Microsoft 365 Exchange Online Protection (EOP) enforces SPF failures against your tenant's outbound and inbound mail. The canonical M365-recommended record posture terminates with ~all (SoftFail per RFC 7208 §2.6.5) — EOP's own Connection Filtering policy treats SoftFail as "deliver to junk folder with SCL=5" while -all (Fail per §2.6.4) triggers EOP's hard-reject path (SCL=9, SMTP 550 5.7.23 rejection at the Exchange receive connector). The qualifiers page documents the ~all-vs--all decision in the broader receiver- enforcement context (Gmail / Yahoo / Apple all align with EOP's broad SoftFail-friendly posture), the per-mechanism qualifier prefix overrides that let you mark specific include: chains as Pass (+include:spf.protection.outlook.com) while leaving other senders at the record-default qualifier, and the +all footgun (Pass-for- everything — devastatingly common misconfiguration after a copy-paste of an ESP-provided example record). Read the qualifiers page when designing your final EOP-bound SPF posture: the M365 deployment workflow on this page selects WHICH includes / IPs / third-party senders belong in the record, the qualifiers page documents WHICH enforcement strength each of those entries should carry to achieve your tenant's intended SoftFail-vs-Fail enforcement posture.
• SPF DNS record syntax explained — the focused RFC 7208 section 3 byte-level DNS-record reference governing how the Microsoft 365 SPF policy is encoded as a TXT record at the publishing apex: the mandatory v=spf1 version tag, the TXT record type (no legacy SPF type 99 publication — the November 2014 deprecation of DNS RR type 99 in RFC 7208 §3.1 means Microsoft 365 + every modern receiver ignores SPF type 99 publication entirely), the 255-octet DNS character-string limit and the multi-string concatenation rule (when your M365 SPF record approaches 255 octets — a near-certainty once you chain include:spf.protection.outlook.com with 2–3 third-party senders — the record must be split into multiple quoted strings within the same TXT RDATA, NOT into multiple TXT records — publishing two SPF records returns PermError per §4.5), the "exactly one SPF record per domain" rule (M365 tenants accidentally publishing a second SPF record alongside the first — e.g. after adding a marketing-vendor record — trigger receiver-side PermError and lose ALL SPF authentication on that domain), whitespace and case-sensitivity rules (v=spf1 case-sensitive version tag, mechanism tokens case-insensitive, domain-spec case-insensitive per DNS), apex vs subdomain publication semantics (M365 deployments need SPF at EVERY sending subdomain explicitly — wildcard TXT records do NOT cover apex), and wildcard TXT handling. Read the SPF DNS record syntax page when AUTHORING the M365 SPF record byte-by-byte: this M365 deployment guide tells you WHICH include: chains and IP4/IP6 mechanisms belong in the record, the syntax page tells you HOW to encode them as a syntactically valid TXT record — the byte-level encoding rules whose violation causes receiver-side PermError even when every semantic mechanism is correct.
• SPF Lookup Limit — the 10-lookup cap of RFC 7208 section 4.6.4, the canonical causes (deeply nested includes, recursive Salesforce expansion, Microsoft 365 + 8+ third-party senders), and the mitigations (flattening, subdomain partitioning, relay consolidation).
• SPF permerror vs temperror — the focused diagnostic deep dive on the two SPF error result codes, the seven canonical permerror causes and the three canonical temperror causes, with the cause-specific resolution playbook beside each.
• Forwarding issues with SPF — the operational deep dive on why forwarding breaks SPF (first-hop authentication model, second SMTP hop), the four canonical forwarding scenarios, SRS (Sender Rewriting Scheme), and ARC (Authenticated Received Chain) — the IETF receiver-side answer that Microsoft 365 validates.
• include vs ip4 vs a vs mx (SPF mechanism decision tree) — the M365-TENANT-MECHANISM-SELECTION-DECISION-TREE companion documenting the per-mechanism trade-off matrix for Exchange-Online tenants choosing between include:, ip4:, a:, and mx: mechanism tokens when authoring or extending their SPF record. The canonical M365 posture (v=spf1 include:spf.protection.outlook.com -all) uses include: exclusively for the EOP-managed egress pool, but tenants regularly need to add SUPPLEMENTARY mechanisms for non-EOP senders: hybrid Exchange on-prem servers (ip4: when the on-prem edge has a static public IP, or a: when DNS A-records track edge-pool membership), third-party ESPs (include: for the ESP's per-vendor macro), legacy SMTP relays used for non-mailbox-traffic (ip4:), and partner-domain co-tenants (include: via the partner's apex). The decision-tree page documents the four key trade-off axes: (1) DNS-lookup-budget impact — the include:spf.protection.outlook.com macro consumes 1 published lookup (EOP flattens its egress pool internally, so the publishing tenant sees only the outer lookup); raw ip4: literals consume 0 lookups; a: / mx: each consume 1 lookup plus all resolved A/MX hosts (a hidden budget-blow-up vector for tenants chaining many a: entries because of EOP's strict RFC 7208 §4.6.4 10-lookup enforcement — exceeding it triggers PermError and EOP marks every message Fail at the connector); (2) rotation-frequency impact — the EOP-managed macro auto-updates when Microsoft adds an egress region; raw ip4: literals require operator-led DNS edits per IP rotation (typically an on-prem-edge IPv4-pool ISP-rotation event); (3) granularity — include: is all-or-nothing per included domain, ip4: targets a single host or CIDR, a:/mx: sit between; (4) receiver-side-evaluation- determinism — raw ip4: evaluates deterministically at receiver send-time (no DNS-lookup variance possible); include: / a: / mx: all evaluate against then-current DNS state (drift between publisher and receiver caches is possible during the propagation window after an upstream record change). Read the decision-tree page when designing an Exchange-Online tenant SPF record that SUPPLEMENTS the canonical include:spf.protection.outlook.com EOP-managed macro with hybrid-Exchange, third-party-ESP, or relay-host additional senders — the decision-tree documents the per-mechanism trade-off matrix the M365-tenant operator must navigate to select the right mechanism token for each supplementary sender.
• Why SPF alone is insufficient — the authoritative answer to "why DMARC if I have SPF" covering the From: header spoofing gap, the forwarding gap, the mailing-list gap, and the DKIM + DMARC layered defense.
• DMARC for Microsoft 365 (deployment guide) — the full DKIM + DMARC + Trusted ARC Sealers deployment walkthrough for Microsoft 365 / Exchange Online.
• DMARC for Google Workspace (deployment guide) — the sibling Google Workspace deployment walkthrough. Useful for operators running multi-tenant organisations or hybrid Workspace+M365 flows.
• DKIM for Microsoft 365 — the SAME-PROVIDER DKIM-SIDE COMPANION to this SPF-side Exchange Online deployment guide. Where this page documents the M365-side SPF posture (v=spf1 include:spf.protection.outlook.com -all, the spf.protection.outlook.com macro envelope Microsoft maintains, the realised-lookup- count budget, M365's per-route SPF behaviour including Centralized Mail Transport and Direct-Delivery hybrid topologies), the DKIM-side spoke documents the parallel DKIM signing posture for the same tenant (Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, the two selector1._domainkey.<domain> and selector2._domainkey.<domain> CNAME records pointing to selector1-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com and selector2-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com, the Microsoft-managed dual-selector ~6-month rotation cadence, the onmicrosoft.com signing-domain gotcha where Exchange Online's default DKIM signing identity is <tenant>.onmicrosoft.com before custom DKIM is activated — which PASSES DKIM verification but does NOT align with the From-header organisation domain and therefore FAILS DMARC alignment despite the green DKIM verdict). M365 operators reading this SPF-side guide for the dual-auth setup need the DKIM-side spoke to complete the BEFORE-DMARC-ENFORCEMENT signing-posture work — DMARC requires EITHER SPF-aligned OR DKIM-aligned but operators SHOULD deploy both for forwarding-tolerance (SPF breaks on forwarding when the forwarder rewrites envelope MAIL FROM without SRS; DKIM survives most forwarding because the signature travels in the message headers). This is the FIRST M365 cross-protocol bridge from this SPF-side guide to the DKIM-side procedural sibling — operators landing here for SPF setup need the DKIM-side procedural deep dive to complete the dual-auth Exchange Online deployment.
• DKIM for Google Workspace — the LOAD-BEARING cross-cloud-provider per-Workspace-tenant per-custom-domain DKIM-CNAME-delegation publication- topology companion (RECIPROCAL to the forward link THIS page's per-M365-tenant SPF-include-cascade publication-topology already documents from the SPF-side cross-cloud-provider authentication- record-publication-topology bridge). Where THIS page documents the per- publisher per-M365-tenant SPF- publication topology (the canonical v=spf1 include:spf.protection.outlook.com ~all record, the per-region EOP egress IP range macro-expansion semantics, the per-tenant outbound mail-flow envelope- layer identity-authorization framework), the DKIM-for-Workspace spoke documents the CROSS-CLOUD-PROVIDER per-Workspace- tenant per-custom-domain DKIM-CNAME- delegation publication-topology STRUCTURAL PARALLEL — the per- Workspace-tenant Google-managed google._domainkey.<d> DKIM-record DNS-publication mechanism, the Workspace Admin-console DKIM enablement flow, the 2048-bit per- tenant DKIM signing posture, the per- tenant DKIM signing-domain verification. The cross-cloud-provider parallel: BOTH cloud-provider tenants (M365 and Workspace) implement per-publisher per-domain DNS-record-class delegation to a cloud-provider-managed authentication-publication endpoint — M365's include: delegation to spf.protection.outlook.com mirrors Workspace's CNAME-style delegation to Google's per-tenant DKIM keypair at google._domainkey. Read THIS page when AUTHORING the per- M365-tenant SPF-include-cascade publication; read the DKIM-for- Workspace spoke as the cross-cloud- provider DKIM-side STRUCTURAL-PARALLEL reference for the per-Workspace-tenant per-custom-domain DKIM-CNAME-delegation publication-topology. The cross-cloud- provider authentication-record- publication-topology bridge across SPF-M365 ↔ DKIM-Workspace closes the per-publisher per-protocol per-cloud- provider per-tenant publication- topology reasoning loop at the cross- cloud-provider authentication-record publication-discipline boundary.
• SPF for Google Workspace — the Google Workspace counterpart to this page. Mirrors the same operational lens (canonical SPF record syntax, third-party-sender catalogue, common misconfigurations) but for include:_spf.google.com instead of include:spf.protection.outlook.com. Essential for operators running hybrid M365 + Workspace deployments or migrating between the two suites.
• DMARC for Office 365 hybrid — focused deep dive on the on-prem + cloud hybrid deployment with Centralized Mail Transport and Direct-Delivery topologies, including the Default Frontend Connector DKIM-strip pitfall and Send Connector relay loops.
• DMARC Alignment Explained — the relaxed vs strict alignment deep dive applicable to every DMARC deployment, with the specific implications for SPF aligned against MAIL FROM vs From: header.
• DMARC Troubleshooting — the master troubleshooting guide covering "I just published my DMARC record but it is not working" symptoms across SPF, DKIM, alignment, and forwarding causes.
• DMARC Records Explained — the tag-by-tag DMARC record reference covering p, sp, pct, rua, ruf, fo, rf, adkim, aspf, and the operational implications of each.
• ARC Explained — the canonical Authenticated Received Chain (RFC 8617) reference. Microsoft 365 implements ARC validation; the Defender for Office 365 Trusted ARC Sealers feature lets M365 tenants explicitly trust specific ARC sealers.
• MTA-STS for Microsoft 365 — the same-provider transport-security companion to this SPF-side application-layer authentication guide — SPF / DKIM / DMARC authenticate the SENDER IDENTITY at the application layer (the receiving MTA verifies the sender domain published the right SPF / DKIM / DMARC records before delivering the message), but they do NOT pin the SMTP SESSION to TLS at the transport layer — which means any active downgrade attacker who controls a hop between the sender and Exchange Online (BGP hijack, malicious Wi-Fi relay, compromised upstream router) can strip the STARTTLS announcement from the SMTP banner and force the message into cleartext where they harvest the bodies, attachments, and SPF/DKIM signatures verbatim. M365 operators reading this SPF-side guide to complete the application-layer authentication setup (the canonical Exchange Online SPF publication procedure with the v=spf1 include:spf.protection.outlook.com -all record and the four-include lookup-budget management discipline) need the MTA-STS-for-Microsoft-365 spoke as the TRANSPORT-LAYER COMPLEMENTARY companion documenting how to close the downgrade- attack gap SPF / DKIM / DMARC do not address: where exactly to publish the _mta-sts.<domain> policy version-pointer TXT record at the registrar (with the v=STSv1; id=<policy-version> format), where to stand up HTTPS hosting for the mta-sts.<domain> web origin on Azure (Blob Storage + CDN, Static Web Apps, App Service, Front Door), how to author the /.well-known/mta-sts.txt policy file with the Exchange-Online-specific mx: <tenant>-com.mail.protection.outlook.com directive, how to wire up TLS-RPT at _smtp._tls.<domain> for the JSON failure-report dwell-time feedback loop, and the testing-mode burn-in workflow (publish testing-mode policy → monitor TLS-RPT for 4 weeks → switch to enforce mode only when zero unexplained delivery failures observed) that protects production mail flow during the deployment window. Read this spoke IMMEDIATELY AFTER completing the SPF publication step from this guide — the SPF-side application-layer record alone leaves a structural gap an active downgrade attacker exploits, and the MTA-STS spoke closes that gap with the TRANSPORT-LAYER companion deployed AGAINST THE SAME M365 TENANT. The two protocols are COMPLEMENTARY not overlapping: SPF gates the message based on the publishing domain's SPF record + envelope MAIL FROM alignment, MTA-STS gates the SMTP session based on the publishing domain's MTA-STS policy file + receiving MTA's TLS-RPT report. Both are required for a complete Exchange Online inbound + outbound application-layer + transport-layer security posture.
• MTA-STS policy-file syntax — the UPSTREAM-RFC-8461-§3.2-POLICY-FILE- BYTE-GRAMMAR-AUTHORING-DISCIPLINE-AS- LOAD-BEARING-PRE-DEPLOYMENT-AUTHORING- REFERENCE-FOR-PER-M365-TENANT-PER-ACCEPTED- DOMAIN-EXCHANGE-ONLINE-INBOUND-MX-PATTERN- ALLOW-LIST-PUBLICATION-DISCIPLINE companion to this per-M365-tenant per-accepted-domain SPF authoring guide. Where THIS page documents the per-M365-tenant per-accepted-domain SPF envelope-MAIL-FROM-layer authoring discipline (the canonical v=spf1 include:spf.protection.outlook.com -all publication procedure, the include: chain expansion at the per-tenant Exchange-Online-Protection authorised- outbound-sender boundary, the per-tenant per- accepted-domain four-include lookup-budget management discipline against the RFC 7208 §4.6.4 ten-DNS-lookup ceiling), the MTA-STS-policy- syntax spoke documents the RFC 8461 §3.2 byte- grammar of the per-M365-tenant per-accepted- domain HTTPS-served policy file the deployment companion enumerated immediately above documents the deployment workflow of. Four per-M365-tenant per-accepted-domain SPF- application-layer-vs-MTA-STS-byte-grammar authoring-discipline coupling dimensions: (i) per-M365-tenant per-accepted-domain SPF include:spf.protection.outlook.com envelope-MAIL-FROM-layer authorisation publication-discipline THIS page documents AS LOAD-BEARING APPLICATION-LAYER PUBLICATION- PORTFOLIO COMPANION to per-M365-tenant per- accepted-domain MTA-STS policy-file mx: *.mail.protection.outlook.com transport-layer allow-list publication- discipline the MTA-STS-policy-syntax spoke documents the RFC 8461 §3.2 byte-grammar of — receivers consume BOTH application-layer authorisation-list and transport-layer allow- list publication anchors when evaluating per- message inbound delivery to an M365-hosted recipient at the per-M365-tenant per-accepted- domain Exchange-Online-Protection coordination boundary; (ii) per-M365-tenant per-accepted- domain SPF qualifier-vocabulary publication- decision (~all SoftFail vs -all Fail terminal-disposition- cliff) AS STRUCTURALLY-PARALLEL ramp-readiness- publication-discipline to per-M365-tenant per- accepted-domain MTA-STS mode: field publication-decision (mode: testing vs mode: enforce enforcement-cliff) — both per-publisher per- domain publication-discipline ramp-progression- decisions instantiate the SAME per-M365-tenant per-accepted-domain operator-side enforcement- readiness publication discipline at the per- tenant Exchange-Online-Protection coordination boundary; (iii) per-M365-tenant per-accepted- domain SPF TXT-RR DNS-publication byte-grammar (per RFC 7208 §3.1) AS STRUCTURALLY-PARALLEL per-publisher per-domain text-record byte- grammar publication-discipline to per-M365- tenant per-accepted-domain MTA-STS policy-file body byte-grammar (per RFC 8461 §3.2) AND per- tenant _mta-sts.<accepted-domain> TXT-RR v=STSv1; id=<policy-id> DNS-byte-grammar — three coexisting per- publisher per-domain text-publication byte- grammars the per-M365-tenant per-accepted- domain operator MUST author consistently; (iv) per-M365-tenant per-accepted-domain SPF record version-bump triggers per RFC 7208 §3.3 DNS- record cache TTL-coherence-management discipline AS STRUCTURALLY-PARALLEL cache-coherence discipline to per-M365-tenant per-accepted- domain MTA-STS policy-file id= rotation per RFC 8461 §3.1 (policy-id rotation in the TXT-RR signalling policy-body revision) — both per-publisher per-domain publication- cadence cache-coherence disciplines feed the same per-tenant per-accepted-domain composite envelope-MAIL-FROM-and-transport-layer publi- cation-discipline coordination at the per-tenant Exchange-Online-Protection coordination boundary.
• MTA-STS for Google Workspace — the CROSS-PROVIDER-M365-OUTBOUND-TO- WORKSPACE-RECEIVER-MTA-STS-POLICY- ENFORCEMENT companion to this M365-tenant SPF authoring guide. Where THIS page documents the M365-tenant SPF outbound-IP authorisation discipline (the canonical include:spf.protection.outlook.com apex record authorising M365-tenant outbound mail at the SENDER-SIDE IP-authorisation layer), the MTA-STS-for-Google-Workspace spoke documents the STRUCTURALLY-DISTINCT cross-provider TRANSPORT-LAYER policy the M365-tenant outbound mail MUST respect when the recipient is a Workspace-tenant inbound MX at FOUR structurally-distinct cross- provider-interop dimensions: (i) M365 outbound MTA (the *.outbound.protection.outlook.com sender pool authorised by THIS page's SPF include:spf.protection.outlook.com directive) connecting to Workspace-tenant inbound MX (aspmx.l.google.com / alt1-4.aspmx.l.google.com) MUST respect the Workspace-tenant MTA-STS policy file's mx: *.l.google.com allow-list and mode: enforce directive — the M365-side outbound STARTTLS is enforced by the Workspace-side MTA-STS policy retrieved from https://mta-sts.<workspace-tenant> /.well-known/mta-sts.txt by the M365 sending MTA at policy-cache-TTL boundaries; the cross-provider SPF-outbound + MTA-STS- inbound coordination is structurally orthogonal to the M365-tenant's OWN MTA-STS policy at mta-sts.<m365-tenant> /.well-known/mta-sts.txt; (ii) M365-SPF + Workspace-MTA-STS cross-provider publication-discipline KPI pair — the load-bearing observability surface for an M365 tenant heavily emailing Workspace tenants is the joint per-tenant ratio of (a) M365-side SPF-pass-rate at Workspace-receiver per the per-domain DMARC-aggregate reports from Gmail back to the M365 tenant AND (b) M365-outbound-to-Workspace-receiver TLS- handshake-success-rate per the M365-side TLS-RPT-aggregate feedback; when the SPF-pass-rate is high but the TLS-handshake- success-rate is low, the Workspace-tenant MTA-STS policy is either misconfigured at the receiver side OR the M365 sending MTA is not retrieving / honouring the Workspace MTA-STS policy correctly — the joint KPI surfaces the cross-provider transport-vs- authentication-layer health; (iii) SPF include:spf.protection. outlook.com IP-republishing-cadence vs Workspace-MTA-STS mx: allow-list-cadence cross-provider coordination — Microsoft republishes the M365 outbound IP pool behind spf.protection.outlook.com on a multi-month cadence (silent additions and removals as Microsoft scales the EOP outbound fleet); Google republishes the Workspace-tenant inbound MX hostname pattern in the Workspace MTA-STS policy file on a structurally-independent cadence (Workspace operator-controlled via the customer-DNS zone-managed https://mta-sts.<workspace-tenant> /.well-known/mta-sts.txt publication); the two republishing cadences do not synchronise — an M365 tenant heavily emailing Workspace tenants must monitor BOTH at the cross-provider boundary; (iv) M365-side spf.protection.outlook.com sub-include cascade as authentication-layer cost-budget vs Workspace-side MTA-STS HTTPS- fetch as transport-layer cost-budget — the M365-tenant SPF authentication chain consumes ~3-5 DNS lookups for the include:spf.protection.outlook.com cascade out of the RFC 7208 §4.6.4 10- lookup ceiling (each M365 SPF verification at the Gmail-receiver costs the chain), the Workspace-side MTA-STS chain consumes one HTTPS fetch per max_age cycle (typically 86400 seconds — once per day per M365-MTA-to-Workspace-tenant pair) regardless of message volume; the cost- budget profiles complement each other rather than overlap at the cross-provider boundary. Read the MTA-STS-for-Google-Workspace spoke when designing an M365-tenant outbound mail- stream that includes heavy Workspace recipient traffic — the Workspace-MTA-STS policy is the load-bearing receiver-side TLS- enforcement boundary the M365 outbound MTA must respect at every M365-to-Workspace transport-session boundary.
• Reverse DNS / PTR records for mail servers — the M365-TENANT-EGRESS-SOURCE-IP- INVENTORY-AS-LOAD-BEARING-UPSTREAM- DOMAIN-INVENTORY-INPUT-INTO-PER- SOURCE-IP-REVERSE-ZONE-PTR-RR- PUBLICATION-DISCIPLINE companion to this M365-tenant SPF-publication guide. Where THIS page documents the per-M365-tenant canonical include:spf.protection.outlook.com include-cascade resolution chain (M365-tenant v=spf1 include:spf.protection.outlook.com -all publication discipline, the per- shard Exchange-Online-egress-IP inventory resolved via the include cascade's nested subordinate netblock includes, the per-M365- tenant per-accepted-domain publication-coordination discipline), the reverse-DNS-PTR spoke documents the per-source-IP IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-RR publication discipline whose Microsoft-operated PTR-target hostname publication is the LOAD- BEARING upstream-prerequisite for the per-M365-tenant SPF-mechanism- aligned-pass-rate floor at FOUR per- M365-tenant-egress-shard-to-PTR-RR- publication-discipline coupling dimensions: (i) per-M365- tenant-egress-source-IP-inventory- resolved-via-include:spf.protection.outlook.com- as-load-bearing-domain-inventory- input-into-per-source-IP-reverse- zone-PTR-RR-resolution — the per-M365-tenant include:spf.protection.outlook.com mechanism resolution THIS page documents enumerates the Exchange- Online egress source-IP inventory whose per-source-IP reverse-zone PTR-RR resolution (against mail-*.outbound.protection.outlook.com / tenant.mail.protection.outlook.com Microsoft-operated PTR-target hostnames) is the LOAD-BEARING upstream-input every receiver-side per-M365-tenant FCrDNS verification consumes to corroborate the per- source-IP identity-claim with the per-M365-tenant SPF-aligned-pass verdict; (ii) per-M365- tenant-egress-IP-FCrDNS-forward- confirmation-as-load-bearing- UPSTREAM-evidence-input-into- Defender-Threat-Explorer-and-SNDS- reputation-scoring-of-M365-egress- spf=pass-verdicts — the per-source-IP forward-confirmed- reverse-DNS publication discipline THIS reverse-DNS spoke documents is the upstream-evidence input the M365-tenant Defender for Office 365 Threat Explorer + Smart-Network-Data- Services reputation-model consumes alongside the per-M365-tenant spf=pass verdict THIS page documents; per-M365-tenant spf=pass evidence rows arriving from mail-*.outbound.protection.outlook.com source-IPs with well-formed FCrDNS are scored differently from per- M365-tenant spf=pass evidence rows arriving from M365- tenant-side ip4: / ip6: explicit-published IPs with absent or forged PTR-RRs; (iii) per-M365-tenant- hybrid-Exchange-on-prem-IP-and- third-party-ESP-IP-supplemented-SPF- publication-discipline-as-upstream- input-into-M365-tenant-side-PTR-RR- publication-discipline-for- publisher-owned-source-IPs — the per-M365-tenant SPF- publication discipline THIS page documents allows ip4: / ip6: / per-third-party-ESP-include supplements alongside the canonical include:spf.protection.outlook.com for hybrid-Exchange on-prem-IP / Direct-Send-coverage / third-party- ESP-publication coverage; every per- M365-tenant-side publisher-owned source-IP added to the SPF policy REQUIRES per-source-IP reverse-zone PTR-RR publication discipline THIS reverse-DNS spoke documents to be in place at the M365-tenant-side DNS provider for the publisher-side FCrDNS-verified-spf=pass evidence row to be receiver-side reputation- score-eligible; (iv) per- M365-tenant-rua-aggregate-XML- row/auth_results/spf/result=pass- evidence-row-attribution-as- downstream-consumer-of-per-source- IP-FCrDNS-verified-identity- corroboration — the per- receiver per-M365-tenant per-source- IP per-day rua aggregate-XML row/auth_results/spf/result=pass + row/source_ip attribution evidence row THIS page's post-cutover observability layer consumes is reliably attributable to the per-M365-tenant egress-IP identity only when per-source-IP FCrDNS verification corroborates the per-source-IP spf=pass verdict — per-source-IP reverse-zone PTR-RR publication discipline THIS reverse-DNS spoke documents is the LOAD-BEARING upstream-prerequisite for per-M365-tenant per-source-IP rua-aggregate-XML evidence-row attribution integrity. Read the reverse-DNS-PTR spoke alongside THIS page when the M365-tenant operator asks "how does the per- M365-tenant egress-source-IP- inventory-as-resolved-via-include: spf.protection.outlook.com translate into the per-source-IP reverse-zone PTR-RR publication discipline at the Microsoft-operated PTR-target hostname layer" — the answer is FOUR-LAYERED: THIS page documents the per-M365-tenant SPF-publication discipline, the reverse-DNS-PTR spoke documents the per-source-IP reverse-zone PTR-RR publication discipline whose Microsoft-operated PTR-target hostname publication is the load-bearing upstream-prerequisite for per-M365-tenant FCrDNS-verified- spf=pass evidence-row attribution integrity.
• Email Authentication Cluster Intro — the four-protocol pillar overview (SPF + DKIM + DMARC + BIMI) and the deployment ordering operators should follow.
• Email Authentication Glossary — definitions for every term used in this guide and across the cluster.
• DMARC for shared hosting — the UPSTREAM-RELAY-PROVIDER-INCLUDE- CASCADE-VOCABULARY-PARALLEL-AT-FOUR- DEPLOYMENT-CLASS-PER-PUBLISHER-SPF- INCLUDE-AUTHORITY-LIST-COORDINATION- DIMENSIONS companion to this SPF-for- Microsoft-365 reference. Where THIS page documents the canonical M365-tenant SPF-record publication discipline (v=spf1 include:spf.protection.outlook.com -all at the M365-tenant apex domain) whose Exchange Online cloud- egress IP-pool is published through the Microsoft-operated spf.protection.outlook.com include-token, the shared-hosting spoke is the structural-parallel per- deployment-class sibling documenting the SAME upstream-relay-provider include- cascade authority-delegation discipline at four per-publisher SPF-include- authority-list coordination dimensions: (i) per-publisher upstream- relay-provider include-token-delegation parallel — M365 tenants publish include:spf.protection.outlook.com which expands at receiver-side SPF evaluation to the Microsoft-operated Exchange Online egress IP-pool; shared- hosting tenants publish include:<provider-spf-host> (e.g. include:_spf.cpanel.net for cPanel-Email-Routing hosts, include:spf.bluehost.com for Bluehost, include:_spf.hostgator.com for HostGator, include:_spf.kasserver.com for All-Inkl, etc.) which expands at receiver-side SPF evaluation to the hosting-provider-operated shared- outbound-relay-pool IP space — both deployment classes face the SAME per- publisher upstream-provider include- token-delegation discipline; (ii) RFC 7208 §4.6.4 10-mechanism lookup-limit ceiling parallel — M365-tenant SPF records often exceed the 10-DNS-lookup ceiling when cascading include:spf.protection.outlook.com + include:_spf.salesforce.com + include:mailgun.org + per- third-party-ESP includes; shared-hosting SPF records frequently exceed the SAME ceiling when cascading include:<provider-spf-host> + include:<third-party-ESP> + per-marketing-tool includes — both deployment classes face the SAME RFC 7208 §4.6.4 permerror ceiling and the SAME SPF-flattening / authoritative- delegation remediation pattern; (iii) upstream-provider-managed- include-host-rotation transparency parallel — M365 tenants depend on Microsoft-managed spf.protection.outlook.com include-host content rotation (Microsoft adds/removes Exchange Online egress IP-blocks without publisher-side coordination); shared-hosting tenants depend on hosting-provider-managed include-host content rotation (hosting-providers add/remove shared- relay-pool IP-blocks without per-tenant coordination) — both deployment classes face the SAME upstream-provider-managed- include-host-rotation transparency discipline at the per-publisher per- source-IP DMARC-aligned-pass-rate- attribution boundary; (iv) per- publisher per-source-IP DMARC alignment coordination with upstream-provider- include-cascade parallel — M365 tenants face per-source-IP DMARC-SPF- aligned-pass-rate attribution across Microsoft-operated Exchange Online cloud-egress shared-IP-pool members; shared-hosting tenants face per-source- IP DMARC-SPF-aligned-pass-rate attribution across hosting-provider- operated shared-outbound-relay-pool IP- members — both deployment classes face the SAME per-publisher per-source-IP DMARC alignment-attribution discipline at the multi-publisher-share-the-same- upstream-IP-pool forensic-investigation boundary. Read the shared-hosting spoke ALONGSIDE this SPF-for-Microsoft-365 reference whenever a per-publisher upstream-relay-provider include-cascade authority-delegation discipline question crosses deployment-class — the cross- deployment-class structural-parallel between M365-tenant include-cascade authority delegation and shared-hosting- tenant include-cascade authority delegation is the load-bearing publisher-side SPF-authority-list- coordination education surface for per- publisher SPF-include-mechanism-cascade discipline transfer across deployment- class boundaries.
• Microsoft Learn: Set up SPF to help prevent spoofing — the canonical primary-source Microsoft documentation for SPF on Exchange Online.
• Microsoft 365 Defender portal — the operator entry point for message trace and DKIM management.
• Google: Email sender guidelines — the Feb 2024 bulk-sender requirements applicable to every M365 tenant.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker — live DNS lookups for every email- authentication record. Surfaces the realised SPF lookup count.
• DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC Analyzer Dashboard — ingests Microsoft / Google / Yahoo aggregate reports and surfaces the per-sender / per-IP / per-day breakdown.
• DMARC deployment checklist — the END-TO-END PHASED-DEPLOYMENT-PIPELINE companion to this M365-SPF deployment reference. Where THIS page documents the M365-CONCRETE SPF record publication workflow (the canonical v=spf1 include:spf.protection.outlook.com -all record at the apex, the per-tenant third-party sender enumeration via Mail Flow > Connectors, the hybrid Exchange On-Premises co-existence adjustment, the 10-DNS-lookup budget management across the M365 + third-party-ESP include chain, the onmicrosoft.com tenant-default- domain SPF prerequisite), the deployment checklist documents the M365-AGNOSTIC canonical phased-deployment sequence within which SPF publication is the FIRST authentication-protocol publication step (followed by DKIM publication and finally DMARC publication). Four DEPLOYMENT-CHECKLIST-VS-M365-SPF axes the checklist documents that THIS page is the M365-CONCRETE walkthrough for: (1) SPF publication phase — the checklist's "publish an SPF TXT record covering every legitimate sending source" step that this page concretises with the canonical spf.protection.outlook.com include plus the per-tenant third-party-ESP include chain (Constant Contact / Mailchimp / SendGrid / Marketo / HubSpot / Salesforce / Atlassian) whose cumulative DNS-lookup cost the M365 tenant must manage against the RFC 7208 §4.6.4 10-lookup limit; (2) onmicrosoft.com tenant-default-domain prerequisite — the checklist's "audit the rua-stream for unsigned tenants" enumeration step against which this page documents the M365-specific tenant.onmicrosoft.com default- sending-domain SPF prerequisite (the #1 SPF=pass + DMARC=fail M365 pattern when the tenant-default-domain SPF record at tenant.onmicrosoft.com is missing the canonical spf.protection.outlook.com include); (3) hybrid-Exchange coordination — the checklist's "coordinate sending sources across all legitimate egress points" step that this page concretises with the hybrid-Exchange On- Premises Exchange Transport Agent + Exchange Online cloud-MTA dual-egress SPF coordination (ip4:<on-prem-edge-IP> + include:spf.protection.outlook.com); (4) enforcement-commitment phase coordination — the checklist's p=none → p=quarantine → p=reject ramp that requires the M365 tenant's SPF record (documented here) to converge on a zero-spf=fail-from-legitimate-sources state BEFORE flipping enforcement (and BEFORE the Feb 2024 Gmail / Yahoo bulk-sender enforcement deadline for M365-hosted bulk senders). Read the deployment checklist FIRST to understand the canonical phased sequence; read THIS page SECOND to execute the SPF-publication phase on M365.
• DMARC multi-domain strategy — the MULTI-DOMAIN-M365-ESTATE- SPECIFIC SPF-PUBLICATION-COORDINATION companion to this M365-tenant SPF reference. Where THIS page documents the per-M365-tenant canonical include:spf.protection.outlook.com publication step for a single M365- tenant primary domain, the multi- domain-strategy spoke is the MULTI- DOMAIN-M365-ESTATE-SPECIFIC SPF- publication-coordination execution guide at FOUR per-multi-domain-M365- estate-to-SPF-publication coupling dimensions: (i) per- organizational-domain primary-brand- domain include:spf.protection.outlook.com publication coordination with sibling brand-subsidiary-domain M365- tenant accepted-domain SPF records — when the M365 tenant adds brand.com, brand-eu.com, brand-apac.com, brand-shop.com as Exchange-Online accepted-domains, each per-accepted-domain include:spf.protection.outlook.com publication MUST be coordinated to maintain estate-wide Exchange-Online- emitted envelope-MAIL-FROM alignment — the multi- domain spoke documents the per- organizational-domain M365-tenant accepted-domain SPF-publication coordination operators execute to maintain consistent M365-tenant SPF- publication posture across the multi- domain M365 estate; (ii) per- parked-domain defensive v=spf1 -all publication coordination — when the org publishes the canonical M365 include:spf.protection.outlook.com on primary brand domains, parked defensive domains like brand-typo.com, brand-cn.com, brand-misspelling.com MUST publish empty v=spf1 -all records to prevent attacker-impersonation via parked-domain SPF-bypass — the multi-domain spoke documents the per-parked-domain SPF-publication- discipline coordination operators execute alongside M365-tenant SPF publication cycles; (iii) per-M365-accepted-domain SPF-publication coordination discipline alongside Exchange Online accepted-domains catalogue configuration — when a single M365 tenant hosts multiple accepted domains via the Microsoft 365 admin center → Settings → Domains catalogue, each per-accepted-domain _dmarc.<domain> + SPF publication MUST be coordinated across the M365-tenant's accepted- domain inventory to maintain per- accepted-domain envelope-MAIL-FROM alignment with the tenant's egress from <tenant>.mail.protection.outlook.com source IPs — the multi- domain spoke documents the per-M365- accepted-domain SPF-publication- coordination discipline operators execute across the M365 tenant's accepted-domain inventory; (iv) per-multi-domain-M365-estate cross-domain rua-feed aggregation discipline anchored on the M365- tenant primary-domain rua mailbox — the multi-domain strategy spoke's per-estate rua-mailbox-aggregation discipline (where every brand-domain publishes rua=mailto:dmarc@brand-rua-collector.com + the brand-rua-collector.com._report._dmarc.<domain> verification record) consumes the per-M365-tenant rua stream THIS page's M365-tenant SPF publication discipline contributes to — the multi-domain spoke documents the per-estate cross-domain rua-feed aggregation discipline operators execute to centralize the per-M365- estate SPF-publication-outcome evidence stream. Read the multi- domain-strategy spoke ALONGSIDE this M365-tenant SPF reference whenever the M365-tenant SPF-publication step THIS page documents is being scoped for execution across the organization's multi-domain M365 estate — the multi- domain spoke is the canonical per- multi-domain-M365-estate SPF- publication-coordination reference whose per-organizational-domain + per-parked-domain + per-M365- accepted-domain + per-estate-rua- feed-aggregation coordination disciplines are the LOAD-BEARING multi-domain-M365-estate execution discipline every estate-wide M365- tenant SPF-publication cycle depends on.
• MX records — the PER-M365-TENANT-INBOUND-MX-AS- RECEIVER-SIDE-STRUCTURALLY-PAIRED- IDENTITY-RECORD-CLASS-TO-PER-TENANT- OUTBOUND-SPF-PUBLICATION-DISCIPLINE companion reference. Where THIS page documents the per-M365-tenant outbound SPF publication discipline (the per- tenant v=spf1 include:spf. protection.outlook.com -all TXT record at the per-customer-domain master zone authorizing the per-M365-tenant cloud-egress IP pool to MAIL FROM as the per-customer-domain), the MX-records spoke documents the structurally-paired RECEIVER-SIDE per-M365-tenant inbound MX publication discipline (the per- customer-domain <customer-domain-with- dashes>.mail.protection.outlook.com MX RDATA whose per-customer- domain publication at the per-customer- domain master zone steers inbound mail traffic to the per-M365-tenant Exchange Online inbound MTA frontend), across four per-M365-tenant-inbound-MX-to-per- tenant-outbound-SPF-coupling dimensions: (i) per-M365-tenant-inbound-MX- and-outbound-SPF-as-structurally-paired- record-class-pair — every per- M365-tenant per-customer-domain publication cycle requires BOTH the per- tenant outbound SPF TXT record (the v=spf1 include:spf.protection. outlook.com -all authorization) THIS page documents AND the per-tenant inbound MX record (the <customer- domain-dashes>.mail.protection. outlook.com MX target) the MX- records spoke documents to fully wire the per-customer-domain to the M365 tenant boundary; the two record classes are structurally paired at the per- customer-domain master zone publication event; (ii) per-M365-tenant- inbound-MX-publication-as-load-bearing- input-to-inbound-DMARC-evaluation-at- M365-tenant-frontend — the per- tenant inbound MX RDATA the MX-records spoke documents resolves the receiver- side endpoint where the per-message inbound DMARC evaluation occurs at the Exchange Online Protection (EOP) / Microsoft Defender for Office 365 frontend; per-tenant inbound DMARC evaluation outcomes feed the per-tenant Defender-for-Office-365 quarantine-and- block-policy and the per-tenant Authentication-Results header emitted downstream into the per-customer-domain message-trace surface; (iii) per- M365-tenant-inbound-MX-as-structurally- symmetric-load-bearing-input-to-per- tenant-RUA-feed-evidence-source-IP- attribution — the per-tenant inbound MX endpoint the MX-records spoke documents IS the per-tenant per- receiver-side MTA that emits per-day aggregate RUA reports BACK to the per- publisher's rua=mailto: tag-value mailbox; per-tenant inbound MX publication AT the per-customer- domain master zone GATES whether the receiver-side per-tenant RUA-emission infrastructure operates against the per- publisher's per-customer-domain; (iv) per-M365-tenant-inbound- MX-and-outbound-SPF-onboarding-sequence- coordination — the per-M365- tenant onboarding sequence at the per- customer-domain admin portal requires publishing BOTH the per-tenant outbound SPF TXT record THIS page documents AND the per-tenant inbound MX record the MX-records spoke documents at the per- customer-domain master zone IN COORDINATED LOCKSTEP (operators MUST NOT flip the inbound MX to point at the per-tenant EOP frontend before BOTH records have fully DNS-propagated, lest in-flight inbound mail be black-holed at the per-customer-domain prior to the per-tenant EOP frontend's inbound acceptance threshold). Read this WITH the per-M365-tenant outbound SPF publication reference when the per- customer-domain wiring sequence to the per-M365-tenant boundary reaches the operator's queue: THIS page documents the per-tenant outbound SPF publication discipline, the MX-records spoke documents the structurally-paired receiver-side per-tenant inbound MX publication discipline whose per- customer-domain master-zone MX RDATA gates inbound mail traffic to the per- M365-tenant EOP frontend the per- tenant outbound SPF publication symmetric receiver-side identity endpoint THIS page documents presupposes is operational.
• DANE explained — the PER-M365-TENANT-SPF-AS-ENVELOPE-LAYER- AUTHENTICATION-PEER-OF-DANE-TLSA-AS-TRANSPORT- LAYER-AUTHENTICATION companion to this M365- tenant SPF authoring reference. Where THIS page documents the per-M365-tenant outbound- MAIL-FROM-leg SPF TXT-RR publication discipline (the canonical v=spf1 include:spf.protection.outlook.com envelope-MAIL-FROM authorization primitive), the DANE-explained spoke is the per-MX-side DNSSEC-backed cryptographic transport-layer authentication peer protocol whose per-tenant inbound-MX TLSA RR publication forms the SECOND authentication leg covering the per- receiver inbound SMTP TLS handshake at the per-MX cryptographic-fingerprint binding boundary. Joint per-M365-tenant SPF + DANE publication discipline forms the per-publisher per-domain CROSS-LAYER authentication posture (SPF = envelope-MAIL-FROM authorization at application layer; DANE = per-MX cryptographic- chain validation at transport layer) every production-grade per-M365-tenant per-domain receiver-side authentication composite verdict consumes as upstream per-layer publication primitives.
• Phishing protection — the PER-M365-TENANT-PER-CUSTOM-DOMAIN- SPF-PUBLICATION-AS-PER-TENANT-PHISHING-AND- SPOOFING-ATTACK-SURFACE-COMPRESSION companion to THIS per-M365-tenant per- custom-domain SPF authoring reference. Where THIS page documents the per-M365-tenant per- custom-domain SPF publication workflow (the Exchange Online egress IP-range spf.protection.outlook.com include-mechanism alignment, the per-tenant per-custom-domain DKIM dual- selector publication coordination, the per-tenant per-custom-domain DMARC composite- publication alignment, the per-tenant per- custom-domain bulk-sender + Power-Automate + Dynamics 365 + Exchange Online egress coordination), the phishing-protection spoke documents the per-receiver per-message anti- phishing defence-stack at FOUR per-M365- tenant per-custom-domain SPF-publication-vs- phishing-attack-surface coupling dimensions: (i) per-M365-tenant per-custom- domain SPF -all hard-fail qualifier publication AS load-bearing per- receiver per-message anti-spoofing envelope- layer authoritative-rejection primitive — the per-receiver per- message anti-phishing evaluator consumes the per-M365-tenant per-custom-domain SPF -all hard-fail verdict against per-attacker non-Exchange-Online egress envelope-MAIL-FROM authorisation as the per-publisher per-domain authoritative- rejection primitive at the per-receiver per- message envelope-layer authentication boundary; the per-M365-tenant per-custom- domain SPF -all publication discipline THIS page documents directly compresses the per-attacker phishing-and- spoofing-attack-surface at the per-receiver per-message envelope-layer authentication decision; (ii) per-M365-tenant per- custom-domain SPF include:- cascade discipline AS per-tenant per-custom- domain phishing-attack-surface-leakage-vector compression — the per-receiver per- message anti-phishing evaluator's per- publisher per-domain authorised-egress-IP set is determined by the per-M365-tenant per- custom-domain SPF include:- cascade transitive resolution (Exchange Online + Power-Automate + Dynamics 365 + per- tenant third-party SaaS-sender egress IP ranges); per-M365-tenant per-custom-domain SPF include:-cascade permissiveness (over-broad third-party SaaS- sender includes, deprecated include:-mechanism retention) expands the per-tenant per-custom-domain authorised-egress-IP set and elevates the per-attacker per-message spoofing-attack- surface; the per-M365-tenant per-custom- domain SPF include:-cascade audit discipline THIS page documents directly compresses the per-tenant per- custom-domain phishing-attack-surface-leakage vector the phishing-protection spoke catalogues; (iii) per-M365-tenant per-custom-domain SPF + DKIM + DMARC composite-publication AS per-tenant per- custom-domain anti-phishing-baseline floor publication discipline — the per- receiver per-message anti-phishing evaluator's per-publisher per-domain sender-authenticity composite-verdict consumes the per-M365-tenant per-custom-domain SPF + DKIM + DMARC composite-publication discipline (per-tenant per-custom-domain SPF include:spf.protection.outlook.com envelope-layer publication + per-tenant per- custom-domain selector1._domainkey + selector2._domainkey DKIM dual- selector publication + per-tenant per- custom-domain DMARC _dmarc.<custom-domain> record publication) as the per-tenant per- custom-domain anti-phishing-baseline floor; (iv) per-M365-tenant per-custom- domain RFC 7208 §4.6.4 10-DNS-lookup permerror-cap discipline AS per-tenant per-custom-domain phishing-evaluation- fidelity preservation discipline — per-M365-tenant per-custom-domain SPF include:-cascade traversals exceeding the RFC 7208 §4.6.4 10-DNS-lookup permerror cap collapse the per-receiver per- message SPF-leg verdict to spf=permerror which the per- receiver per-message anti-phishing evaluator treats as per-publisher per-domain authentication-discipline-floor regression elevating the per-tenant per-custom-domain phishing-attack-surface; the per-M365-tenant per-custom-domain RFC 7208 §4.6.4 permerror-cap audit discipline THIS page documents preserves the per-receiver per- message anti-phishing evaluation fidelity at the per-tenant per-custom-domain envelope- layer authentication boundary. Read THIS page when AUTHORING per-M365-tenant per- custom-domain SPF publication; read the phishing-protection spoke when UNDERSTANDING how the per-M365-tenant per-custom-domain SPF publication THIS page documents IS the load-bearing per-tenant per-custom-domain anti-phishing-attack-surface compression discipline the per-receiver per-message anti-phishing defence-stack consumes at the per-tenant per-custom-domain envelope-layer authentication-evaluation boundary.
• MTA-STS vs DANE for SMTP — the structurally parallel transport-layer publication-discipline companion to this M365- tenant SPF envelope-MAIL-FROM-layer publication reference. Where THIS page documents the per- M365-tenant per-accepted-domain envelope-MAIL- FROM-layer SPF publication-discipline (per- tenant v=spf1 include:spf.protection.outlook.com -all canonical baseline + per-tenant hybrid-Exchange dual-egress composition + per-tenant SPF- flattening discipline against the RFC 7208 §4.6.4 ten-DNS-lookup ceiling), the MTA-STS-vs- DANE spoke documents the structurally parallel per-M365-tenant per-accepted-domain transport- layer publication-discipline decision-matrix — where Microsoft's platform-engineering decision NOT to DNSSEC-sign protection.outlook.com makes MTA-STS (RFC 8461 HTTPS-served-policy) the per- M365-tenant canonical transport-layer publication-discipline over DANE (RFC 7672 DNSSEC-anchored-TLSA-RR). Four per-M365-tenant per-accepted-domain composite envelope-and- transport-layer publication-discipline coupling dimensions matter at the per-tenant per- accepted-domain publication-coordination boundary: (i) per-tenant per-accepted-domain DUAL publication-channel — per-tenant SPF via per-domain TXT-RR DNS publication, per-tenant MTA-STS via per-domain HTTPS Well-Known-URI publication + per-domain TXT-RR id signal; (ii) per-tenant per-accepted-domain DUAL DANE- ineligibility consequence — per-tenant DANE- ineligibility (protection.outlook.com is not DNSSEC-signed) forces per-tenant MTA-STS as the canonical per-tenant per-accepted-domain transport-layer publication choice; (iii) per- tenant per-accepted-domain DUAL receiver-side verification — per-receiver per-message SPF verification consumes per-tenant per-mechanism macro expansion, per-receiving-MTA per-MX-host MTA-STS verification consumes per-tenant per-MX- host policy-line mx-pattern match; (iv) per- tenant per-accepted-domain DUAL composite envelope-and-transport-layer publication portfolio — per-tenant SPF + per-tenant DKIM + per-tenant DMARC + per-tenant MTA-STS + per- tenant TLS-RPT form the composite per-tenant per-accepted-domain envelope-and-application- and-transport-layer publication-discipline- floor portfolio every per-M365-tenant per- accepted-domain deployment THIS page documents materially coordinates publication discipline against.
• MTA-STS explained — the canonical RFC 8461 MTA-STS protocol primer every M365 tenant operator should read alongside this SPF deployment walkthrough to understand how the per-tenant transport-layer https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-served policy file (declaring mx: *.outlook.com for the EOP inbound MX hosts) pairs with the per-M365- tenant per-accepted-domain SPF v=spf1 include:spf.protection.outlook.com -all DNS-published-TXT-record authorisation discipline this page documents to form the per-M365-tenant composite per-accepted-domain envelope- authentication + transport-layer-encryption publication-discipline portfolio. Where THIS page locks the per-message envelope-MAIL-FROM authorisation at the application-layer, the MTA-STS-explained primer locks the per- receiving-MTA STARTTLS-enforcement boundary at the transport-layer — together they close the per-tenant per-accepted-domain envelope- authentication-and-encryption publication floor.
• DMARC for transactional-email senders — the per-M365-tenant per-accepted- domain SPF-publication-vs-transactional-ESP- include-budget coordination companion to this M365 SPF deployment guide. Where THIS page documents the canonical M365 SPF posture (the v=spf1 include:spf.protection.outlook.com ~all per-accepted-domain TXT-RR publication discipline, the EOP SoftFail SCL=5 vs Fail SCL=9 receiver-side disposition), the transactional-email spoke documents the per- M365-tenant per-accepted-domain DMARC ramp the transactional-ESP onboarding cascades from. Four coupling axes connect them: (i) per-M365-tenant per-accepted-domain SPF MUST include BOTH the M365 include:spf.protection.outlook.com macro AND the transactional-ESP's include (e.g. include:sendgrid.net, include:_spf.salesforce.com, include:mailgun.org, include:_spf.mailjet.com) under a single per-accepted-domain TXT-RR — the include-count budget against the RFC 7208 §4.6.4 10-DNS-lookup-cap drives per- tenant transactional-ESP onboarding sequence; (ii) per-M365-tenant per-accepted- domain DKIM CNAME publication (Microsoft 365 selector1._domainkey + selector2._domainkey CNAMEs to the tenant's signing infrastructure) MUST coordinate with the transactional-ESP's per- stream DKIM-Signature publication (e.g. SendGrid's per-customer-subdomain DKIM CNAME) — both DKIM signers contribute per-stream DKIM-aligned-pass evidence-rows into the per-accepted-domain DMARC composite-verdict; (iii) per-M365-tenant per-accepted-domain DMARC subdomain-policy sp=quarantine|reject publication discipline coordinates per-stream egress attribution at strict identifier-alignment — transactional-stream emission from a per-stream subdomain (receipts.<tenant-domain>, notifications.<tenant-domain>) SHOULD publish per-subdomain DMARC records with the appropriate sp=/p= tier alongside the parent-domain publication; (iv) per-M365-tenant per-accepted-domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject progression IS gated by the composite SPF + DKIM aligned-pass-rate floor measured across BOTH M365 outbound AND transactional-ESP outbound streams — the per-receiver per-day per-source-IP policy_evaluated evidence-row attribution in the per-accepted-domain DMARC RUA aggregate-report stream IS the load- bearing operator-side observability signal driving the ramp progression decision. Read the transactional-email spoke alongside this M365 SPF deployment guide when AUTHORING per-M365-tenant per-accepted-domain composite SPF + DKIM publication discipline with transactional-ESP include coordination, when AUDITING per-tenant include-budget against the 10-DNS-lookup-cap, or when PLANNING per- accepted-domain DMARC enforcement-mode ramp sequencing against per-stream transactional- ESP onboarding cadence.
• DKIM best practices
• DMARC for SaaS senders — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-SPF-ENVELOPE-MAIL-FROM-LAYER-AUTHORIZATION-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-PER-TENANT-PER-CUSTOM-DOMAIN-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-SAAS-TENANT-PER-CUSTOM-DOMAIN-DMARC-APPLICATION-LAYER-ENFORCEMENT-PUBLICATION-DISCIPLINE companion at four per-tenant-onboarding-vs-per-tenant-DMARC-enforcement coupling dimensions: (i) per-M365-tenant per-accepted-domain SPF include:spf.protection.outlook.com macro-publication-discipline IS structurally parallel per-tenant per-custom-domain envelope-MAIL-FROM-layer third-party-egress authorization-publication-discipline to per-SaaS-tenant per-custom-domain SPF include:_spf.salesforce.com / include:helpscoutemail.com / include:servers.mcsv.net / include:sendgrid.net macro-publication-discipline the SaaS-senders spoke documents the per-tenant per-customer per-custom-domain SaaS-product-tenant authorization-cascade of — both per-tenant per-custom-domain envelope-MAIL-FROM-layer macro-publication-discipline references coordinate per-tenant per-custom-domain composite cross-stream authorization-publication-discipline at the per-tenant per-custom-domain composite multi-stream-egress envelope-MAIL-FROM-layer coordination boundary; (ii) per-M365-tenant per-accepted-domain DMARC p=quarantine/p=reject enforcement-mode publication-discipline per RFC 7489 §6.3 IS structurally parallel per-tenant per-custom-domain application-layer enforcement-mode publication-discipline to per-SaaS-tenant per-custom-domain DMARC enforcement-mode publication-discipline the SaaS-senders spoke documents the per-tenant per-customer per-custom-domain DMARC ramp-progression of — both per-tenant per-custom-domain DMARC enforcement-mode publication-discipline references gate per-tenant per-customer-onboarding-readiness at the per-tenant per-custom-domain composite enforcement-mode ramp-progression coordination boundary; (iii) per-M365-tenant per-accepted-domain RFC 7208 §4.6.4 10-DNS-lookup-cap budget IS structurally parallel per-tenant per-custom-domain envelope-MAIL-FROM-layer publication-budget primitive to per-SaaS-tenant per-custom-domain SPF include: macro-publication-budget — per-customer-tenant onboarding multiple-SaaS-product-tenant include: macros can exhaust the per-tenant per-custom-domain 10-DNS-lookup-cap budget surfacing as per-tenant permerror the SaaS-senders spoke documents the per-tenant per-customer per-custom-domain SPF-flattening + macro-consolidation operational-discipline of; (iv) per-M365-tenant per-accepted-domain DMARC RUA aggregate-report-pipeline per-day per-source-IP per-row attribution-stream IS structurally parallel per-tenant per-custom-domain application-layer evidence-stream to per-SaaS-tenant per-custom-domain DMARC RUA per-day per-source-IP per-row attribution-stream the SaaS-senders spoke documents the per-tenant per-customer per-day per-SaaS-product-tenant per-source-IP attribution-evidence-stream consumption of at the per-tenant per-custom-domain composite cross-protocol per-day per-receiver attribution-stream-continuity coordination boundary.
• DMARC policy rollout — the enforcement-deployment companion to this M365 SPF guide. Where this page documents the per-tenant per-accepted-domain envelope-MAIL-FROM-layer SPF authorisation publication (the canonical include:spf.protection.outlook.com -all record, the third-party-sender ordering against the RFC 7208 §4.6.4 10-DNS-lookup cap, the hybrid on-prem-plus-Exchange-Online SPF, the onmicrosoft.com gotcha), the policy- rollout spoke documents the operational deployment path that consumes the resulting SPF-aligned-pass leg: the operator verifies a healthy per-source SPF-aligned and DKIM-aligned pass rate in the RUA aggregate stream at p=none, advances to p=quarantine with a monotonically- ramped pct=, and reaches p=reject only once every legitimate Exchange Online and third-party sending source is stable at the enforcement floor. A jump to p=reject before the M365 SPF record this page documents correctly authorises every legitimate source — including any third-party ESP added before the spf.protection.outlook.com include — blackholes legitimate tenant mail, which is exactly why the rollout spoke gates each enforcement step on the per-source SPF-aligned evidence this M365 SPF publication produces. Read the policy-rollout spoke once the tenant SPF record is verified healthy on this page and the operator needs the phased path to a p=reject posture.
• DMARC reporting pipeline — where the M365-tenant SPF result this page configures actually surfaces for measurement. Every receiver that evaluates include:spf.protection.outlook.com against a connecting M365 outbound IP records the per-message spf=pass/fail/softfail verdict in the DMARC aggregate (RUA) row it later emits; the reporting-pipeline spoke documents the ingestion architecture that parses those rows, aggregates per-source-IP per-day, and exposes the M365-tenant SPF-alignment pass-rate trend the operator monitors to confirm the SPF record published here is producing aligned passes in the wild — and to catch the silent permerror that a 10-DNS-lookup overflow (the canonical M365 + third-party-sender failure mode) would otherwise hide.
• DMARC forensic reports — the per-message failure-sample companion to the aggregate measurement. Where the reporting pipeline shows the M365-tenant SPF pass-rate trend, a ruf= forensic report delivers the redacted headers of an individual failing message so you can see which outbound host or third-party sender produced the spf=fail or silent permerror. Read the forensic-reports spoke to enable and read these per-failure samples when diagnosing a specific M365 SPF break.
• TLS-RPT explained — Microsoft 365 honours inbound MTA-STS and emits SMTP TLS Reporting data, so once your tenant SPF record holds the SPF-aligned-pass leg, TLS-RPT (RFC 8460) is the next layer of observability: a _smtp._tls.<domain> TXT record that collects daily JSON reports of STARTTLS-handshake failures to your accepted domains. Read the TLS-RPT primer to add transport-layer failure visibility alongside the SPF authentication this page configures.
• CAA records explained — alongside the SPF TXT record this page publishes in your Microsoft 365 tenant's DNS zone, a CAA record in the same zone constrains which certificate authority may issue TLS certificates for your domain — the complementary same-zone DNS control that hardens the certificate side while SPF hardens the sender side. Read the CAA primer to round out your DNS-zone security posture.
• RFC 7208 — SPF
• RFC 7489 — DMARC
• RFC 8617 — ARC (Authenticated Received Chain)
• RFC 8601 — Authentication-Results
• RFC 5321 — SMTP
• Microsoft SNDS + JMRP monitoring — the consumer-network half of the Microsoft story: authentication can be perfect and Outlook.com/Hotmail will still junk-folder mail from an IP with a degraded SNDS filter verdict; SNDS grades every sending IP GREEN/YELLOW/RED and JMRP streams each Junk click back as an ARF complaint report.

Verify your Microsoft 365 SPF record now

DMARC Analyzer parses the daily aggregate reports Microsoft, Google, Yahoo, and other receivers send to your rua= mailbox, deduplicates by report_id + org_name, and surfaces the per-sender / per-IP / per-day breakdown needed to spot the onmicrosoft.com alignment gotcha, missing third-party-sender authorisations, forwarding-induced SPF failures, and the realised SPF lookup count. Live DNS verification for every SPF, DKIM, and DMARC record on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Microsoft 365 SPF setup