550 5.7.23 SPF validation failed: which server says it and what to fix
550 5.7.23 means a server found the sending IP is not authorized by the sender domain's SPF record. Find which domain was checked, then fix the record or route.
On this page(9 sections)
Someone pastes "550 5.7.23 The message was rejected because of Sender Policy Framework violation" into a ticket and asks which DNS record to change. The honest first answer is "it depends who said it", because the same code shows up in two different places and the fix differs.
This guide explains what the code states, how to tell which server produced it, and a short order of checks that finds the cause in most cases.
What does 550 5.7.23 mean?
550 5.7.23 is a permanent rejection that says the message failed an SPF (Sender Policy Framework) check. SPF is a DNS record in which a domain lists the servers allowed to send mail for it, defined in RFC 7208. The 550 is the SMTP reply from RFC 5321; 5.7.23 is an enhanced status code of the "security or policy" family (5.7.x, see RFC 3463). Our guide to SMTP enhanced status codes explains how to read the three numbers.
The exact wording of 5.7.23 is not standardized beyond that family. Microsoft documents it for Exchange Online as "The message was rejected because of Sender Policy Framework violation" in its 5.7.23 troubleshooting article, and other mail servers can use the same code for their own SPF rejections. Treat the text after the code as the real clue.
Which server is saying it?
Read the bounce from the bottom up. The "Diagnostic information for administrators" block, or the last Remote-MTA and Diagnostic-Code lines, name the server that refused the message.
| What the bounce shows | Who rejected | Whose SPF is the problem |
|---|---|---|
| Rejection comes from your own Microsoft 365 tenant, with an inner error from an external server | Microsoft 365 reporting a failure on the way out | Your domain's SPF, or how your tenant sends |
| Rejection comes from the recipient's server, naming your sending IP | The recipient's server | The domain in your envelope sender (MAIL FROM) |
| Rejection comes from a relay or gateway you do not control | An intermediate hop | Often a forwarder or filter rewriting the route |
Microsoft's article says its version of the bounce most likely points to an SPF configuration issue in the sender's own Microsoft 365 organization, and that the diagnostic block holds the original error from the external server. So for Exchange Online senders, the clue to follow is the inner error, not the 5.7.23 itself.
Which domain did the check use?
SPF checks the domain in the envelope sender, also called MAIL FROM or Return-Path, not the From address people see. If the two differ, you may fix the wrong record. Our post on From, Reply-To and the envelope sender shows where each lives.
Find it in the delivered or bounced message headers:
Return-Path: <[email protected]>
Received-SPF: fail (example.com: domain of [email protected]
does not designate 203.0.113.25 as permitted sender)
Two values matter: the domain after @ in Return-Path, and the IP the receiver saw. If you send through a provider, the Return-Path domain is often theirs or a subdomain they gave you, and the SPF record to fix is that one. If the header is missing, reading the Received headers gets you the connecting IP.
What are the usual causes, in order of likelihood?
Check these in order. Each one is a quick lookup.
- The sending IP is not in the record. A new tool, a second mail provider, an on-premises server or a marketing platform started sending as your domain without an
include:orip4:entry. - Two SPF records on one domain. A domain must publish exactly one
v=spf1TXT record. Two cause a permanent error that many receivers treat as a failure. See multiple SPF records and permerror. - Too many DNS lookups. SPF allows at most 10 lookup-causing terms (
include,a,mx,redirectand so on) per RFC 7208, section 4.6.4. Past that, evaluation returns a permanent error. See the SPF 10-lookup limit. - A typo or stale record. A missing space, a wrong provider include, or a record edited at the registrar while the live DNS is somewhere else.
- A recent DNS change still cached. Receivers keep the old answer until the TTL expires.
- Forwarding. If the recipient forwards to another mailbox, the forwarder's IP is not in your SPF record, and the next server fails the check. This is a property of how SPF works; see why forwarding to personal inboxes breaks and DMARC, forwarding and ARC.
How do you check the record?
Query the exact domain from the Return-Path, from a machine outside your own network:
dig +short TXT mail.example.com
Confirm three things: there is one string starting v=spf1, it ends in -all or ~all (or ?all), and it includes whatever actually sends. An SPF checker that counts lookups will also catch cause 3. Once you edit the record, wait out the old TTL before retesting.
What does Microsoft 365 add to the checklist?
For tenants sending through Exchange Online, Microsoft's article lists these actions:
- Verify the SPF DNS record for your domain with a public checker.
- Provision all the domains you own, because Microsoft limits the number of messages from unprovisioned domains that a tenant can send.
- Add any on-premises IPs to the SPF record of every domain you send for, including unprovisioned domains you relay through Microsoft 365.
- Check whether the message was flagged as spam and routed through the High Risk Delivery Pool. Per Microsoft, messages in that pool do not pass SPF checks and are not accepted by the destination organization.
The last item surprises people: the SPF record can be perfect and the bounce can still appear, because the message left from a different pool of IPs than the tenant's normal ones. If that is the case, the lever is the outbound spam finding, not DNS.
What if the SPF record is fine?
If every check passes and rejections continue, work through these:
- Different path than you think. A security gateway, CRM or ticketing tool may send as your domain from its own servers. The headers show the real IP.
- Subdomain mismatch. The record exists on
example.combut mail usesmail.example.com, which has none. SPF does not inherit from the parent domain. - Intermittent failure. Failing sometimes and passing other times often means a DNS timeout or a lookup count near the limit.
- A passing result for some receivers only. Different receivers apply different strictness. Keep the evidence (full headers, IP, time) and compare it across a passing and a failing recipient.
Passing SPF is also one half of what DMARC asks for. The other half is DKIM, which survives forwarding where SPF does not, so signing your mail gives you a second route to authenticated.
How does this look in Koltrix?
Koltrix gives each custom domain SPF, DKIM and DMARC records to publish and checks them when you verify the domain, so the record you publish names the servers Koltrix sends from. If you add another service that sends as the same domain, merge its include: into the one existing SPF record instead of creating a second, then re-check the domain. Domain setup is covered in the docs.
Bottom line
- 550 5.7.23 says an SPF check failed; the text and the server that sent it tell you whose record to look at.
- Test the domain in the Return-Path, not the visible From address.
- Look first for a missing sender, then two records, then more than 10 lookups, then cached DNS, then forwarding.
- On Microsoft 365, also check provisioned domains, on-premises IPs and the High Risk Delivery Pool.
- Add DKIM and DMARC so one failed SPF check does not decide delivery.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
