TL;DR
Delivery succeeded after a conversion that lost some data: a success warning, not rejection. Operationally important for content integrity. Do not retry the send. Deliverability stands; reputation is unaffected, but verify whether partial data loss matters to recipients.
What this code means
Successful delivery can still warn about content change: pattern X.6.4 in class 2 signals that the receiving path completed a required conversion but could not keep every original element intact. Treat this as a success-class advisory. The message reached the recipient system, yet parts of the content may no longer match what was sent. The code alone does not name the lost fields or say whether the sender forbade lossy conversion; those answers come from the response text and the sending requirements.
Technical meaning
X.6.4 means conversion with data loss. Under code 2.6.4, class 2 confirms delivery succeeded while warning that the required conversion did not preserve every original data element. The same underlying condition can count as a permanent failure when the sender forbade conversion with loss, but code 2.6.4 itself stays a success status.
Delivery status
Class 2 records a successful result for this event. It is not a rejection and does not, by itself, prove final inbox placement or rule out later events.
- 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
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:
