Exchange SPF Check: How to Verify, Publish, and Fix SPF Records in Exchange

In May 2025, Microsoft began rejecting emails from high-volume senders that lacked valid SPF, DKIM, and DMARC. If your domain sends more than 5,000 messages per day to Outlook.com or Hotmail.com without proper authentication, those messages never reach the inbox.

Google and Yahoo introduced similar requirements in February 2024. That earlier round of enforcement reduced unauthenticated messages received by Gmail users by roughly 75%, according to Google’s email security team.

Business email compromise, which directly exploits weak email authentication, caused $2.9 billion in reported losses in 2023, according to FBI IC3 Internet Crime Report, 2023. 

The problem in Exchange environments is that SPF failures are silent. Exchange Online doesn’t alert you when your record breaks. There’s no native dashboard showing pass rates. Most teams find out weeks later, when users complain that emails are bouncing, or when marketing escalates that open rates have collapsed.

This guide covers how to check your Exchange SPF record across four methods, how to publish the correct record for Exchange Online, on-prem, and hybrid setups, how to fix the most common SPF errors (including the 10-lookup ceiling that breaks SPF in most mid-market organizations), how Exchange Online actually evaluates SPF under the hood, and how to monitor SPF continuously instead of checking it once and forgetting it.

How to Check Your Exchange SPF Record (Step by Step)

There are four reliable ways to check your SPF record, from fastest to the most comprehensive. Use Method 1 for quick verification, Method 4 for ongoing operational visibility.

Method 1: Use an SPF Lookup Tool (Fastest)

