Enhanced Status Code 5.6.0: Malformed Message or Media Error
Enhanced Status Code 5.6.0 means “Malformed Message or Media Error.” The message itself is malformed. Google returns it for mail that is not RFC 5322 compliant, which usually means broken headers or an encoding the receiver cannot process.
554 5.6.0 Mail message is malformed. Please check your message and try again
What does 5.6.0 mean?
Enhanced status code 5.6.0 covers undefined media errors in the registry, meaning something about the message content or its encoding could not be processed. Google uses it more specifically, returning 554 5.6.0 for a message that is malformed and not compliant with RFC 5322.
RFC 5322 governs the structure of an email message: which headers must exist, how they are formatted, and how the body relates to them. Messages generated by hand-written code are the usual offenders. A missing Date header, a From header that is not a valid address, unencoded non-ASCII characters in a header value, a header line that exceeds the length limit without proper folding, or a body separated from the headers by something other than a single blank line all produce a message a strict receiver will refuse.
The reason this is worth taking seriously rather than working around is that malformed messages are strongly associated with spam, because bulk senders using crude tooling produce them constantly. A message that violates RFC 5322 is not merely rejected by strict receivers; it is a reputation signal at receivers that accept it. Generating well-formed mail is cheap and the alternative is expensive.
How 5.6.0 plays out
5.6.0 rejectionWhere 5.6.0 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.6.0 is | ✓ this code |
What each provider means by 5.6.0
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.6.0
- A required header such as Date or From is missing or malformed
- Non-ASCII characters appear in a header without MIME encoding
- A header line exceeds the length limit without correct folding
- The blank line separating headers from body is missing or duplicated
- Duplicate headers appear where only one is permitted, such as two From headers
- The MIME structure is inconsistent, with a declared boundary that does not appear
How to fix 5.6.0
- Generate messages with a maintained MIME library rather than string concatenation
- Ensure Date, From and Message-ID are present and correctly formatted
- MIME encode any non-ASCII header content instead of inserting it raw
- Fold long header lines correctly rather than letting them run past the limit
- Validate a sample of outbound messages against RFC 5322 before sending at volume
- Check that declared MIME boundaries actually appear in the body