Fix Microsoft 365 Error 550 5.7.23: SPF Validation Failed

What This Error Means

Microsoft 365 error 550 5.7.23 is a permanent rejection. Exchange Online Protection (EOP) evaluated your sending IP against the sender domain's SPF record and determined the IP is not authorized. The fix: add the missing IP or include: mechanism to your SPF record, or resolve the PermError causing SPF evaluation to fail.

The full error message is typically:

550 5.7.23 The message was rejected because of Sender Policy Framework violation ->
The sending mail server IP address is not in the sender domain SPF record.
Contact the sender's postmaster for more information.

or:

550 5.7.23 Access denied, a message was rejected. The message was rejected
because of the sender's SPF check failure.

This is a permanent rejection (5xx), not a temporary deferral. EOP evaluated the sending IP against the sender domain's SPF record and determined the IP is not authorized to send email for that domain.

Why Microsoft Is Strict About SPF

Microsoft 365 processes hundreds of billions of emails monthly. EOP uses SPF as a primary front-line defense against spoofing. When EOP encounters an SPF failure, it evaluates the result alongside DKIM and DMARC, but in many configurations — especially when the sender domain publishes -all (hard fail) or has a DMARC policy of p=reject — the message is rejected at the SMTP level before any further processing.

Key difference from other providers: EOP may reject more aggressively on SPF failures in some configurations, even without a DMARC policy. Gmail tends to route SPF-failing messages to spam rather than rejecting outright. This means SPF misconfigurations that appear to "work" with Gmail can produce hard bounces with Microsoft 365 recipients, depending on the recipient tenant's EOP settings.

Step-by-Step Diagnosis

Step 1: Check Your SPF Record

Use the mxio SPF Checker on the domain shown in the Return-Path (envelope sender) of the rejected message. This is the domain EOP evaluates for SPF — not necessarily the From: header domain.

Look for:

• Is the record valid? Syntax errors cause a PermError, which EOP treats as a failure
• Is the sending IP included? Check whether the IP address of the server that attempted delivery is covered by the record's ip4:, ip6:, include:, a:, or mx: mechanisms
• How many lookups? If the record exceeds 10 DNS lookups, EOP receives a PermError and rejects the message
• Multiple SPF records? If you have two or more SPF TXT records on the domain, the result is a PermError

Step 2: Identify the Sending IP

Find the IP address that EOP rejected. You can get this from:

• The bounce message itself (often includes the connecting IP)
• Your mail server logs (look for the SMTP session to the Microsoft MX)
• The mxio Header Analyzer if you have the full headers of a similar delivery attempt

Compare this IP to what your SPF record authorizes. If the IP is not covered, that is your problem.

Step 3: Check the Return-Path Domain

EOP evaluates SPF against the Return-Path (MAIL FROM) domain, not the From: header domain. If your email is sent through a third-party service, the Return-Path might be set to the service's domain (e.g., bounces@sendgrid.net), in which case SPF is evaluated against sendgrid.net, not your domain.

This matters for DMARC alignment but typically would not cause a 5.7.23 rejection by itself — unless the third-party service's own SPF record is also failing.

Common Causes Specific to Microsoft 365

1. Missing include:spf.protection.outlook.com

If your organization uses Microsoft 365 for sending (Exchange Online) and you send to external Microsoft 365 tenants, your SPF record must include Microsoft's sending infrastructure:

v=spf1 include:spf.protection.outlook.com [other includes] ~all

This is the most common fix for organizations that recently migrated to Microsoft 365 or set up a hybrid Exchange environment. Without this include, email sent through Exchange Online to external recipients fails SPF.

2. On-Premises Relay Not in SPF

In hybrid Exchange deployments, on-premises servers relay email through Exchange Online or directly to the internet. If your on-premises server sends email directly (not through Exchange Online):

• The server's public IP must be in your SPF record as an ip4: mechanism
• If the server uses a NAT gateway, include the NAT gateway's public IP, not the server's internal IP

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

If your on-premises server relays through Exchange Online using a connector, the outbound IP is a Microsoft IP covered by include:spf.protection.outlook.com.

