TL;DR
Forwarding required a content conversion the path could not perform, so delivery failed permanently. Change message format or routing to match downstream capabilities. Permanent: do not retry unchanged; format mismatches are not list-hygiene issues.
What this code means
A host on the forwarding path needed to convert content for a downstream hop but could not do so practically; code 5.6.3 records that condition under registry pattern X.6.3 within enhanced status class 5. The leading digit marks a permanent outcome in the SMTP enhanced status register; this detail describes a format or transport capability gap, not mailbox existence. The code alone does not identify which hop refused conversion or whether the fix is format change, routing change, or gateway configuration.
Technical meaning
Forwarding that requires a content conversion the path cannot perform, or that is not practical, is the X.6.3 condition the standard describes. Code 5.6.3 applies this detail in class 5; the IANA registry associates the pattern with basic status 554 as well.
Delivery status
The leading digit 5 denotes a permanent failure for this message in the current context. The code identifies a conversion problem in the forwarding path, but it does not by itself identify the specific host or prove that the recipient address is invalid.
- 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 send only after a verified diagnostic change, such as to the message format, transport path, or conversion capability; reassess suppression before sending it.
Suppression decision
Operational guidance: do not add the address or domain to a suppression list based on 5.6.3 alone. Inspect the complete response, forwarding path, results for this recipient, and the applicable policy because the code may describe a conversion problem unrelated to address validity.
Common causes
- A host in the forwarding path must convert the message content for the next hop, but that conversion is impossible or impractical.
- One possible case is an ESMTP gateway that supports 8-bit transport but cannot transform the message into the 7-bit form required by the next hop.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm that the enhanced code is exactly 5.6.3 and that the basic response belongs to the 5xx class.
- Correlate the response with the intended message, attempt time, and forwarding path; retain the complete text and available logs to identify the host that returned the code when the evidence permits.
- Compare the message's format and transport requirements with the capabilities of that host and the next hop. Check whether 8-bit-to-7-bit conversion was required, but do not assume that cause from the code alone.
- Stop unchanged retries; before a controlled new send, verify a material correction and reassess the suppression decision.
Actions by owner
Sender
- Do not resend the same unchanged message; give the administrator the complete report and attempt context.
- Prepare a corrected version only when diagnosis identifies a necessary format or transport change; do not treat this code alone as proof that the address is invalid.
Sender administrator
- Retain the raw response and available logs, reconstruct the forwarding path, and identify the host and conversion requirement when the diagnostic evidence permits.
- After confirming the cause, change the format, route, or conversion capability in managed infrastructure, or coordinate the correction with the provider; verify it before a new attempt and reassess suppression.
Provider
- If a managed host returned the code, inspect its logs, conversion capabilities, and the next hop's requirements for the specified attempt.
- Correct a confirmed conversion or configuration problem, or give the administrator the exact unsupported requirement; preserve the code and complete response without automatically suppressing the recipient.
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 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
Last verified:
