Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 554 5.6.0

554 5.6.0 invalid content: malformed messages Exchange refuses to accept

11 min read Updated October 4, 2026 Exchange Server

Fix it now

The receiving system refused the message because of what was in it rather than who sent it or where it was going. Almost always the sender is an application writing SMTP by hand, so the repair belongs in the generating code, not in your connectors.

Run these in the Exchange Management Shell on the receiving server

Get-MessageTrackingLog -Start (Get-Date).AddHours(-2) -EventId FAIL | Format-Table Timestamp,Source,SourceContext,Recipients,MessageSubject
Get-ReceiveConnector | Format-List Name,BareLinefeedRejectionEnabled
  1. Identify what generated the message. A mail client almost never produces these; a line-of-business application, a scanner, a monitoring tool or a script usually does.
  2. Get the message as the application produced it. Have it write a copy to a file, or capture it at a local relay, before anything else has touched it.
  3. Check line endings first. SMTP requires carriage return and line feed together; code that writes only a line feed produces bare line feeds, which is the single most common cause here.
  4. Check the envelope addresses next. A malformed or missing sender address is refused before the body is even considered.
  5. Correct the generating application, send one test message, and confirm it appears in the tracking log without a FAIL event.

BareLinefeedRejectionEnabled is $false by default on an Exchange receive connector, so an on-premises server usually is not the thing rejecting bare line feeds. Setting it to $true is a way to start refusing them, not a way to stop.

If a corrected test message is accepted you are done. If not, the next section covers what each code in this family is actually telling you.

Why it happens

An SMTP message has a defined shape. Header lines follow a fixed form, exactly one empty line separates the header block from the body, every line ends with a carriage return followed by a line feed, and the addresses in the envelope commands have to be syntactically valid. A receiving system is entitled to refuse anything that does not comply, and hosted services generally do so without negotiation, because accepting malformed mail is how parsing defects get exercised.

The 5.6.x family is the content class. RFC 3463 defines the subject digit 6 as message content or media status, and X.6.0 as a content problem that no more specific detail code describes. That is all 554 5.6.0 and 550 5.6.0 tell you on their own: something about the bytes was unacceptable. Neither Microsoft NDR reference publishes an Exchange-specific meaning for them, so the diagnosis has to come from the message itself.

The codes either side of it are more precise, and they are the ones worth reading carefully, because two of them point at the sender’s address and one of them points at the recipient’s.

The application writes bare line feeds

You have this one if Mail from one application is refused by hosted recipients while identical-looking mail from Outlook is accepted, and the bounce carries 5.6.11.

  1. Fix the line endings in the generating code so every line ends with a carriage return and a line feed.
  2. Where you cannot change the code, replace hand-written SMTP with a mail library. Every mature library gets this right.
  3. As a stopgap only, route the application through a local relay that accepts the message and re-emits it correctly formatted.
  4. If you control the receiving Exchange server and it is the thing refusing them, check Get-ReceiveConnector | Format-List Name,BareLinefeedRejectionEnabled and set the value to $false on the connector concerned.

Microsoft’s documented cause for 5.6.11 has two halves: the message contains bare line feeds and the destination server cannot accept them, because carrying them needs the SMTP BDAT chunking command. Microsoft 365 used to strip bare line feeds on the way through and stopped doing so to avoid breaking DKIM signatures, which is why long-working applications started failing without changing.

An address in the envelope is invalid

You have this one if The rejection arrives during the SMTP conversation, before the body is transmitted, and carries 5.1.3 or 5.1.7.

  1. Print the exact strings the application puts into the MAIL FROM and RCPT TO commands, including any display name wrapped around the address.
  2. Remove spaces, stray angle brackets, trailing commas and semicolons. A display name containing a comma must be quoted or the address parses as two.
  3. Confirm a sender address is present at all. Some applications omit it and rely on the server to fill one in.
  4. Retest with a plain address and no display name, then add the display name back.

The two codes point at opposite ends. Microsoft publishes 5.1.3 as an invalid recipient address and 5.1.7 as a problem with the sender’s address, so the code tells you which half of the envelope to print.

Raw non-ASCII characters appear in headers or addresses

You have this one if Messages fail only when a name, subject or address contains an accented or non-Latin character.

  1. Encode header values properly rather than inserting the characters directly. Mail libraries do this for you.
  2. Keep the addresses themselves to plain ASCII unless every system in the path is known to support internationalised addresses. The registry reserves X.6.7 for exactly that refusal.
  3. Check the database or form the value comes from. This is more often bad data than bad code.
  4. Retest with the value that previously failed.

The MIME structure is broken

You have this one if Messages with attachments fail while plain text messages from the same application succeed.

  1. Confirm the boundary markers are unique, declared correctly in the content type header, and terminated at the end of the message.
  2. Confirm each part declares its own content type and transfer encoding, and that binary content is encoded rather than sent raw.
  3. Replace hand-built MIME with a library. Hand-built multipart messages are a reliable source of this failure.
  4. Test with one small attachment before testing the real workload.

Full reference

Where each code in this family comes from

Only three of the six are published with an Exchange meaning. Knowing which is which stops you reading significance into a number that carries none.

