TL;DR
The message was rejected after DATA because its UTF-8 header could not be relayed to one or more recipients. Downgrade or re-encode headers, or use a UTF-8-capable path. Permanent: do not retry unchanged; header policy mismatches hurt delivery success rates.
What this code means
After the final DATA dot, relay of a message whose headers use UTF-8 failed for at least one recipient; that is code 5.6.9 under registry detail X.6.9. The leading digit places the outcome in the permanent enhanced status class for this message. The pattern names a header transfer barrier on the delivery path, not by itself an invalid recipient address. It does not identify the affected recipients, the blocking system, or whether header re-encoding or a UTF-8-capable route is the right remedy.
Technical meaning
A message with a UTF-8 header that cannot be transferred to one or more recipients must be rejected under X.6.9. The failure occurs after the final dot of the DATA command, as the standard defines. Code 5.6.9 applies this detail in class 5; the IANA registry associates the pattern with basic status 550.
Delivery status
The leading digit 5 denotes a permanent failure for this message in the current context. The code identifies a problem transferring a message with a UTF-8 header after DATA, but it does not by itself identify the affected recipient or system or explain the exact cause.
- 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 change to the message, configuration, or path removes the diagnosed transfer barrier; reassess suppression before sending.
Suppression decision
Operational guidance: do not automatically add an address or domain to a suppression list based on 5.6.9 alone. Inspect the complete response and per-recipient results because the code concerns transfer of a message with a UTF-8 header and does not by itself prove that an address is invalid.
Common causes
- A message with a UTF-8 header could not be transferred to one or more recipients, so the entire message had to be rejected after DATA completed.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm that the enhanced code is exactly 5.6.9 and that the basic response belongs to the 5xx class.
- Correlate the response with the intended message and attempt; confirm that the failure occurred after the final DATA dot, and identify the recipients covered by the event when the evidence permits.
- Inspect the message headers and available logs from systems on the path to determine the exact barrier to transferring the message with its UTF-8 header; do not assign a specific cause from the code alone.
- Stop unchanged retries; before a controlled new send, verify a material correction and reassess suppression for each recipient.
Actions by owner
Sender
- Do not resend the same unchanged message; give the administrator the complete report and attempt context.
- Prepare a changed message or use a verified alternative sending method only after diagnosis; do not automatically treat the recipient address as invalid.
Sender administrator
- Retain the raw response and available logs, correlate the event with the post-DATA stage, and identify the affected recipients and systems when the diagnostic evidence permits.
- After confirming the cause, correct the message, configuration, or path in managed infrastructure, or coordinate the correction with the provider; verify it before a new send and reassess suppression.
Provider
- For the specified attempt, inspect managed-system logs after DATA completed and determine why the message with its UTF-8 header could not be transferred to the affected recipients.
- Correct a confirmed problem in the managed service, or give the administrator the exact safe diagnostic context; preserve the code and complete response without automatically suppressing the recipients.
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:
