A 550 5.7.23 bounce means the receiving server rejected your message because SPF validation failed and a policy told it to reject rather than deliver. Microsoft 365 is the most common source of this exact code, and it almost always maps to one of three distinct problems that people wrongly treat as the same thing. Either the sending IP is genuinely not authorized by your SPF record and you use a hard fail (-all), or your SPF record itself is broken and returns a PermError, or the mail was forwarded and the forwarding server broke the SPF path.
The fastest way to know which one you are dealing with is to check whether your record even parses and how many DNS lookups it costs, because a record that exceeds the limit fails for every recipient regardless of the sending IP.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
What 550 5.7.23 actually says
The enhanced status code 5.7.23 is defined in the mail delivery status registry as "the message was not accepted because the SPF check failed." The leading 550 is a permanent rejection, so the sending server will not retry. The message bounces back to the envelope sender.
A typical Microsoft 365 rejection looks like this:
550 5.7.23 The message was rejected because SPF was configured incorrectly, or because SPF validation failed. Please contact the administrator of the domain.
That wording is deliberately broad because Microsoft is combining two different outcomes under one code. "SPF was configured incorrectly" is a PermError. "SPF validation failed" is a hard fail. They are not the same problem and they do not have the same fix. This is why so many people chase the wrong solution: they see the code, assume their record is broken, rewrite it, and the bounces continue because the real cause was an unlisted sending IP.
Cause 1: a hard fail from -all
SPF publishes the servers allowed to send for your domain in a single TXT record. The mechanism at the end tells receivers what to do when a sending IP is not in that list.
v=spf1 include:_spf.google.com -all
The -all is a hard fail. It means "if the connecting IP is not authorized by anything to the left, treat this as a definite failure." When a receiver evaluates a hard fail and its local policy is set to reject on SPF failure, you get 550 5.7.23.
This is the correct, healthy behavior when the sender is actually forged. The problem is when the sender is legitimate but you forgot to authorize it. Common triggers:
- You added a new mailing platform (a CRM, a helpdesk, an invoicing tool) that sends from its own servers and never added its
includeto your record. - You moved mailboxes to a new provider but the SPF record still lists only the old one.
- An application server or copier sends directly to a recipient without relaying through an authorized host.
The fix is to add the missing source. If a marketing tool sends on your behalf, add its include exactly as the provider documents it, then re-test. Our provider guides such as the SendGrid domain authentication setup and Amazon SES SPF, DKIM and DMARC setup show the specific includes each platform needs. If you are unsure whether a soft fail would be safer while you audit senders, understand that ~all (soft fail) rarely produces a 550 on its own, but it also gives spoofers more room, so it is a temporary measure, not a destination.
Confirm the sending IP first
Before you touch the record, read the bounce and any Authentication-Results header you can get from a test message. If SPF says fail and names an IP that belongs to a service you recognize, this is cause 1 and the fix is authorization. If SPF says permerror, skip ahead, because no amount of authorizing IPs will help.
Cause 2: an SPF PermError from too many lookups or broken syntax
RFC 7208 caps the number of DNS-querying mechanisms in a single SPF evaluation at 10. Every include, a, mx, ptr, exists and redirect counts, and includes are recursive, so one vendor include can pull in several more lookups behind the scenes. When the total exceeds 10, the evaluation returns PermError, not fail.
Here is the trap: many receivers, including Microsoft 365, treat PermError the same as fail and reject with 550 5.7.23. So a record that passes every legitimate sender still bounces mail, because the record never finishes evaluating. Adding another include to "fix" delivery makes it strictly worse.
A record that looks harmless can blow the budget:
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.protection.outlook.com include:_spf.salesforce.com include:mail.zendesk.com -all
Each of those includes resolves to several lookups internally. Six includes can easily cost 12 or more. Our checker counts the exact number for you and shows which include is expensive, so you are not guessing. If you are over the limit, the fix for SPF too many DNS lookups walks through flattening, removing dead senders, and consolidating.
PermError also fires for plain syntax mistakes:
- Two SPF records on the same domain. You are allowed exactly one TXT record starting with
v=spf1. A second one is a PermError. - A macro or mechanism typo, a missing space, or a stray character.
- An
includethat points to a hostname with no SPF record of its own.
The difference between a PermError and a temporary TempError matters for how you respond, and we cover it in SPF PermError vs TempError. A TempError is a transient DNS failure and usually retries clean. A PermError is a defect in the record that will keep bouncing until you fix it.
Cause 3: forwarding that fakes a failure
SPF authenticates the envelope sender against the connecting IP. When a message is forwarded, for example from an old address that auto-forwards to a new inbox, the forwarding server connects using its own IP but keeps your domain in the envelope. Your SPF record does not list the forwarder, so SPF fails at the final destination even though nothing is wrong with your setup or the original send.
This is not something you can fix by editing your SPF record, because you cannot list every random server that might forward your mail. It is exactly the case that DMARC alignment via DKIM is designed to survive, since a valid DKIM signature travels with the message and passes even when SPF breaks in transit. We explain the mechanism in why email forwarding breaks SPF and when DKIM passes while SPF fails. If your bounces only happen for forwarded mail, the durable answer is making sure DKIM is signing and aligned, not chasing SPF.
How to diagnose your exact case in two minutes
Run your domain through the checker above and read three things in order. First, does the record parse at all, or does it report a syntax error or a duplicate record. Second, how many of the 10 lookups does it consume, because anything at or above the limit is a PermError waiting to happen. Third, which sending sources are actually authorized, so you can see whether the IP in your bounce is on the list.
- Parse error or duplicate record: this is cause 2, fix the syntax.
- Lookup count of 10 or more: this is cause 2, reduce the count.
- Record is clean and under the limit, but a known sender is missing: this is cause 1, add the include.
- Record is clean and the sender is authorized, but only forwarded mail bounces: this is cause 3, rely on DKIM and DMARC alignment.
Once SPF is healthy, tighten the policy layer above it so receivers know what to do with mail that fails. Both how to set up SPF and how to set up DMARC close the loop, and DMARC is what turns a raw SPF result into a policy decision you control.
Frequently asked questions
Is 550 5.7.23 always my fault?
No. If the message was forwarded, the failure happens at a server you do not control and your own setup can be perfectly correct. In that case the fix is confirming DKIM signs and aligns, because DKIM survives forwarding while SPF does not. If the bounce is for direct mail from a sender you own, then it is your record or your authorization list.
Will changing -all to ~all stop the bounce?
Sometimes, but it treats the symptom, not the cause. A soft fail (~all) usually will not trigger a 550 on its own, so mail may start delivering. But if the real problem is a PermError from too many lookups, softening the qualifier does nothing, because PermError ignores the qualifier entirely. Fix the record first, then decide on the qualifier.
How do I know if it is a PermError versus a hard fail?
Read the Authentication-Results header of a test message or use the checker above. A hard fail names a specific unauthorized IP and reports spf=fail. A PermError reports spf=permerror and means the record could not be evaluated, usually from exceeding 10 lookups or a syntax defect. The two have completely different fixes.
Does Microsoft 365 reject on PermError by default?
Microsoft 365 commonly rejects with 550 5.7.23 on both hard fail and PermError, which is why the code is so often misdiagnosed. That is exactly why you should confirm whether your record parses and how many lookups it costs before assuming an unauthorized sender is the problem.