Code Published by What that source says
5.6.11 Microsoft Invalid characters: the message contains bare line feeds and the destination server does not support them
5.1.3 Microsoft STOREDRV.Submit; invalid recipient address
5.1.7 Microsoft Invalid address, or unknown sender address
5.6.0 RFC 3463 and the IANA registry A content problem that no more specific detail code describes
5.6.12 Nobody Absent from both Microsoft NDR references and from the IANA registry, which stops at X.6.10

Because 5.6.0 and 5.6.12 carry no published detail, the reply text that accompanies them is the only diagnostic information you are given. Capture the whole SMTP response, not the number.

Getting the message as the application wrote it

  1. Have the application write the outbound message to a file at the same time it sends it, or point it at a local relay you control and capture it there.
  2. Open the file in an editor that shows line endings rather than hiding them, and confirm each line ends CR LF.
  3. Read the header block. It ends at the first completely empty line; anything after that is body, whatever the application intended.
  4. Read the MAIL FROM and RCPT TO strings from a protocol log rather than from the message, because that is where 5.1.3 and 5.1.7 are decided.

What loosening the server does and does not buy you

On an Exchange receive connector, BareLinefeedRejectionEnabled controls whether messages containing bare line feeds are refused in the DATA stream. Microsoft documents $false as the default, and notes that although such messages might be delivered successfully, they do not follow SMTP protocol standards and might cause problems on messaging servers. So the setting is a way of tightening a server, not a repair for a sender.

That matters because the setting has no reach beyond your own server. Once the message leaves for a hosted recipient, that recipient’s rules apply, and a message with bare line feeds will be refused there whatever your connector allows. Every server-side accommodation for a malformed sender is borrowed time with an expiry date you do not control.

Why this appears during a migration

The application did not change; the tolerance of the thing receiving its mail did. Older on-premises servers repaired some defects silently on the way through. Hosted services do not, and Microsoft 365 specifically stopped removing bare line feeds so that DKIM signatures stay valid. An application that has produced invalid mail for years starts producing visible bounces the week its mail begins going through a service instead of a local hub.

When the message looks clean and still fails

  • Check the tracking log on the sending side for a FAIL event and read its SourceContext. That tells you whether the message was refused by your own transport or by the next hop.
  • Turn on verbose protocol logging on the connector handling the session, reproduce the failure, and read the conversation. The full reply text is worth more than the code.
  • Confirm the failure is content and not size. A message larger than the recipient’s limit is a different code and a different article.
  • Send the same content from a mail client to the same recipient. If the client’s version arrives, the difference between the two files is your defect.

Every code this article covers

Code What it points at Source
554 5.6.0 A content-class refusal. RFC 3463 defines X.6.0 as a content problem that no more specific detail code describes; no Microsoft NDR reference publishes an Exchange-specific meaning RFC 3463
550 5.6.11 Invalid characters: the message contains bare line feeds and the destination server cannot accept them, because carrying them requires the SMTP BDAT chunking command Microsoft Learn
550 5.6.0 The same content-class detail code returned with a 550 reply; again only the RFC class meaning is published RFC 3463
550 5.6.12 No meaning is published by Microsoft or registered with IANA, whose X.6.x range ends at X.6.10. Treat it as an unelaborated content refusal and read the accompanying reply text not published by the vendor
501 5.1.3 STOREDRV.Submit; invalid recipient address. RFC 3463 puts X.1.3 on the destination address being syntactically invalid Microsoft Learn
550 5.1.7 Invalid address, or unknown sender address: there is a problem with the sender’s address Microsoft Learn

Confirm the fix worked

  1. A test message from the application is accepted and appears in the tracking log with no FAIL event.
  2. The raw file the application produced shows CR LF line endings, a properly separated header block and encoded header values.
  3. Messages with an attachment and messages containing a non-ASCII character both succeed, since these fail independently.
  4. Delivery works to a hosted recipient outside your organisation, not only to an internal one.

Questions people ask about this

Does anything here need to be bought?

No. This is a formatting defect in whatever generates the message, and the fix is a code or configuration change at the sender. No licence, gateway or add-on makes a malformed message valid.

Can I configure Exchange to accept these messages?

On premises you can control one specific check: BareLinefeedRejectionEnabled on a receive connector, which Microsoft documents as $false by default. It has no effect once the mail leaves for a recipient that enforces the rule, so it buys time rather than solving anything.

Why did this start after we moved to a hosted service?

Tolerance differs. Microsoft 365 used to strip bare line feeds and stopped, to avoid invalidating DKIM signatures. The application has been producing non-compliant mail all along; only now is something saying so.

The bounce says 5.6.12 and I cannot find it documented anywhere. Is that normal?

Yes. It is not in either of Microsoft’s NDR references and it is not in the IANA registry of enhanced status codes, which stops at X.6.10. Work from the reply text that came with it and from the raw message, not from the number.

How do I see the raw message to inspect it?

Have the application write the message to a file as well as sending it, or capture it at a local relay. Reading it as the application produced it, before anything else touches it, is the only reliable way to see the defect.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Error 1638: another Exchange version blocks this cumulative update install License Error 550 5.7.708: Microsoft 365 will not accept traffic from your sending IP License Error 550 5.2.1: the mailbox is disabled, blocked or has lost its licence Free Fix HTTP 404.0 on Autodiscover: Outlook cannot retrieve its own configuration
← Back to Knowledge Base