# 5.6.11 Bounce: Bare Line Feeds Are Illegal (Exchange)

URL: https://email-validation.org/bounce-codes/5-6-11/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**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](https://www.rfc-editor.org/rfc/rfc5321) 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)). 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](https://email-validation.org/bounce-codes/554-5-6-0/). Devices that relay through Microsoft 365 can also hit [5.7.57](https://email-validation.org/bounce-codes/5-7-57/) when they do not sign in.

## Related codes

- [554 5.6.0](https://email-validation.org/bounce-codes/554-5-6-0/): The message is malformed
- [5.7.57](https://email-validation.org/bounce-codes/5-7-57/): Client not authenticated to send anonymous mail (Microsoft 365)
- [503 5.5.1](https://email-validation.org/bounce-codes/503-5-5-1/): Commands sent in the wrong order

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.