What it looks like in your logs
550 5.7.23 The message was rejected because of Sender Policy Framework violation [BN8NAM11FT045.eop-nam11.prod.protection.outlook.com]What does 5.7.23 mean?
RFC 7372 defines X.7.23 as SPF validation failed: the SPF check completed and returned a fail result, and local policy says that is enough to reject. This is a definitive answer, not a timeout. A DNS error during evaluation is reported separately as 5.7.24. The receiver has already decided, so your server will not retry the message and resending without fixing SPF will fail again. It is usually a configuration gap in your DNS, not a sign that someone spoofed you.
SPF authorizes IP addresses to send for the domain in the envelope sender, the MAIL FROM or return-path, not the From header your reader sees. That is why forwarded mail so often fails: the forwarding server's IP is not in your record. The other common trigger is the 10 DNS lookup limit. Every include, a, mx, exists and redirect counts, and a record that grows past 10 returns permerror, which many receivers treat as a fail.
Microsoft 365 is the main source of 5.7.23 in practice, with the text "rejected because of Sender Policy Framework violation". Gmail does not use 5.7.23 for SPF; it reports SPF problems under 5.7.26 and 5.7.27.
Soft or hard bounce?
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| Sender behaviour | Queue and retry with backoff | Stop, suppress the address |
| Reputation risk | Low, unless it repeats for days | High above a 2% bounce rate |
| 5.7.23 | ✓ this code |
Common causes
- The sending IP or service is not listed in the domain's SPF record.
- A new platform such as a CRM, helpdesk or invoicing tool was added without updating SPF.
- The record exceeds 10 DNS lookups and evaluation returns permerror.
- The domain publishes two SPF records, which is invalid.
- The message was forwarded, so the forwarding server's IP was checked instead of yours.
- The record ends in -all and a legitimate sender was never added.
How to fix 5.7.23
- Check the record and its lookup count with the SPF checker.
- List every service that sends as your domain and add each one, using the include the vendor documents.
- If you are near 10 lookups, remove unused includes or consolidate them, and rebuild the record with the SPF generator.
- Publish exactly one SPF TXT record per domain, merging any duplicates.
- Sign all mail with DKIM so it can still pass DMARC after forwarding; verify with the DKIM checker.
- Switch to -all only after DMARC reports confirm every legitimate source passes; the email authentication guide covers the rollout.
5.7.23 questions
What does 550 5.7.23 mean?
It means the receiving server checked SPF for your envelope sender domain, got a fail, and rejected the message. The IP that sent the mail is not authorized by your SPF record. It is common from Microsoft 365 when a sending service was never added to SPF.
Why does SPF fail when my record looks correct?
Check three things. First, the lookup count: more than 10 causes permerror. Second, which domain was checked: SPF uses the return-path, which may belong to your ESP. Third, forwarding, which changes the sending IP. The SPF checker shows lookups and syntax problems.
What is the SPF 10 lookup limit?
SPF evaluation may trigger at most 10 DNS lookups. Each include, a, mx, exists and redirect mechanism counts, including those nested inside vendor includes. Going over returns a permanent error, which many receivers treat as a failure, so keep the record lean.
Should I use -all or ~all?
Use ~all while you are still discovering senders, and move to -all once DMARC reports show every legitimate source passing. In practice DMARC policy decides the outcome at most large providers, so a correct record and a DMARC policy matter more than the qualifier.