5.6.0

Enhanced Status Code 5.6.0: Malformed Message or Media Error

Permanent failure High severity Content RFC 3463
What it means

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.

At a glance
Code5.6.0
Bounce typeHard (permanent)
SeverityHigh
CategoryContent
What to doSuppress the address; do not retry
StandardRFC 3463
What it looks like in your mail logs
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

Your server attempts delivery
The recipient server returns a permanent 5.6.0 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.6.0 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
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.

Gmail The message is malformed and not RFC 5322 compliant Reference
IANA registry The registry names 5.6.0 other or undefined media error Reference

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

Frequently asked questions

What does 554 5.6.0 mean?
From Google it means the message is malformed and does not comply with RFC 5322, the standard governing email message structure. The registry defines the code more broadly as a media error. In both readings the problem is the message itself rather than the recipient, your authentication, or your reputation.
What makes a message non-compliant with RFC 5322?
Most commonly a missing or malformed required header. A missing Date, a From value that is not a valid address, unencoded non-ASCII characters in a header, header lines too long without folding, duplicate headers where one is permitted, or a missing blank line between headers and body. Hand-built messages hit all of these.
Why does my message look fine in my mail client?
Because clients are forgiving and receiving servers are not. A client will happily render a message with a malformed header that a strict receiver refuses outright. Judge compliance from the raw source, not from how it displays.
Does a malformed message hurt my reputation?
Yes, beyond the immediate rejection. Malformed mail correlates strongly with bulk senders using crude tooling, so receivers that accept the message still weight the defect against you. Fixing message generation improves placement at receivers that never rejected you in the first place.
How do I avoid this?
Use a maintained MIME library rather than assembling messages by string concatenation. Every common language has one, they handle folding, encoding and boundaries correctly, and they eliminate this entire class of failure. Hand-built message construction is the single largest source of 5.6.0.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes