Blazalek.com

5.6.9Message with a UTF-8 header cannot be transferred

The message was permanently rejected after its data had been transmitted because it could not be transferred with its UTF-8 header to one or more recipients. Do not retry the same unchanged attempt.

Category
Message content and format
Class
Permanent failure
Retry
Do not retry unchanged
Suppression
Check the full context

What this code means

The message was permanently rejected after its data had been transmitted because it could not be transferred with its UTF-8 header to one or more recipients. Do not retry the same unchanged attempt.

Technical meaning

The standard X.6.9 pattern means that a message with a UTF-8 header cannot be transferred to one or more recipients, so the message must be rejected. The failure occurs after the final dot of the DATA command. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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 and verification

The standard X.6.9 meaning, the failure after the final DATA dot, its class-5 use, and its association with basic status 550 were verified against the IANA registry and RFC 2034, RFC 5248, and RFC 6531 as of July 17, 2026. The diagnostic, remediation, retry, and suppression recommendations are operational guidance, not a description of any provider's practice.

  • Enumerated Status Codes / X.6.9

  • 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

  • rfc6531T0 source

    IANA registry reference for X.6.9

Last verified:

Wojtek Blazalek

Email deliverability expert

Stuck on this error code? I help teams clear the root cause of rejections and fix authentication and reputation — so email lands in the inbox.

Hands-on deliverability work for teams that send at scale.