What does 550 5.7.23 SPF validation failed mean?

The receiving server looked up the SPF record for your sending domain and the server that connected was not authorised by it. The recipient address is irrelevant to this rejection. Fix the SPF record and every address in the send starts working again.

What are DKIM, SPF and DMARC, and why are they so important?

SPF lists which servers may send for your domain. DKIM signs each message so the receiver can verify it was not altered and came from your domain. DMARC ties the two to the visible From address and tells receivers what to do when they fail. All three are now required by the major mailbox providers for bulk senders.

What is SMTP authentication and how does it secure your email?

Two different things share the name. SMTP AUTH is a client proving its identity to a submission server before it is allowed to relay. Email authentication — SPF, DKIM and DMARC — lets a receiving server check that a message genuinely came from the domain it claims. A 5.7.23 is the second kind failing, not the first.

SMTP reply code

550 5.7.23 — SPF validation failed

A 550 5.7.23 reply means the receiving server checked SPF for the sending domain and the check did not pass. It is entirely about the sender. The recipient address is not in question, and the fix is a DNS record you control.

The facts

Reference facts for SMTP 550 5.7.23
Field	Value
Reply code	`550`
Enhanced status code	`5.7.23`
Class	5 — permanent failure
Subject	7 — security or policy status
Detail	23 — SPF validation failed
Bounce type	Hard
Should the sender retry?	No
Representative wording	`550 5.7.23 The message was rejected because of Sender Policy Framework violation`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 550 5.7.23
Field	Value
Does a verification probe meet this code?	Rarely. The probe stops before `DATA`, so no message is transmitted and most SPF rejections never arise.
`emailStatus`	`unknown` when a `5xx` reply names a block, a blocklist, an access denial or a poor reputation — the classifier reads the reply text, not just the digits
`reason`	`ip_blocked` in that case
`retryable`	`true` — the mailbox was never tested
Charged	No, when the result is retryable.

What SPF actually checks

SPF, defined in RFC 7208, is a DNS record listing which servers are allowed to send mail on behalf of a domain. The receiving server takes the domain in the envelope sender, looks up its TXT record, and asks whether the IP address that just connected is in the permitted set.

The enhanced code is registered in RFC 7372 — Email Authentication Status Codes, which defines X.7.23 as "SPF validation failed" along with its neighbours: X.7.24 SPF validation error, X.7.25 reverse DNS validation failed, X.7.26 multiple authentication checks failed, and the DKIM codes X.7.20 through X.7.22. If you are building a bounce processor, that RFC is the table you want.

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

Why this is not a list problem

Every address in the send will fail the same way, because the failure has nothing to do with the addresses. A bounce handler that suppresses on 5xx will empty a segment over one misconfigured DNS record, and the damage is permanent while the cause takes ten minutes to fix.

The usual causes are mundane: a new sending platform that was never added to the SPF record; more than ten DNS lookups in the record, which is a hard limit in the specification and causes a permerror; two SPF records published on the same domain, which is invalid; or mail forwarded by an intermediary that SPF cannot survive by design.

What to do

If you sent the message

Nothing is wrong with the recipient. Do not suppress the address.
Check your domain’s SPF record and confirm every service that sends on your behalf is included.
Count the DNS lookups your record causes — more than ten is a specification limit, not a guideline, and it fails the whole record.
Confirm you have exactly one SPF record. Two is invalid and often produces a permerror rather than a merge.

If you own the receiving domain

You are enforcing a policy, which is reasonable. Consider whether a reject at SPF failure is right for forwarded mail, which fails SPF by design.
Make sure the reply text names SPF explicitly — a sender who cannot tell which check failed cannot fix it.

If you are a developer

Route every 5.7.x to a sender-side incident queue, never to address suppression.
Use RFC 7372 as the branch table: the DKIM codes and the SPF codes need different remediation.
Monitor authentication results as a rate rather than per message — a single failure is noise, and a step change is a broken DNS record.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.