3. Third-Party Email Security or Archiving

Organizations using email security gateways (MailRoute, Mimecast, Proofpoint, Barracuda) or archiving services in front of Exchange Online often have mail flow that looks like:

Sender -> Security Gateway -> Exchange Online -> Recipient

If the security gateway re-sends or relays email with a modified envelope sender, and the gateway's IPs are not in the original sender's SPF record, the recipient's EOP sees an SPF failure. This is common when:

• The gateway modifies the Return-Path during processing
• Outbound filtering changes the sending IP from what the SPF record authorizes
• The gateway is configured as a send connector but its IPs are not in SPF

4. Shared Hosting IP Not in SPF

If you send email from a web application hosted on shared infrastructure (cPanel, Plesk, cloud VPS), the sending IP may not be in your SPF record. Shared hosting environments often have outbound email IPs that differ from the web server IP.

Check with your hosting provider which IP addresses are used for outbound SMTP, and add them to your SPF record:

v=spf1 ip4:198.51.100.25 include:spf.protection.outlook.com ~all

5. SPF Record Exceeds 10 Lookups

Microsoft 365 strictly enforces the 10-lookup limit defined in RFC 7208. If your SPF record includes many third-party services, the total lookup count exceeds the limit, producing a PermError that EOP treats as a hard failure.

Use the mxio SPF Checker to see your exact lookup count. If you are over the limit, see Fix SPF PermError: Too Many DNS Lookups for solutions including SPF flattening. For a permanent solution, mxio's Managed SPF keeps your record under the lookup limit automatically — IP ranges are resolved and updated on a schedule, so provider changes never break your SPF.

6. DNS Propagation After Recent Changes

If you recently updated your SPF record, DNS propagation may not have completed. TTL values for TXT records vary — some providers set TTLs as high as 3600 seconds (1 hour) or more. During propagation, some resolvers return the old record while others return the new one.

Use the mxio TXT Lookup to verify that the record you expect is actually being served. If the old record is still cached, wait for the TTL to expire and test again.

Fixes by Scenario

Testing After the Fix

After updating your SPF record:

1. Wait for DNS propagation — At least as long as your TXT record's TTL
2. Verify with SPF Checker — Use the mxio SPF Checker to confirm the record is valid and includes the correct IPs
3. Send a test message — Send to a Microsoft 365 recipient and check delivery
4. Analyze headers — Use the mxio Header Analyzer on the delivered test message to confirm spf=pass in the Authentication-Results
5. Check DMARC alignment — While you are fixing SPF, verify that DKIM is also configured and that DMARC alignment passes. Use the mxio DMARC Checker to review your policy.

Prevention and Ongoing Monitoring

SPF records break silently. A third-party provider changes their IP ranges, a new service gets added without updating DNS, or a record edit introduces a syntax error. None of these produce an immediate alert — you find out when emails start bouncing.

• EOP respects both ~all (softfail) and -all (hardfail), but treats -all more severely. Messages failing against -all are more likely to be rejected outright.
• EOP evaluates SPF before content filtering. A hard SPF failure with -all can cause rejection before any spam or content analysis occurs.
• Microsoft's own IPs change periodically. The include:spf.protection.outlook.com mechanism resolves to Microsoft-managed IP ranges updated automatically. Never flatten Microsoft's include into static IPs — use the include mechanism so changes propagate automatically.
• Connectors affect SPF evaluation. If you have configured inbound connectors in Exchange Online, EOP may evaluate SPF differently based on connector settings. Verify that your connectors are not interfering with SPF evaluation for external mail.

Set up domain health monitoring to catch SPF record changes, lookup limit breaches, and DNS misconfigurations the moment they happen — before they cause 5.7.23 bounces.

Related Issues

• SPF PermError: Too Many DNS Lookups — Exceeding the 10-lookup limit
• Multiple SPF Records — Having two SPF records on one domain
• SPF Flattening Explained — How flattening solves the lookup limit
• Emails Going to Spam — Broader deliverability troubleshooting
• Email Bounce Codes — Complete SMTP error code reference