5.7.23

Enhanced Status Code 5.7.23: SPF Validation Failed

Permanent failure Critical severity Authentication RFC 7372
What it means

Enhanced Status Code 5.7.23 means “SPF Validation Failed.” Your message completed an SPF check that returned a fail, and the receiving server rejects on that result. The sending IP address is not authorised to send for the domain in the envelope sender.

At a glance
Code5.7.23
Bounce typeHard (permanent)
SeverityCritical
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7372
What it looks like in your mail logs 
550 5.7.23 The message was rejected because of Sender Policy Framework violation

What does 5.7.23 mean?

Enhanced status code 5.7.23 means SPF validation failed. RFC 7372 defines it as a message that completed an SPF check producing a fail result, contrary to the receiver's local policy. Note the word completed: this is a definitive fail, not an error or a timeout, which has its own code in 5.7.24.

SPF authorises IP addresses to send for the domain in the envelope sender, which is the MAIL FROM address rather than the From header your recipient sees. That distinction causes most of the confusion around this code. A message can pass SPF while the visible From header belongs to an entirely different domain, and it can fail SPF while the visible From header is perfectly legitimate, which is what happens whenever a message is forwarded. Forwarding breaks SPF by design: the forwarding server becomes the sending IP and it is not in your record.

The other frequent cause is structural rather than accidental. SPF permits a maximum of ten DNS lookups during evaluation, and every include, a, mx, ptr, exists and redirect term counts toward it. Records that accumulate one include per vendor drift past that limit and start returning permerror, which many receivers treat as a fail. A record that worked last year can begin failing with no change on your side, because a vendor expanded their own record inside your include.

How 5.7.23 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.23 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.23 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.23 is✓ this code

What each provider means by 5.7.23

A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.

IANA registry SPF validation failed: the check completed and produced a fail result Reference
Exchange Online The message was rejected because of a Sender Policy Framework violation Reference
Gmail Gmail uses the temporary 4.7.23 for a missing PTR record rather than for SPF Reference

Common causes of 5.7.23

  • The sending IP address is genuinely not listed in the domain SPF record
  • A new sending platform was added without updating the record
  • The record exceeds the ten DNS lookup limit and evaluation returns permerror
  • The message was forwarded, so the forwarding server IP replaces yours
  • The domain publishes more than one SPF record, which is invalid and fails outright
  • The record ends in -all and a legitimate sender was never added to it

How to fix 5.7.23

  • Check the record and its lookup count with SPF Record Checker before changing anything
  • Add every platform that sends as your domain, including invoicing, ticketing and CRM tools
  • Flatten or consolidate includes if you are near the ten lookup limit
  • Publish exactly one SPF record for the domain, merging any duplicates into it
  • Sign with DKIM as well, because DKIM survives forwarding where SPF cannot
  • Move to -all only once you have confirmed every legitimate sender is covered

Frequently asked questions

What does SMTP error 5.7.23 mean?
It means an SPF check ran to completion and returned a fail, and the receiving server rejects messages on that result. The IP address that connected is not authorised in the SPF record of the domain used in the envelope sender. This is the registered code for an SPF failure; 5.7.20 is the DKIM equivalent and 5.7.24 is an SPF evaluation error rather than a fail.
Why does SPF fail when my record looks correct?
Three causes account for most of these. The message was forwarded, so the sending IP is the forwarder rather than you and SPF cannot pass. The record exceeds the ten DNS lookup limit and returns permerror, which many receivers treat as a fail. Or the domain publishes two SPF records, which is invalid and fails regardless of what either one says. Check the lookup count first, since it changes without you touching anything when a vendor expands their own include.
What is the SPF ten lookup limit?
SPF evaluation is capped at ten DNS lookups, and every include, a, mx, ptr, exists and redirect term counts, including lookups triggered inside another provider include. Exceeding it produces permerror. This is the most common way a working record silently breaks: you add nothing, but a vendor expands the record inside your include and pushes you over. Audit the count whenever you add a sender and after any vendor migration.
Does SPF failing mean my email is spoofed?
Not necessarily, and treating it that way causes real mail to be discarded. Forwarded mail fails SPF as a matter of course because the forwarding server is not in your record, which is precisely why DMARC accepts a DKIM pass as an alternative. Look at whether DKIM also failed before concluding anything about spoofing.
Should I use -all or ~all?
Use -all once, and only once, you have confirmed every legitimate sender is in the record. -all tells receivers to reject anything not listed, which is the point of publishing SPF, but it is unforgiving of the invoicing tool nobody remembered. Start at ~all, read your DMARC aggregate reports until no legitimate source is failing, then move to -all.

Related bounce codes

5.7.24 SPF Validation Error 5.7.20 No Passing DKIM Signature Found 5.7.26 DMARC Authentication Failed 5.7.1 Delivery Not Authorized - Message Refused 5.7.25 Reverse DNS Validation Failed

Sources & further reading

RFC 7372 · The standard that defines this reply code RFC 7372 · Email authentication status codes, which define the DKIM and SPF codes Exchange Online NDR reference · Microsoft list of SMTP errors returned by Exchange Online
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes