550 5.7.23: Fix the SPF Check Failed Bounce

Problem

Your mail bounces with 550 5.7.23 and text like “The message was rejected because of Sender Policy Framework violation.” The recipient’s server — very often Exchange Online / Microsoft 365 — checked the IP your message came from against the SPF record of your sending domain, didn’t find it authorized, and refused the message. Nothing landed in the inbox, and retrying the same message from the same server won’t change the outcome.

Symptoms

• Bounce or NDR contains 550 5.7.23 and a “Sender Policy Framework” or “SPF” phrase; Microsoft’s exact wording is “The message was rejected because of Sender Policy Framework violation.”
• Mail from your main mail system delivers fine, but mail from a new app, a script, a marketing tool, or an on-premises server bounces.
• The message is accepted when sent directly, but bounces when it’s forwarded through an intermediary.
• Recipients on Microsoft 365 / Outlook reject it while some other providers still accept it.
• An SPF lookup of your domain “looks fine,” yet the mail still fails — because the failing IP or the return-path domain isn’t the one you checked.

What 550 5.7.23 Actually Means

Read it as two facts. The 550 is a permanent SMTP rejection (RFC 5321) — the receiver is done with this message, not asking you to try later. The 5.7.23 is the enhanced status code, and unlike the vague 5.7.1, it names the reason: a Sender Policy Framework failure. The receiving server took the IP address that connected to it, looked up the SPF record of your sending domain, and the record’s rules said that IP is not allowed to send for the domain — most often because the record ends in -all (a hard fail) and the IP simply isn’t listed.

Two words decide everything here, and neither is the one people check first. SPF evaluates the connecting IP, not your server’s name or your header From. And it evaluates the record of the return-path (MAIL FROM) domain, the envelope sender, which for mail sent through a third party is frequently not the domain in your visible From. That’s why a message can carry a From address whose domain has a picture-perfect SPF record and still earn a 5.7.23: the receiver checked a different domain, or checked an IP you never put in the record.

It also matters that this is not an alignment or DMARC failure. Gmail’s 5.7.26 means “no aligned SPF and no aligned DKIM.” Microsoft’s 5.7.509 means “your own DMARC policy said reject.” 5.7.23 is narrower and older-fashioned: the raw SPF check for the envelope domain returned fail. Fix the SPF authorization for the real sending path and 5.7.23 goes away, regardless of what DKIM or DMARC are doing.

Top 3 Causes

1. A sending source that isn’t in your SPF record. A new SaaS platform, a transactional-mail service, an on-premises relay, or a one-off script sends “as your domain” from an IP you never added, while your record ends in -all. The hard fail plus the unlisted IP is exactly the 5.7.23 condition. The tell: it’s a recently added or unusual sender, and its IP or vendor include: is missing from your v=spf1 record.
2. Forwarding breaks the SPF path. The original send passes, but a mailbox or list forwards the message onward, and the forwarding server relays it from its IP — not yours — so SPF fails at the final hop. The tell: the message only bounces when it’s forwarded, and the failing IP in the headers belongs to the forwarder, not you.
3. A shared or hybrid IP that fails the check. Outbound mail flagged as risky can be routed through a shared high-risk delivery pool whose IP isn’t in your record, or a hybrid/on-prem connector sends from an address you forgot to authorize. The tell: intermittent 5.7.23 on a subset of mail, from an IP inside your provider’s or your own infrastructure that the SPF record doesn’t cover.

Diagnose with DechoNet

• Email Check pulls your domain’s SPF record and evaluates it — so you can see the exact mechanisms, whether it ends in -all or ~all, and whether it resolves within the 10-lookup limit (RFC 7208 §4.6.4) before it even reaches the all rule. That tells you what IPs your record currently authorizes.
• Email Header Analyzer reads a bounced or received message’s Authentication-Results and Received-SPF lines, showing the IP the receiver evaluated and the domain it checked — the fastest way to see whether 5.7.23 came from a missing IP, a return-path domain you didn’t expect, or a forwarding hop.

Resolution Checklist

• Confirm the code is 5.7.23, not 5.7.1, 5.7.26, or 5.7.509 — 5.7.23 is a raw SPF authorization failure, so the fix lives in your SPF record, not your DMARC policy or DKIM alignment.
• From the bounce and headers, identify the exact sending IP and the return-path domain the receiver checked with Email Header Analyzer.
• Run Email Check on that domain and confirm the missing IP or service isn’t covered by the current record.
• Add the legitimate source: the vendor’s documented include: (for Microsoft 365, include:spf.protection.outlook.com) or the specific ip4:/ip6: for your own relay — keeping total DNS lookups under 10 and only one SPF TXT record on the domain.
• If the failure is forwarding-only, don’t chase forwarder IPs — set up DKIM so the message stays authenticated across hops, and publish DMARC so it passes on DKIM alignment when SPF breaks.
• Re-send and re-check the headers to confirm spf=pass for the real sending IP and envelope domain.

When to Escalate

• If the failing IP belongs to your email provider’s shared infrastructure (a high-risk delivery pool or a platform relay) and their documented include: still doesn’t cover it, that’s a provider-side routing issue — take the bounce and the offending IP to their support rather than widening your record blindly.
• If SPF now passes for the envelope domain and the receiver still returns 5.7.23, capture the full bounce plus the Received-SPF and Authentication-Results headers — the receiver is evaluating a domain or IP you haven’t accounted for, and those lines name exactly which one.