550 5.7.23: SPF validation failed
550 5.7.23 means the receiver checked your domain's SPF record and your sending server did not pass. The mail was rejected because of it. Fix the SPF record so it lists every service that sends for your domain.
- Bounce type
- Hard bounce (permanent)
- Usually caused on
- Your sending side
- Terlido report label
- Blocked by the provider
What the standard says
RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. RFC 7372 defines X.7.23 as "SPF validation failed": the SPF check ended in a result that the receiver treats as a failure. Class 5 means the refusal is permanent for this attempt.
What the mailbox providers say
- Microsoft 365 / Outlook (5.7.23): “The message was rejected because of Sender Policy Framework violation” Source
Common causes
- The service that sends your mail is not listed in the SPF record.
- The SPF record has too many DNS lookups. The limit is ten, and above it the check fails.
- A strict policy ending in -all, combined with a sender that is missing from the record.
- More than one SPF record on the same domain, which is invalid.
- A typo in the record or an include that no longer exists.
- A marketing or support platform that sends as your domain but was never added to SPF.
How to fix it
- Read your current SPF record and add every service that sends mail for the domain.
- Count the lookups and remove includes you do not use, to stay inside the limit of ten.
- Keep one SPF record per domain and merge duplicates into a single line.
- Test the record again after the change and send a test message to confirm the pass.
- Use a record generator to build one correct SPF line from the full list of senders, then replace the old lines with it.
- Prefer a softer ending such as ~all while you are still finding all senders, and tighten it later.
Is it a deliverability problem?
Yes. An SPF failure is a direct sender-side problem and it hurts more than one receiver. Gmail and others use SPF in their own decisions too, so the fix improves delivery everywhere, not only at Microsoft. SPF problems are usually silent until a strict receiver rejects the mail. If Microsoft rejects you with this code, assume other receivers see the same failure but accept the mail anyway for now, which makes it a good time to repair the record.
How Terlido handles it
When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".
On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.
Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.
Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.
Check the domain behind the bounce
The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.
Free tools that help
- SPF checkerInspect a published SPF record and its recursive DNS lookup budget.
- SPF lookup limit checkerTrace SPF DNS lookups against the 10-lookup limit.
- SPF record generatorCreate a proposed SPF TXT record from explicit sender inputs.
Related error codes
- 550 5.7.26: Blocked because the sender is unauthenticated
- 550 5.7.27: Blocked because SPF did not pass
- 550 5.7.509: Sending domain fails DMARC with a reject policy
- 421 4.7.26: Rate limited because mail is unauthenticated