1. Open any SPF checker (the PowerDMARC SPF Checker is free and requires no signup)
2. Enter your domain (e.g., yourdomain.com, no http:// prefix) and 
3. Review the output

The lookup returns several SPF validation results. Here’s what each output field means and what you should pay attention to when reviewing it: 

A record can parse cleanly and lookup count can be six, but you can still be missing a legitimate sending source. The SPF checker validates what’s in DNS, but it doesn’t know which IPs should be authorized.

Method 2: Check via Microsoft 365 Admin Center

Sign in to the Microsoft 365 admin center. Navigate to Settings → Domains → select your domain → DNS records. Under the Microsoft Exchange section, check that the TXT record status shows OK.

If the status reads “Invalid entry,” your SPF record is either missing or doesn’t include the required include:spf.protection.outlook.com statement. This is the fastest way to verify SPF without leaving the admin portal.

Method 3: Check via Command Line (nslookup / dig)

For server-side troubleshooting or situations where you don’t have browser access, you can query your domain’s SPF TXT record directly from the command line.

Run one of the following commands: 

# Windows

nslookup -type=txt yourdomain.com

# Linux 

/ macOSdig txt yourdomain.com +short

The output returns the raw TXT record. Look for the line beginning with v=spf1. If you see two such lines, you have multiple SPF records, which is an immediate PermError. Fix it before doing anything else.

Method 4: Check via DMARC Aggregate Reports (The Gold Standard)

Aggregate reports from receivers, like Gmail, Yahoo, Microsoft, Mail.ru, regional ISPs, show SPF pass/fail rates across every email your domain sent, not just one test message. This is the only way to get an ongoing, complete picture of SPF health.

If you’re publishing DMARC with a rua= tag, you’re already collecting these reports. Most organizations have them, but only a few read them, because the raw XML is unreadable without a platform to parse it.

PowerDMARC ingests these reports daily and surfaces SPF-specific analytics in a dedicated dashboard with pass/fail rates per sending source, DNS lookup tracking, and alerts when a new unauthorized sender appears.

Method 5: Verify via Exchange Message Headers (Real-World Validation)

To verify how SPF is being evaluated by an actual recipient:

• Send a test message from your domain to an external address (a personal Gmail account works).
• Open the message and pull the full headers. In Outlook: File → Properties → Internet Headers. In OWA or Gmail: View Source / Show Original.
• Locate the Authentication-Results header and find the spf= field.

Here’s what the relevant header looks like annotated:

Authentication-Results: 

spf=pass (sender IP is 40.107.22.83)  

smtp.mailfrom=yourdomain.com;  

dkim=pass (signature was verified)  

header.d=yourdomain.com;  

dmarc=pass action=none  

header.from=yourdomain.com;  

compauth=pass reason=100

spf=pass confirms the sending IP was authorized by your SPF record. If you see spf=fail, spf=softfail, or spf=permerror, the specific result tells you what’s broken:

• spf=fail: The sending IP is not in your SPF record at all.
• spf=softfail: The IP isn’t authorized, but your record uses ~all instead of -all.
• spf=permerror: Your SPF record has a structural problem (>10 lookups, multiple records, syntax error).

What a Valid Exchange SPF Record Looks Like

How to Publish an SPF Record for Exchange Online (M365)

Publishing an SPF record for Exchange Online is simple. However, getting the inputs right is where most teams fail.

Step 1: Identify All Your Authorized Sending Sources

Before you touch DNS, audit every system that sends email on behalf of your domain. Most organizations underestimate this list by 30–50%.

• Microsoft 365 / Exchange Online → include:spf.protection.outlook.com
• Marketing automation (HubSpot, Mailchimp, Marketo, Pardot) → each has its own include
• CRM (Salesforce, Microsoft Dynamics) → check vendor SPF documentation
• Transactional email (SendGrid, Amazon SES, Postmark, Mailgun) → vendor-specific includes
• Helpdesk / ticketing (Zendesk, Freshdesk, ServiceNow) → vendor-specific includes
• HR / payroll (BambooHR, Gusto, Workday) → check if they send notifications as your domain
• Legacy on-premises servers → ip4: with the public-facing IPs

The most reliable way to discover senders you didn’t know about is DMARC aggregate reports. Every legitimate (and illegitimate) source sending as your domain shows up there.

Step 2: Construct the SPF Record

Start with the version tag, add authorized sources, and end with the qualifier.

Basic M365 example:

v=spf1 

include:spf.protection.outlook.com -all

Typical mid-market org with HubSpot and SendGrid:

v=spf1 

include:spf.protection.outlook.com 

include:_spf.hubspot.com 

include:sendgrid.net -all

Count your DNS lookups as you build. Each include:, a:, mx:, ptr:, and exists: mechanism triggers one lookup. ip4: and ip6: mechanisms do not count. Nested includes also count because include:spf.protection.outlook.com itself consumes 2–4 additional lookups internally as it chains through Microsoft’s infrastructure.

Step 3: Publish the Record in DNS

The publishing process varies slightly by DNS provider but follows the same pattern:

Settings to use consistently:

• Record type: TXT
• Host / Name: @ (or blank, provider-dependent)
• TTL: 3600 (1 hour) during testing, then 86400 (24 hours) once stable

Critical: Only one SPF record per domain. A second v=spf1 TXT record is a PermError waiting to be detected. If your DNS provider’s provisioning process auto-creates a record when you add a service, check for duplicates immediately.

Step 4: Verify the Published Record

• Wait 5–60 minutes for DNS propagation (depending on TTL and provider).
• Re-run the SPF lookup from Method 1 to confirm the record resolves correctly.
• Check the M365 admin center (Method 2). The TXT status should now show OK.
• Send a test message to an external address and inspect the headers for spf=pass.
• Confirm the DNS lookup count is below 10.

If you’d rather not assemble the record manually, the PowerDMARC SPF Generator outputs a properly formatted record once you list your sending sources.

SPF for Hybrid Exchange Environments: On-Prem + Cloud

Hybrid Exchange environments make SPF significantly more complex because email can originate from both Microsoft 365 and on-premises infrastructure at the same time. During migrations especially, mail flow paths often overlap in ways that create silent SPF failures unless every outbound route is accounted for correctly.

The Hybrid Challenge: Two Mail Paths, One SPF Record

In a hybrid environment, outbound mail can leave via three different routes:

• Exchange Online directly: for mailboxes hosted in M365
• On-premises Exchange or Edge Transport servers: for mailboxes still on-prem
• Smart hosts or third-party relays: when mail is routed externally before reaching the public internet

Each path presents the recipient server with a different source IP. SPF doesn’t care which path was intended because it only checks whether the IP it actually saw is authorized. Both paths must be covered in a single SPF record, because only one SPF record per domain is allowed.

How to Construct SPF for Hybrid Exchange

Include both authorization paths:

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

The on-prem IPs are the public-facing addresses your mail server uses when it sends to the internet, not the internal RFC 1918 addresses. Check your Edge Transport server’s send connectors and any NAT or firewall rules that determine the public-facing IP. If you have geographic redundancy or multiple outbound paths, every public IP that might originate mail needs to be in the record.

SPF During Migration (Transitional State)

Staged or cutover migration introduces a window where mailboxes exist in both locations and mail can leave from either path. SPF needs to cover both for the full duration.

• Before migration begins: Ensure your SPF record covers both the on-prem ip4: entries and include:spf.protection.outlook.com.
• During migration: Leave both authorizations in place. Monitor SPF pass rates via DMARC aggregate reports. If routing changes shift mail through unexpected paths, the reports show it before users do.
• After migration completes: Remove the on-prem ip4: entries. Leaving stale IPs in SPF is a security risk. If those old IPs are reassigned by your ISP or cloud provider, the new tenant can send authenticated mail as your domain.

Removing on-prem IPs during migration because the cutover is “almost done” is a common mistake. It only takes one mailbox still routing through the old path to break authentication for that user’s mail.

Subdomains in Exchange: SPF Does Not Inherit

A critical point that catches many hybrid organizations: subdomains do not inherit the parent domain’s SPF record. If marketing.yourdomain.com sends email through a separate ESP, it needs its own SPF TXT record. Wildcard SPF records are not supported by the protocol. Every subdomain that sends mail must have its own v=spf1 record published at its DNS root.

This also means that using subdomains is an effective strategy for distributing SPF load. Route marketing mail through marketing.yourdomain.com, transactional mail through mail.yourdomain.com so that each subdomain gets its own 10-lookup budget. This is RFC-compliant, well-supported by ESPs, and widely used in enterprise environments.

Does Exchange Online Check SPF on Intra-Tenant Mail?

No. Exchange Online treats intra-tenant messages as internal mail and does not perform SPF evaluation. Messages between different tenants, even trusted partner organizations, are subject to SPF checks, because that mail traverses the public mail-routing path.

For organizations with multiple domains in a single M365 tenant, each domain needs its own SPF record. Sharing a record across domains via CNAME is not standard practice and does not work reliably.

Common Exchange SPF Errors and How to Fix Them

Every troubleshooting scenario below follows the same diagnostic shape: Symptom → Cause → Fix.

PermError: Too Many DNS Lookups

• • Symptom: SPF returns PermError. Recipients may junk or reject your email. DMARC alignment fails.
  • Cause: More than 10 DNS lookups in your SPF record, including nested includes. This is the single most common SPF failure in organizations using multiple SaaS services.

• Fix (5-step workflow):

• • Step 1: Audit your current lookup count using an SPF checker that recursively counts nested includes.
  • Step 2: Remove stale includes for services you no longer use.
  • Step 3: Replace include: with ip4: mechanisms where the vendor’s IPs are stable and documented.
  • Step 4: Move high-volume, non-corporate senders (marketing, transactional) to subdomains with their own SPF records.
  • Step 5: If you’re still over 10, implement SPF flattening or macros using a tool like PowerSPF to auto-resolve includes into ip4 entries and keep the record updated when vendors change IPs.

Before/after example:

Before (14 lookups: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com  include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com  include:zendesk.com include:spf.freshdesk.com a mx -all

After (7 lookups: under limit):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com  include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce and Zendesk moved to mail.yourdomain.com# Freshdesk replaced with flattened ip4 entries# a and mx mechanisms removed (redundant with explicit includes)

Multiple SPF Records Found

• Symptom: SPF checker returns a “multiple SPF records” error. All SPF evaluation fails.
• Cause: Two or more TXT records starting with v=spf1 exist for the same domain. This commonly happens when a SaaS vendor’s provisioning process creates a second record without the admin noticing.
• Fix: Merge into one record. You can have many include: and ip4: mechanisms inside one record, but only one v=spf1 TXT record per domain. Delete the redundant entry.

SPF Fails After Adding a New SaaS Tool

• Symptom: Emails from the newly added tool fail SPF. Other senders may also break if the new include pushed total lookups over 10.
• Cause: The new service’s include: wasn’t added to SPF, or adding it exceeded the lookup limit.
• Fix: Add the include, then re-audit total lookups. If you’re now over 10, the lookup count, not the include itself, is the problem. Apply the 5-step workflow above.

SPF Fails in Hybrid Exchange (On-Prem IP Missing)

• Symptom: Emails sent from on-premises Exchange fail SPF, while M365-originated mail passes.
• Cause: The on-premises server’s public-facing IP isn’t in the SPF record. This is especially common after a partial migration where the admin updated SPF for Exchange Online but forgot the on-prem path still routes mail.
• Fix: Add ip4:x.x.x.x for every on-prem outbound egress IP. If mail routes through an Edge Transport server, smart host, or third-party relay, that relay’s public IP needs to be included too.

SPF Fails After Exchange Online Migration

• Symptom: Post-migration emails fail SPF across the board.
• Cause: DNS still points to old on-prem IPs, include:spf.protection.outlook.com wasn’t added, or mail is routing through unexpected paths during the transition.
• Fix: Verify the SPF record includes both old (on-prem) and new (Exchange Online) authorization paths during the migration window. Remove old entries only after 100% of mailboxes are confirmed migrated. Monitor with DMARC aggregate reports throughout. They show you exactly which paths your mail is taking from the receivers’ perspective.

SPF Passes But Email Goes to Spam

• Symptom: Headers show spf=pass but the message lands in the recipient’s junk folder.
• Cause: SPF is one signal among many. Sender reputation, content, DKIM, or DMARC may be failing. Any of those can overrule a clean SPF pass.
• Fix: Check DKIM alignment, DMARC policy, sender reputation (blacklist status, domain age, recent volume changes), and content/link reputation. PowerDMARC’s Domain Analyzer returns a grade across all of these in a single scan.

SPF Fails for Forwarded Emails

• Symptom: Auto-forwarded messages, mailing list emails, or transport rule-routed messages fail SPF.
• Cause: The forwarding server’s IP isn’t in the original sender’s SPF record. This is SPF’s architectural limitation rather than a configuration error.
• Fix: Treat SPF failure on forwarded mail as expected behavior. Ensure DKIM is properly configured for your domain. DKIM signatures survive forwarding, which allows DMARC to pass via DKIM alignment even when SPF fails. ARC (Authenticated Received Chain) in Exchange Online further preserves authentication results across trusted forwarding chains.

How Exchange Online Actually Processes SPF Results (The Black Box Explained)

Most Exchange admins run into the same confusion: how does Exchange Online Protection (EOP) actually treat SPF failures? Some sources say hard fail means automatic rejection. Others suggest SPF is only a minor spam signal. Here’s how it actually works.

The Multi-Signal Pipeline (SPF Is Just One Input)

Exchange Online Protection does not make delivery decisions based on SPF alone. SPF is one input into a composite authentication evaluation that includes:

• SPF result: pass, fail, soft fail, neutral, PermError, or TempError
• DKIM result: pass, fail, or none
• DMARC result: derived from alignment of SPF or DKIM with the header From domain
• Sender reputation: IP reputation, domain reputation, historical sending patterns
• Spam Confidence Level (SCL) scoring: Microsoft’s internal score from -1 (safe sender) to 9 (high-confidence spam)
• Content filtering: keywords, URL reputation, attachment analysis

The composite authentication result, not any single protocol, is what EOP uses to determine final message disposition.

How EOP Handles Each SPF Outcome

PermError is a hard failure that EOP treats almost identically to an outright SPF fail, and it cascades into DMARC, breaking authentication entirely. This is why the 10-lookup limit is a structural failure point.

Where to See SPF Results Inside Exchange

Three places, in increasing order of completeness:

• Message headers (Authentication-Results): Every message processed by EOP gets stamped with spf=pass/fail/softfail/permerror/temperror, along with the evaluated sending domain and IP.
• Exchange message trace: Shows delivery status, source IP, recipient, and final disposition, but does not prominently display the SPF evaluation. If you’re relying on message trace alone for SPF visibility, you’re flying blind.
• DMARC aggregate reports (RUA): The only data source that shows how receivers worldwide are evaluating your SPF. RUA reports surface per-IP, per-source SPF pass and fail rates across every receiving server that processes your mail.

Configuring SPF Hard Fail Enforcement in EOP

By default, Exchange Online factors SPF results into its composite scoring but does not reject on SPF alone. To explicitly configure EOP to mark SPF hard-fail messages as spam:

In the Exchange Online admin center: navigate to Protection → Spam filter → Advanced options, and turn the “SPF record: hard fail” switch to On. Alternatively, run the following PowerShell cmdlet:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} |  Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

SPF Best Practices for Exchange Environments in 2026

• Use -all (hard fail) as your default qualifier. Combined with DMARC, -all is the standard. The only exception is the initial deployment window before DMARC is in place.
• Never use +all. It authorizes the entire internet to send as your domain. If you find +all in your record, treat it as an active security incident.
• Always include spf.protection.outlook.com for M365, even if outbound mail routes through a third-party gateway. Exchange Online generates calendar invites, auto-replies, NDRs, and read receipts that ship directly from Microsoft’s infrastructure.
• Audit your SPF record quarterly at minimum. SaaS vendors change IP ranges. Marketing teams adopt new tools without telling IT. Quarterly audits catch drift before it causes PermError. Continuous monitoring via DMARC reports catches drift in real time.
• Deploy SPF alongside DKIM and DMARC. SPF alone doesn’t prevent header-from spoofing. DKIM alone doesn’t validate envelope sender. Only DMARC enforcement, checking SPF or DKIM alignment with the header From domain, provides comprehensive protection.
• Comply with sender requirements from all major receivers. In 2026, Google, Yahoo, Microsoft, and Apple all require SPF + DKIM + DMARC for bulk senders. PCI DSS v4.0, mandatory since March 2025, explicitly requires all three as anti-phishing controls.

How to Monitor SPF Continuously 

The single biggest gap between organizations with “SPF set up” and organizations actually protected by SPF is monitoring. One-time configuration is the easy part, but detecting silent failures over the months that follow is what separates working email authentication from theoretical email authentication.

Why One-Time SPF Checks Create a False Sense of Security

SPF records drift constantly because vendors change their authorized IP ranges, your include: chains resolve to different IPs, and one of them may push you over the lookup limit. Teams add new SaaS tools without updating SPF. Migrations alter outbound mail routing in ways your DNS doesn’t reflect. Old entries remain for services the organization stopped using years ago.

What Continuous SPF Monitoring Looks Like

Four components, each addressing a specific failure mode:

• DMARC aggregate reports ingested daily from receivers worldwide. These show per-IP, per-source SPF results across every receiving server that processed your mail. PowerDMARC ingests these automatically and surfaces them in a dedicated SPF analytics dashboard with pass/fail rates by source, DNS lookup-count tracking, and historical trend lines.
• Automated alerts the moment SPF failures cross a threshold, when a new unauthorized sending source appears, or when a DNS change affects your record. PowerDMARC’s PowerAlerts routes these via email, Slack, or Discord so the right team sees the issue during business hours.
• Automated SPF flattening that updates when third-party providers change IPs. PowerSPF resolves include: chains into ip4: entries and keeps your record permanently under 10 lookups without manual DNS edits.
• Blacklist and reputation monitoring. If your sending IPs end up on a blocklist, SPF may pass but deliverability still degrades. Integrated reputation monitoring catches the failure mode that SPF alone doesn’t see.

For MSPs specifically: when a client’s vendor changes their IP range, you know about it before the client’s email breaks. 

PowerDMARC’s MSP Dashboard provides centralized SPF monitoring across all client domains from a single screen, with per-tenant drill-down. That changes SPF management from reactive firefighting into a productized service line.

Start a 15-day free trial to try it yourself. 

Frequently Asked Questions

How do I check SPF records in Exchange Online?

Use an SPF lookup tool like the PowerDMARC SPF Checker, enter your domain and review the record, syntax, and lookup count. You can also verify in the Microsoft 365 admin center under Settings → Domains → DNS records. For recipient-side verification, check the Authentication-Results header in a test message sent externally.

What SPF record do I need for Microsoft 365?

At minimum: v=spf1 include:spf.protection.outlook.com -all. If you use additional sending services (HubSpot, SendGrid, Salesforce, Zendesk), add their includes before -all. Ensure total DNS lookups stay under 10, including nested lookups inside each include:.

Why is SPF failing even though my record looks correct?

Common causes: exceeding the 10 DNS lookup limit (PermError), having multiple SPF records on the same domain, forwarded emails (SPF breaks on forwarding by design), or a vendor changing their authorized IP ranges without notifying you. Check the Authentication-Results header for the specific spf= result.

What’s the difference between -all and ~all?

-all (hard fail) instructs receivers to reject or fail messages from unauthorized IPs. ~all (soft fail) is more permissive. In 2026, with DMARC deployed, the DMARC policy controls enforcement regardless of qualifier. If you don’t have DMARC yet, -all provides significantly stronger protection.

How many DNS lookups does include:spf.protection.outlook.com use?

The Microsoft include counts as 1 lookup, but it chains to nested includes that consume approximately 2–4 additional lookups. The exact number varies as Microsoft updates infrastructure. Always verify with a checker that recursively counts nested lookups.

Is SPF enough to stop email spoofing?

No. SPF alone does not prevent spoofing of the visible From: address (header From). It only validates the envelope sender (Return-Path). Comprehensive protection requires DKIM for message-level signing plus DMARC to enforce alignment. All three protocols working together, and monitored continuously, is the standard in 2026.