554 5.6.0: The message is malformed

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 554: “Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")” (RFC 5321 §4.2.3).
• Enhanced code 5.6.0: “Other or undefined media error” in the IANA registry (RFC 3463), in the group message content or media status (RFC 3463 §3.7).

The receiving server could not accept your message because of how it is built: broken MIME structure, invalid headers or bad encoding. The recipient is fine; the message itself has to be fixed.

What it means

RFC 3463 §3.7 defines X.6.0 as "other or undefined media error": something about the content made the message undeliverable, and none of the more specific content codes fits. The basic code 554 says the transaction failed (RFC 5321 §4.2.3). Because 5.6.0 is a general code, the text after it matters more than the number.

The format rules are in RFC 5322. Its §3.6 says only two header fields are required in every message: the origination date (Date) and the originator (From). Line endings must be CRLF (RFC 5321 §2.3.8).

Common causes

• A missing or invalid Date or From header.
• MIME boundaries that do not match, or a multipart message that is cut off before its closing boundary.
• Non-ASCII characters in headers without proper encoding.
• Duplicate headers that should appear only once, such as Subject or From.
• A From header with several addresses and no Sender header.
• Bare line feeds instead of CRLF line endings.

How providers use it

• Gmail returns 554 5.6.0 for a malformed message. Its 550 5.7.1 also covers header problems: a missing or invalid From, a missing or invalid Message-ID, duplicate headers, or unencoded Unicode in headers (Google's SMTP error reference).
• Microsoft has specific codes for some of these: 550 5.1.20 for several From addresses without a Sender, 5.7.512 for a missing or invalid From, and 5.6.11 for bare line feeds (Exchange Online NDR reference).
• Yahoo lists oversized headers, bad dates and headers it cannot decode among its 550 policy rejections (Yahoo SMTP error codes).

How to fix it

1. Send the same message to a mailbox you own and open its raw source ("show original" or "view source").
2. Check that Date and exactly one From are present and well formed, and that Message-ID is there.
3. Check the MIME structure: every boundary declared in a Content-Type header should appear in the body, and the last part should end with the closing boundary.
4. Encode non-ASCII text in headers instead of sending raw UTF-8 bytes.
5. If the message is built by your own code, switch to a mail library that produces MIME for you rather than joining strings by hand.
6. If only some messages fail, compare a failing one with one that works; the difference points to the template or attachment at fault.

Related codes

• 5.6.11: Bare line feeds in the message (Microsoft 365)
• 552 5.3.4: The message is too big
• 550 5.7.1: Delivery not authorized: refused for policy reasons

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.