What does 550 5.7.23 mean?
Microsoft returns this error when SPF evaluation fails for an inbound message. The diagnostic string is:
550 5.7.23 The message was rejected because of Sender Policy Framework violation
This is Microsoft's SPF-specific NDR code for SPF validation failure. Unlike 550 5.7.26 (Gmail's DMARC rejection) or 550 5.7.515 (Outlook's bulk sender rejection), this error focuses specifically on SPF — the sending IP wasn't authorized by the domain's published SPF record.
Microsoft has a dedicated troubleshooting article for this error, which means it's a well-known and frequently encountered rejection in Microsoft mail flows.
DMARCit tracks SPF results for every sender and alerts you when a sending source fails SPF — before it triggers rejections.
Why did this happen?
Cause 1: The sending IP isn't in your SPF record
The most straightforward cause. A legitimate service is sending email as your domain, but its sending IP (or IP range) isn't covered by any mechanism in your SPF record. This often happens when a new service is set up and the SPF record isn't updated, or when the service's sending IPs change.
Cause 2: SPF PermError from exceeding the 10-lookup limit
If your SPF record exceeds 10 DNS-querying mechanisms, receivers return PermError — which Microsoft treats as an SPF failure. This can trigger 550 5.7.23 even for senders whose IPs are technically listed in your record, because the receiver never finishes evaluating it. → See: SPF PermError — Too many DNS lookups.
Cause 3: Multiple SPF records on the same domain
Two TXT records both starting with v=spf1 on the same domain cause an immediate PermError. Every message fails SPF until the duplicate is removed.
Cause 4: SPF syntax error
A malformed SPF record, such as an invalid mechanism or syntax error, can cause PermError and trigger this rejection.
Cause 5: Email forwarding changed the sending IP
The message was forwarded by an intermediate server. The forwarding server's IP replaces the original sender's IP in the SMTP connection, but the Return-Path still points to the original sender's domain. SPF fails because the forwarding server isn't in the original domain's SPF record.
How to fix 550 5.7.23
Step 1: Identify the sending IP and source
Check the bounce message or full headers for the IP address that Microsoft rejected. Look at:
| Header field | What it tells you |
|---|---|
Return-Path: | Which domain SPF was evaluated against |
Sending IP (in bounce or Received: headers) | Which IP connected to Microsoft's servers |
Authentication-Results: | The SPF result (fail, permerror, softfail) |
Step 2: Determine if the sender is legitimate
If the IP belongs to a service you recognize (your email platform, a marketing tool, a transactional sender), it needs to be authorized. If you don't recognize it, it may be a spoofed message — in which case SPF did its job correctly.
Step 3: Fix the SPF record
- Missing sender: Add the service's
include:directive or the specificip4:/ip6:address to your SPF record. - Too many lookups: Audit and reduce your lookup count. → See: SPF PermError.
- Duplicate records: Remove the extra
v=spf1TXT record so only one exists. - Syntax error: Validate your SPF record with a checker tool and fix any malformed mechanisms.
Step 4: Confirm the fix
After updating DNS, wait for propagation (typically minutes to a few hours for TXT records), then verify SPF passes for the sending source. Check your DMARC aggregate reports within 24- 48 hours to confirm the fix across all receivers, not just Microsoft.
This isn't a one-time fix
Email authentication tends to break again because:
- New sending services need SPF updates. Every time your organization adds a service that sends email as your domain, the SPF record may need an update. If the service isn't added, its messages fail SPF.
- The 10-lookup limit is a persistent constraint. Adding a new include may push you over the limit, breaking SPF for all senders — not just the new one.
- Vendor IP ranges change. If you use
ip4:entries or flattened records instead ofinclude:directives, vendor IP rotations can silently break your SPF. - Forwarding is a common cause. Server-side forwarding commonly breaks SPF because the forwarding server's IP is not in the original sender's SPF record.
The most reliable way to catch SPF failures across all senders is continuous monitoring of your DMARC aggregate reports.
Catch SPF failures before they become rejections
DMARCit shows which services are actually sending as your domain and whether SPF is passing for each one. When a sender fails SPF, you'll see it in your dashboard — not in a bounce message from a client.
7-day free trial · Cancel anytime