What this code means
The message was delivered, but delivery required a conversion in which some data was lost. This is a successful-result warning, not a rejection.
Technical meaning
The X.6.4 pattern denotes conversion with data loss. In the concrete code 2.6.4, class 2 confirms successful delivery and warns the sender that not all data was preserved during the required conversion. The same condition can have permanent-failure significance when the sender prohibited conversion with loss, but code 2.6.4 itself remains a success status.
Delivery status
The leading digit 2 denotes success. Code 2.6.4 reports delivery after a conversion that lost data; it does not describe a temporary error, a permanent error, or a rejection of this attempt.
- Class
- Success
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Do not retry automatically based on code 2.6.4 alone because the message was delivered. If the lost data matters, establish the scope of the conversion and only then consider deliberately sending a corrected version in an appropriate format; retrying the same message may produce the same result or create a duplicate.
Suppression decision
Do not add the address or domain to a suppression list based on code 2.6.4 alone. The code does not indicate an invalid or unreachable recipient; make a suppression decision only from other independent events and the full context.
Common causes
- Delivery required the message to be converted, and the conversion could not preserve all of the data.
Diagnostic steps
- Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 2.6.4 and that the event belongs to the success class.
- Correlate the warning with the intended message and recipient, then retain the complete response text to determine whether the report gives additional context about the conversion.
- Compare the sent message with the delivered result, if available, and inspect the sending requirements to determine whether lossy conversion was prohibited or whether a corrected version is needed.
Actions by owner
Sender
- Treat 2.6.4 as successful delivery with a warning, and do not resend the same message solely because the code appeared.
- If preserving all content matters, inspect the result and prepare a corrected version only after determining what was lost during conversion.
Sender administrator
- Classify 2.6.4 as success while retaining the data-loss warning separately; do not route it automatically into rejection handling.
- Retain the raw report and conversion requirements, and if the loss is unacceptable, help select a format or delivery path that does not require the same conversion.
Provider
- Preserve code 2.6.4 and the full warning text in the success event so that conversion information is not lost during normalization.
- Do not present 2.6.4 as a bounce or as a basis for automatic retry or suppression.
Sources and verification
The meaning, success class, and distinction involving a prohibition on conversion were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248 as of July 17, 2026. The retry, suppression, diagnostic, and owner-action guidance is separate operational advice, not a standards claim or a description of provider practice.
- iana-smtp-enhanced-status-codesT0 source
Enumerated Status Codes / X.6.4
- rfc5248T0 source
Section 2.1: registry fields and non-exclusive Associated Basic Status Code
- rfc2034T0 source
Section 4: enhanced status class agrees with SMTP reply class
- rfc3463T0 source
IANA registry reference for X.6.4
Last verified:
