Rechazo de envíos en Outlook/Hotmail por “Bare Line Feeds” (Error 5.6.11): causas y soluciones efectivas

¿Tus correos enviados desde Outlook.com rebotan con el mensaje «5.6.11 – bare line feeds are not allowed»? Este artículo explica en profundidad qué causa el problema, cómo diagnosticarlo y qué soluciones aplicar tanto en el lado del remitente como en el del destinatario.

Resumen de la situación

Desde mediados de 2022 se reportan rechazos sistemáticos cuando un mensaje originado en Outlook.com (o Hotmail) llega a determinados dominios que han endurecido el cumplimiento de los estándares SMTP. El servidor receptor interrumpe la entrega con el código 554 5.6.11 y la descripción “bare line feeds are not allowed”. Al tratarse de un error en la fase de aceptación de datos, la entrega nunca se reintenta. El remitente recibe un NDR inmediato.

Contexto del error 5.6.11 y bare line feeds

El estándar SMTP, consolidado en RFC 5321 y RFC 5322, exige que cada línea terminada en la conversación y en el cuerpo del mensaje utilice la secuencia \r\n (CR + LF). Un “bare LF” es un salto de línea que carece del retorno de carro previo (\n sin \r). Aunque la inmensa mayoría de MTA históricos toleran el formato Unix (\n), los operadores preocupados por la inyección de cabeceras y los ataques de protocol smuggling comienzan a rechazar cualquier desviación.

Microsoft, por su parte, reforzó sus propias pasarelas durante 2022 para detectar incoherencias y ampliar la trazabilidad, lo que coincidió con una oleada de dominios que aplicaron parses más estrictos. El cruce de ambos cambios destapó a millones de usuarios una incoherencia que tradicionalmente había pasado desapercibida.

Por qué Outlook.com puede generar LF huérfanos

• Copia y pega desde editores Unix. Al pegar texto procedente de Notepad++ configurado en modo “Unix”, Visual Studio Code o editores online que usan solo \n, el contenido incrustado en el cuerpo HTML conserva esos finales de línea.
• Formularios web incrustados. Algunas firmas corporativas o plantillas generadas por terceros incluyen campos <textarea> cuyo JavaScript fuerza \n para ahorrar espacio.
• Complementos del navegador. Extensiones que modifican plantillas o inyectan fragmentos (p. ej., gestores de plantillas de correo o integraciones de CRM) pueden reconstruir el DOM con finales de línea simplificados.
• Conversión defectuosa a texto plano. Al cambiar manualmente el tipo de mensaje de HTML a texto plano, ciertos caracteres ocultos se reinterpretan y dejan líneas huérfanas.

Impacto de las políticas estrictas del servidor receptor

Un servidor que valida cada octeto conforme a RFC 5321 realizará estas acciones:

1. Analiza carácter por carácter el flujo SMTP.
2. Detecta un \n no precedido de \r.
3. Interrumpe la recepción enviando 554 5.6.11 bare line feeds are not allowed.

Esta respuesta se envía antes del punto final “.” de la transacción DATA. Outlook.com, que se comunica mediante relays propios, reporta el fallo al usuario sin volver a intentar.

Tabla de problemas y acciones recomendadas

Problema identificado	Explicación	Acciones recomendadas
Bare line feed (\n sin \r)	El estándar requiere CR + LF. Un LF aislado se considera potencial vector de inyección de cabeceras o truncamiento.	Enviar un mensaje vacío de prueba para verificar si el problema persiste con contenido mínimo. Probar otro cliente (Outlook de escritorio, Thunderbird, Apple Mail) o configurar un envío mediante SMTP autenticado desde PowerShell; comparar la captura con Wireshark. Evitar pegar bloques de texto procedentes de editores Unix o limpiar la firma con un conversor a CRLF.
Política estricta en el receptor	El MTA del dominio destino aborta la sesión al detectar LFs huérfanos.	Compartir el NDR completo con el administrador del dominio. Solicitar la creación de un proxy o filtro que normalice los finales de línea antes de pasarlos al parser. Proponer una relajación temporal usando una política “accept‑then‑filter”.
Bloqueo de la comunicación	No se entrega ningún mensaje mientras persista la incoherencia.	Usar cuentas de otro proveedor (Gmail, Proton, etc.) o canales alternativos (Teams, WhatsApp) si la comunicación es crítica. Configurar reenvíos automáticos desde Outlook.com a un buzón intermedio capaz de reescribir EOLs.

Procedimiento de diagnóstico paso a paso

Para confirmar el origen exacto del fallo se aconseja:

