550 5.6.11 bare line feeds: why mail bounces and how to fix it

How can you check a saved message for bare line feeds?#

Save the failing message as a raw .eml file or capture the exact bytes you handed to your SMTP library, then count lines that do not end in CR. On Linux or macOS with GNU grep:

# lines that do NOT end with CR (each one is a bare LF)
grep -cvP '\r$' message.eml

# show the first few offending line numbers
grep -nvP '\r$' message.eml | head

A result of 0 means every line ends in CR LF. A larger number means you have bare line feeds. Be careful that your tool did not already normalize the file: some editors and download paths convert endings silently, so test the bytes your code actually sent, not a copy that has been through a text editor.

If you can reproduce the send, swaks lets you replay a raw message against the destination and see the exact SMTP reply, which is faster than waiting for a customer to resend.

How do you fix it in code?#

Normalize every line ending to CR LF at the last moment before the message is serialized, and do it for each text part, not just the main body. A minimal version in Python:

import re

def to_crlf(text: str) -> str:
    # turn any CRLF, bare CR or bare LF into a single CRLF
    return re.sub(r"\r\n|\r|\n", "\r\n", text)

body = to_crlf(body)

The regular expression matches a CR LF pair first, so existing pairs are not doubled. The same idea works in any language: replace CR LF, CR and LF with CR LF in one pass.

Where you can, do not assemble raw messages by hand. Mail libraries built for sending, such as Python's email package with its SMTP policy, are designed to produce CR LF when they serialize a message. If you are on a hand-built path, see MIME structure for developers for what a well-formed message looks like.

Two cautions. Never rewrite line endings inside raw binary data; encode attachments as base64 and normalize the encoded text instead. And normalize before you sign: if you add a DKIM signature, compute it over the final CR LF form.

What about 550 5.6.0 and "line too long" errors?#

Those are a different limit, and the fix is different. RFC 5322 section 2.1.1 says each line must be no more than 998 characters and should be no more than 78, excluding the CR LF. A message with a longer line can be refused with text such as "maximum allowed line length is 998 octets".

Common causes reported in community threads are a very long unbroken line of HTML, a base64 blob that was not wrapped, and a header that grew with every reply until it exceeded the limit. Treat those as likely suspects to check, not as a guarantee; confirm against your own message.

To find long lines in a saved message, count characters per line. Each line includes its CR, so flag anything over 999:

awk '{ if (length($0) > 999) print NR ": " length($0) }' message.eml

The fix is to fold long header values and wrap long body lines. For HTML emails, a mail library that encodes the body as quoted-printable or base64 wraps lines for you. For plain text, wrap at around 78 characters.

Can the recipient fix it?#

Yes, but you usually cannot make them. Microsoft's article lists two options for the recipient's administrator: turn off bare line feed rejection on the server if it supports that, or move to server software that supports BDAT. For Exchange Server, it names the BareLinefeedRejectionEnabled setting on the Receive connector for internet mail, set to $false.

Asking a customer's IT team to loosen security settings because your message is malformed is rarely a good trade. Fix the message first and keep the recipient-side change as a last resort for a sender you cannot change.

A short checklist#

1. Read the bounce for 5.6.11 and "bare line feeds", or for a line-length message.
2. Capture the raw bytes that were actually sent.
3. Run the grep check for lines that do not end in CR.
4. Normalize every text part to CR LF before serializing and signing.
5. Wrap lines that exceed 998 characters, and aim for about 78.
6. Test against the failing destination with a raw replay before you turn the sender back on.

Where does Koltrix fit?#

Koltrix is AI-first email for SaaS teams, with a transactional email API and an SMTP relay. If you send through an API, you hand over content and the service builds the message, which removes most hand-assembled line endings. If you speak SMTP directly, the line endings you write are the line endings that get sent, so the checks above apply. For choosing between the two paths, see SMTP relay vs HTTP API. If an AI assistant reads your mailbox through the Koltrix MCP server, a bounce like this is just another message it can summarize and help you act on. Check docs.koltrix.com for exact sending behavior.

Bottom line#

550 5.6.11 is a formatting error, not a reputation problem. A bare line feed is an LF with no CR in front of it, RFC 5322 forbids it, and many servers now refuse it because Microsoft 365 no longer cleans it up for them. Find the lines, convert every ending to CR LF before you serialize and sign, and keep lines under 998 characters. Changing the recipient's server is possible but should be the last step.