550 5.7.23: SPF validation failed

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.23: “SPF validation failed” in the IANA registry (RFC 7372), in the group security or policy status (RFC 3463 §3.8).

A 5.7.23 bounce means the receiving server checked SPF for your domain and the server that sent the message is not on the list. The message was refused as possibly forged.

What it means

SPF lets a domain publish, in DNS, which servers may send mail for it. RFC 7372 §3.2 defines two enhanced codes for SPF:

• X.7.23, SPF validation failed: the check ran and the sending IP is not allowed by the record.
• X.7.24, SPF validation error: the check could not finish, for example because of a DNS problem or a broken record.

Both appear in the IANA registry. A 550 in front makes the failure permanent: the receiver will not accept this message from this server.

Common causes

• You started sending through a new service (a newsletter tool, a CRM, a help desk) and did not add it to your SPF record.
• Someone edited the SPF record and removed a sender that is still in use.
• Your mail server moved to a new IP address.
• The message was forwarded, so it now reaches the receiver from the forwarder's IP, which your record does not list. Microsoft reports this case as 5.7.367.
• A spoofer is sending as your domain. Then the bounce is correct, and you only see it because it came back to you.

How providers use it

Microsoft's Exchange Online NDR reference lists 5.7.23 as an SPF violation. Google's reference lists SPF problems under other codes: 5.7.26 (SPF hard fail or no SPF or DKIM pass), 5.7.27 for bulk senders, and 451 4.7.24 for suspicious SPF entries (Google's SMTP error reference).

How to fix it

1. Find the sending IP in the bounce or in the original message headers, and work out which service owns it.
2. Make a list of every system that sends mail with your domain: your mailbox provider, marketing tools, billing, support, servers.
3. Run your domain through the SPF checker to see the current record and any errors.
4. Add the missing service, using the include or IP the service documents. The SPF generator builds a valid record.
5. Also sign with DKIM (DKIM checker). Google's sender guidelines need SPF or DKIM from every sender, and both from bulk senders.
6. Resend once the record has been updated in DNS.

What to do with the address

Keep it. The recipient's mailbox is fine; the problem is your domain's DNS.

Related codes

• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it
• 550 5.7.27: SPF failed for a bulk sender (Gmail), or the sender has a null MX
• 5.7.367: Remote server says not permitted to relay (Microsoft 365)
• 5.7.509: DMARC failed and the domain’s policy is reject (Microsoft 365)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.