1. Capturar el tráfico SMTP. Con smtp-cli o Wireshark, ejecutar STARTTLS y revisar la sección DATA. Buscar líneas que terminen en 0A (LF) sin 0D (CR) inmediatamente antes.
2. Validar el cliente. Reenviar el mismo contenido desde un cliente distinto. Si deja de fallar, el problema está en la composición original.
3. Analizar la plantilla HTML. Abrir la firma o la plantilla en un editor hexadecimal y comprobar los bytes de control.
4. Reproducir con correo sencillo. Enviar un correo solo con el texto “Prueba CRLF” escrito manualmente.
5. Consultar los logs del destinatario. En servidores Postfix, mirar el identificador de sesión y el momento exacto del corte para confirmar el flag de “Bad command sequence” interno.

Soluciones temporales mientras se adapta el servidor

• Intermediario SMTP. Configurar un pequeño forwarding host (Postfix o Exim) en una VM propia; aceptar por 587 SMTP Submission y reenviar al dominio destino tras convertir \n en \r\n.
• Servicios de pasarela comercial. Plataformas como Mailgun o SendGrid permiten reescribir líneas y firman DKIM automáticamente, evitando la reputación negativa.
• Macros de limpieza en Outlook de escritorio. Añadir un script VBA que recorra el cuerpo del mensaje antes de enviar y ejecute Replace(vbLf, vbCrLf).
• Adjuntar la información en PDF. Si el receptor solo necesita leer, enviar el contenido incriminado como fichero adjunto en lugar de texto incrustado.

Soluciones definitivas para administradores de dominios receptores

La estrategia a largo plazo es garantizar que el MTA acepte el correo y subsane él mismo las incoherencias, evitando rechazos innecesarios que impacten la reputación del dominio:

1. Actualizar el parser. Versiones recientes de OpenSMTPD, Postfix ≥ 3.8 y Exim ≥ 4.97 incluyen parches para tolerar LF aislados mientras aplican filtros internos.
2. Configurar smtpddiscardehlokeywordaddress. En Postfix, este ajuste permite añadir una etapa “cleanup” previa al antivirus que reescribe LFs.
3. Implementar un milter. Un milter en C o Python intercepta  y reemplaza LFs sin modificar los encabezados.
4. Auditoría de proveedores externos. A menudo detrás del dominio hay un filtrado antispam (Proofpoint, Barracuda, Mimecast); la petición debe cursarse a ese proveedor.
5. Documentar la excepción. Incluir en el RFC‑policy del dominio un apartado sobre tolerancia de CRLF para evitar que futuros cambios de hardening resuciten el problema.

Buenas prácticas para remitentes

• Evitar firmas complejas. Cada imagen incrustada o bloque HTML aumenta la probabilidad de inconsistencias.
• Emplear plantillas generadas por Outlook. No pegar directamente desde Word; utilizar “Guardar como plantilla” y reutilizarla.
• Desactivar complementos de navegador cuando redactes. Algunos scripts de productividad reescriben el DOM en tiempo real.
• Usar siempre UTF‑8 y quoted‑printable. Los codificadores MIME de Outlook se adhieren mejor al estándar cuando detectan esta combinación.
• Verificar con Ctrl+U la fuente del mensaje antes de enviar. En el visor de origen se pueden detectar patrones de LFs sospechosos.

Preguntas frecuentes

¿El problema aparece únicamente en Outlook.com?

No. Cualquier cliente o pasarela que inserte LFs aislados puede generar el rechazo, pero la casuística muestra que Outlook.com es la fuente más común porque el usuario no controla la capa SMTP.

¿Significa que Microsoft “bloquea” mis correos?

Microsoft no los bloquea. Outlook.com finaliza la transacción conforme al estándar; el bloqueo se produce porque el receptor exige CRLF y detecta que tu mensaje no los contiene en todos los casos.

¿Actualizar a Microsoft 365 o pagar una licencia E3 soluciona el problema?

No. El comportamiento es idéntico para cuentas gratuitas y de pago. El origen está en la construcción del cuerpo del mensaje y la validación externa.

¿Puedo desactivar la política en mi cuenta Hotmail?

No, porque no es una política del lado remitente; depende del servidor destino. La única solución controlada por el usuario es asegurarse de no incluir LFs huérfanos.

Conclusión

El error 5.6.11 bare line feeds are not allowed no indica un fallo de Outlook.com ni una restricción económica, sino un conflicto entre la forma en que se compone el mensaje y la política estricta del servidor receptor. La buena noticia es que, al entender el origen técnico —la ausencia de \r antes de \n—, resulta relativamente sencillo mitigar la incidencia:

• El remitente puede depurar la plantilla, usar otro cliente o pasar el mensaje por un intermediario que normalice CRLF.
• El destinatario puede actualizar su parser o habilitar filtros que subsanen el problema sin rechazar el correo.

Adoptar estas medidas mejora no solo la entrega puntual, sino la salud general del flujo de correo al reducir falsos positivos y preservar la reputación de ambos dominios.