TL;DR
Permanent SPF policy rejection: SPF evaluated to fail against local policy. Fix SPF records or sending infrastructure before retrying. Repeated SPF fail patterns can harm domain reputation and deliverability. Do not retry unchanged.
What this code means
SPF evaluation that finishes with fail contrary to local policy is registry pattern X.7.23, returned as code 5.7.23. RFC 7208 Section 8.4 prescribes this code instead of the broader 5.7.1 for that SPF outcome. Class 5 denotes permanent failure for the current attempt. The status confirms a completed SPF check and a fail result; it does not reveal whether fail stems from record content, an unauthorized sending IP, alignment limits, or policy thresholds. Provider-specific enforcement sits outside what the code alone establishes.
Provider examples
550 5.7.23 The message was rejected because of Sender Policy Framework violationTechnical meaning
A completed SPF check that produced a fail result contrary to local policy requirements is the X.7.23 case. Under Section 8.4 of RFC 7208, operators use this enhanced status code instead of 5.7.1. Code 5.7.23 applies this detail in the permanent-failure class.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. The code confirms the SPF fail result and conflict with local policy, but it does not by itself identify the cause of that result, the layer responsible, or any particular provider's policy.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after a confirmed correction or confirmed change in policy conditions and verification that SPF no longer produces a fail result; check suppression again first.
Suppression decision
Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.23 alone. Inspect the complete response, SPF result, event scope, configuration of the systems involved, and delivery history, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The message's SPF check produced a fail result that was contrary to the receiving system's local policy requirements.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm the exact 5.7.23 code and a basic reply in the 5xx class; retain the complete response text.
- Correlate the response with the intended message, attempt time and stage, evaluated sender identity, and system that returned the code.
- Use available authentication results, logs, and configuration to confirm the SPF fail result and establish its actual cause; do not assign responsibility or provider practice from the code alone.
- Stop unchanged retries. After a confirmed correction or change in conditions, verify that SPF no longer produces a fail result, check suppression again, and make one controlled attempt.
Actions by owner
Sender
- Confirm that the message and sender identity used are intended, then give the sender administrator the complete response and attempt time without repeatedly retrying it manually.
Sender administrator
- Retain the complete response, correlate it with the message, sender identity, and sending system, and inspect available SPF results, logs, and configuration to establish the confirmed cause of the fail result.
- After correction, confirm that SPF no longer produces a fail result, check suppression again, and make one controlled attempt instead of retrying the unchanged message.
Recipient administrator
- If you manage the system that returned the code, inspect its SPF-evaluation logs and local policy for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the result needed for remediation.
Provider
- If you operate a managed sending, SPF-configuration, or SPF-evaluation layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 7372 — Email Authentication Status Codes — Status codes for SPF, DKIM, DMARC and related authentication results.
- RFC 7208 — Sender Policy Framework (SPF) — SPF standard for authorizing domains that send mail.
- Common email bounce messages — Rackspace documentation of common SMTP bounce messages.
Last verified:
