Microsoft 365 sent your message, and the destination server rejected it because SPF failed: the server it came from isn’t listed in the SPF record of your envelope sender domain. Check that record below, then find the server it doesn’t list and add it.
Last verified 9 October 2026.
Microsoft’s list of Exchange Online bounce codes gives 5.7.23 this message and explanation:
5.7.23 The message was rejected because of Sender Policy Framework violation
“The destination email system uses SPF to validate inbound mail, and an issue affects your SPF configuration.”
The code itself comes from RFC 7372 §3.2, which registers X.7.23 with the sample text “SPF validation failed” and says it “is returned when a message completed an SPF check that produced a ‘fail’ result, contrary to local policy requirements.” So you may see either wording. In order, this is what happened:
Return-Path), not the From: address you see. For mail a Microsoft 365 user sends, that is normally the sender’s own domain.-all and doesn’t list that IP (RFC 7208 §2.6.4: fail “is an explicit statement that the client is not authorized to use the domain in the given identity”).Who fixes it: the sending side. Microsoft’s fix page says “Only an email admin in your Microsoft 365 or Office 365 organization can fix this issue.” If you got the bounce as a user, forward it to your admin. The recipient can’t make your SPF pass: the record and the sending servers are yours.
A 5xx code is a permanent rejection: resending the same message the same way gets the same bounce.
Sources: Microsoft Learn, Fix NDR error “550 5.7.23” in Exchange Online and Email non-delivery reports and SMTP errors in Exchange Online; RFC 7372 §3.2; RFC 7208 §2.6.4 and §8.4 (checked 9 October 2026).
Enter the domain from the Return-Path of the bounced message (usually the domain in your own address). The lookups run in your browser against public DNS: they read the SPF record, follow every include and redirect, count DNS lookups, and show whether Microsoft 365’s include is in the record before its all.
This shows what the domain publishes, not which server sent the bounced message. To compare an IP from the bounce, look for it in the ip4: and ip6: ranges under “Records checked”.
What this can and can’t tell you: it reads the records the domain publishes right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). A lookup that fails shows as unknown, never as missing. It doesn’t test a specific IP address against the record. For the PermError detail of every term, use the SPF PermError check; for a full A–F grade with DMARC and DKIM, the DMARC checker.
<Forwarding Mailbox Local Part>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>, so that domain’s SPF record is the one checked.OutboundIpPoolName property, which Microsoft says “contains a friendly name value for the outbound pool that was used.” That tells you whether the message left through the normal pool or the high-risk or relay pool (below).Microsoft’s fix page lists these steps: verify the SPF record, provision all your domains, add on-premises IPs, and check whether the message went out through the High Risk Delivery Pool. Here is each one, with the record changes.
Microsoft: “Most Microsoft 365 organizations require include:spf.protection.outlook.com in the SPF TXT record for the domain.” For a domain that sends only through Microsoft 365:
v=spf1 include:spf.protection.outlook.com -allGCC High and DoD use include:spf.protection.office365.us, and Microsoft 365 operated by 21Vianet uses include:spf.protection.partner.outlook.cn. You publish the record at your DNS host; Microsoft 365 has no setting for it.
Microsoft: “Add your on-premises IPs, if any, to the SPF record of any domains you send for. This would include any unprovisioned domains you might be relaying through Microsoft 365 or Office 365.” In a hybrid setup, that is the public IP your Exchange Server sends from. Other services that send with your domain in the Return-Path (a CRM, help desk, newsletter tool) need their own include:, from their setup guide.
Before: a hybrid organisation’s on-premises server at 192.0.2.25 (a documentation address; use your own) sends mail for example.com, and the record lists only Microsoft 365, so that server’s mail gets SPF fail:
v=spf1 include:spf.protection.outlook.com -allAfter: the same record, edited in place, with the server added:
v=spf1 ip4:192.0.2.25 include:spf.protection.outlook.com -allTwo rules while you edit. Keep one SPF record per name: Microsoft says multiple SPF records “cause SPF to return permerror”, so add to the existing record rather than publishing a second (merge duplicates). And stay at 10 DNS lookups or fewer: each include, a, mx, ptr, exists and redirect counts, nested ones too, while ip4 and ip6 don’t (how to cut them). Over 10 is a PermError, and SPF can’t pass at all.
Microsoft: “Provision all of the domains you own. We limit the number of emails with unprovisioned domains that a tenant can send.” Add each domain your users or applications send as to Microsoft 365 as an accepted domain, and give it an SPF record. A domain you own but never send from can publish v=spf1 -all.
Microsoft sends outbound mail it determines to be spam through a separate high-risk delivery pool, and its fix page says: “Messages in the High Risk Delivery Pool won’t pass SPF checks, and therefore won’t be accepted by the destination email organization.” Microsoft also says “Messages where the source email domain has no A record and no MX record defined in public DNS are always routed through the high-risk delivery pool”; the checker above tests for that. If message trace shows this pool and the message wasn’t spam, look for a compromised account or a misbehaving application first, then contact Microsoft support, as the fix page advises.
Forwarding resends a message from the forwarder’s server, so the original sender’s SPF can’t cover it. Microsoft 365 handles most of this with the Sender Rewriting Scheme, which “rewrites the MAIL FROM address … for all applicable messages sent from Microsoft 365 to external recipients”, so SPF is checked against your forwarding domain, which your record covers with step 1. The case it doesn’t fix is the relay pool: in some cases Microsoft sends forwarded or relayed mail from a separate pool that is “not part of published SPF record for Microsoft 365”. A message avoids it if the sender is in one of your accepted domains or SPF passed when the message arrived. Microsoft’s SRS page: “This behavior mainly affects messages entering Exchange Online that fail SPF checks. SRS doesn’t fix these failures.” If your MX points to another service or an on-premises server first, Microsoft recommends Enhanced Filtering for Connectors so SPF is evaluated correctly on arrival.
SRS can make SPF pass for a forward, but SPF then passes for your forwarding domain, not the original sender’s, so DMARC still depends on the original DKIM signature. See DMARC alignment failed for how that works.
Sources: Microsoft Learn, Fix NDR error “550 5.7.23” in Exchange Online; Set up SPF to identify valid email sources for your Microsoft 365 domain; Outbound delivery pools; Sender Rewriting Scheme (SRS) in Microsoft 365 (checked 9 October 2026).
5.7.23 | SPF ran and gave fail: the sending IP isn’t in the record. This page. |
|---|---|
5.7.24 | RFC 7372’s “SPF validation error”: SPF couldn’t be evaluated (permerror or temperror). See SPF PermError and SPF TempError. |
5.7.509 | The message failed DMARC and the From: domain’s policy is p=reject. See fixing 550 5.7.509. |
5.7.515 | Outlook.com’s rule for high-volume senders: the domain doesn’t meet the required SPF, DKIM and DMARC level. See fixing 550 5.7.515. |
The sending side. The destination server rejected your message because SPF failed for your envelope sender domain, and only that domain’s SPF record, or the server the mail left from, can change the result. Microsoft says only an email admin in your Microsoft 365 organization can fix it, so forward the bounce to your admin.
Because the message left from a server that the record doesn’t cover: an on-premises or hybrid server, another service sending as your domain, or one of Microsoft’s separate pools. Mail Microsoft classifies as spam goes out through the high-risk delivery pool, which Microsoft says won’t pass SPF checks, and some forwarded or relayed mail goes through the relay pool, which isn’t part of Microsoft 365’s published SPF record. Message trace shows which pool sent it.
No. RFC 7372 defines 5.7.23 for an SPF fail result, which -all produces, and some receivers may accept a softfail instead, but the message still isn’t authenticated, and Microsoft says DMARC treats -all and ~all as SPF failures. Microsoft recommends -all for Microsoft 365 domains. Add the missing server to the record instead.
Yes. A forwarded message reaches the destination from the forwarder’s server, not yours. Microsoft 365 rewrites the envelope sender of mail it autoforwards (Sender Rewriting Scheme), so SPF is checked against the forwarding domain. But a forwarded or relayed message that isn’t from one of your accepted domains and failed SPF when it arrived can go out through Microsoft’s relay pool, which isn’t in Microsoft 365’s SPF record, and SRS doesn’t fix that.
If you manage sending domains for clients or brands, Email Security Signals runs SPF, DMARC and DKIM checks on a whole list and returns one row per domain with the DMARC policy, SPF lookup count, DKIM selectors found and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →Related: fixing 550 5.7.509 (DMARC policy of reject), fixing 550 5.7.515 (Outlook.com high-volume senders), fixing SPF PermError, fixing SPF “too many DNS lookups” and the free DMARC, SPF and DKIM checker.