5.6.11: Bare line feeds in the message (Microsoft 365)

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: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.6.11: not in the IANA registry; the group is message content or media status (RFC 3463 §3.7).
• Who uses it: Microsoft (Exchange Online): invalid characters (bare line feeds) in the message.

Exchange Online refused to pass on your message because it contains bare line feeds: line breaks written as LF alone instead of CR followed by LF. The program that created the message has to be fixed.

What it means

In SMTP, every line ends with two characters: carriage return (CR) and line feed (LF), written CRLF. RFC 5321 §2.3.8 says implementations must not recognize or produce any other line ending, and that a client must not send a bare CR or bare LF except as part of CRLF. The RFC notes that bare line endings have a long history of causing problems in mail systems.

Microsoft uses 5.6.11 for this case, with text such as 5.6.11 SMTPSEND.BareLinefeedsAreIllegal. Its NDR reference describes the cause as invalid characters: the email program added bare line feeds to the message (Exchange Online NDR reference). The code is Microsoft's; the basic code that comes with it can vary.

Common causes

• A script that builds the message with \n line breaks, which is the default on Linux and macOS.
• Templates or text files saved with Unix line endings and pasted into the body or headers.
• An application that writes its own SMTP instead of using a mail library.
• A device, such as a scanner or printer, or an older app that relays mail through Microsoft 365.
• Code that converts line endings in one part of the message, such as the body, but not in headers or attachments.

How to fix it

1. Find which application sent the message. The NDR and the message headers show the sending system.
2. Make it produce CRLF line endings everywhere: headers, body and MIME boundaries. In code, normalize every line break to \r\n before sending.
3. Prefer a maintained mail library over hand-built messages; libraries handle line endings and encoding for you.
4. For attachments, use base64 or quoted-printable encoding rather than inserting raw text or binary data.
5. For devices and older apps you cannot change, check whether a firmware or software update fixes the line endings, or send through a relay that corrects them.
6. Send a test to a mailbox you own and inspect the raw source to confirm the line endings are now CRLF.

If the message also fails at other providers with a general content error, see 554 5.6.0. Devices that relay through Microsoft 365 can also hit 5.7.57 when they do not sign in.

Related codes

• 554 5.6.0: The message is malformed
• 5.7.57: Client not authenticated to send anonymous mail (Microsoft 365)
• 503 5.5.1: Commands sent in the wrong order

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.