TL;DR
The server needed a UTF-8 mailbox string in the reply, but the SMTP client forbids that response form. Enable UTF-8 support or use ASCII addresses on the client side. Permanent failure: fix client capabilities before retrying to restore deliverability.
What this code means
Displaying the mailbox name required an SMTP reply containing a UTF-8 string, yet the client on this session would not accept that reply form; registry pattern X.6.8 appears as code 5.6.8. The enhanced status result for the attempt is permanent under class 5. The status captures a client-server capability mismatch around UTF-8 replies, not evidence that the mailbox itself is invalid. Diagnosis must separate server reply requirements from client restrictions using session logs instead of inferring cause from the numeric code alone.
Technical meaning
X.6.8 covers the case where showing the mailbox name requires a reply containing a UTF-8 string, but the SMTP client does not permit such a reply. Code 5.6.8 applies this detail in class 5.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. The code identifies a conflict between the required reply form and an SMTP client restriction, but it does not by itself prove that the mailbox does not exist or 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 attempt only after a verified change to the client's handling of UTF-8 replies or another correction identified through diagnosis.
Suppression decision
Operational guidance: do not automatically add the address or domain to a suppression list based on 5.6.8 alone. Inspect the complete response, client behavior, event history, and applicable policy, then make the suppression decision in that context.
Common causes
- Showing the mailbox name required a reply with a UTF-8 string that the SMTP client did not permit.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm that the enhanced code is exactly 5.6.8 and that the basic response belongs to the 5xx class.
- Correlate the response with the intended attempt and retain its complete text and available context to confirm that it concerns a mailbox name requiring a UTF-8 string.
- Inspect the SMTP client's configuration, UTF-8 reply handling, and available logs to identify the restriction; before a new attempt, verify a material correction and reassess suppression.
Actions by owner
Sender
- Do not resend the same unchanged message; give the administrator the complete response and attempt context.
Sender administrator
- Determine why the client did not permit the required UTF-8 reply, then correct its configuration or handling if diagnosis confirms that option.
- Verify the correction before a controlled new attempt and reassess suppression instead of treating the mailbox as invalid from this code alone.
Provider
- For the specified attempt, inspect available logs and give the administrator exact, safe context for the UTF-8 reply restriction.
- Correct a confirmed problem in the managed service or identify the required client-side change; do not trigger automatic suppression from this 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 6531 — SMTP Extension for Internationalized Email — SMTP extension for internationalized email addresses and content.
Last verified:
