550 5.7.1: mensaje rechazado y cómo leer el código

Su campaña se estancó detrás de un muro de respuestas 550 5.7.1, o un contacto les reenvió un rebote que termina en esos dígitos. El código parece específico. Las soluciones que la gente sugiere en línea se contradicen entre sí, porque responden a rebotes distintos que comparten el mismo número.

550 significa falla permanente. 5.7.1 significa que el receptor no aceptó la entrega ni el contenido del mensaje, como lo define el RFC 3463. Todo lo que sigue en esa línea es donde el receptor les dice qué fue lo que realmente no le gustó. Traten el 5.7.1 como una categoría, no como un diagnóstico.

Lo que realmente ocurre

Cuando un servidor receptor rechaza el correo en la capa SMTP, devuelve un código de tres dígitos, a menudo un estado extendido como 5.7.1, más una explicación breve en inglés. Su ESP guarda esa cadena en el registro de rebotes o en el reporte de entrega.

Dos fallas distintas causan la mayoría de estos rebotes.

Rechazo por política. El servidor aceptó la conexión, revisó quiénes dicen ser y qué enviaron, y rehusó el mensaje por su reputación o su autenticación. Normalmente verán palabras como SPF, DKIM, DMARC, policy, spam, blocked, o una cadena específica del proveedor como el 5.7.515 de Microsoft.

Relay denegado. El servidor no quiso transportar su correo porque no tienen permiso de enviar a través de ese host hacia ese destinatario. Estén atentos a relay, relaying denied, not permitted to relay o unauthorized.

Estas dos formas se llaman rechazo por política y relay denegado. El mismo número cubre ambas. Una corrección del permiso de relay no hace nada contra una falla de DMARC, y lo mismo aplica en sentido inverso.

Un rechazo por política real suele verse así:

550 5.7.1 Message rejected due to SPF policy

Un rechazo de relay real suele verse así:

550 5.7.1 <user@example.com>: Relay access denied

Los encabezados de un mensaje que sí llegó y después fue filtrado son otro caso. Este artículo cubre el rechazo en el momento SMTP, donde el mensaje nunca llegó a una bandeja de entrada. Antes de intentar cualquier corrección, clasifiquen el rebote en una de estas dos formas.

Rechazo por política: las tres causas, en orden de prioridad

Cuando el texto del rebote apunta a política, autenticación o spam, trabajen estas causas en orden.

1. SPF, DKIM o DMARC fallan en el correo del dominio remitente

Este es el 5.7.1 más común en correo legítimo en 2026. Gmail, Yahoo y Microsoft publican reglas para remitentes que tratan la autenticación ausente o fallida como motivo para rechazar el correo directamente, no solo para marcarlo como spam.

Lean Authentication-Results en un mensaje que llegó a un buzón de prueba, o en la copia saliente que su ESP conserva:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of bounce@esp.example does not designate 203.0.113.10 as permitted sender)
       dkim=pass header.i=@yourdomain.com
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Una sola rama en falla es suficiente para un 5.7.1 en receptores estrictos. La corrección es el registro que falló: publiquen o reparen SPF en cada ruta de envío, activen la firma DKIM con el selector de su dominio y lleven DMARC más allá de p=none hacia la aplicación estricta una vez que los reportes se vean limpios. La guía de fallas de SPF cubre el lado de los registros, y el artículo de requisitos de Gmail y Yahoo cubre las cadenas de aplicación que verán en los registros. Aquí no se repiten los pasos de los registros.

2. El dominio o la IP de envío está en una lista de bloqueo que el receptor consulta

El texto de política a veces nombra Spamhaus, SpamCop, Barracuda o un genérico block list. Una inclusión en la lista es un veredicto de reputación, no un error de sintaxis. Verifiquen el dominio y la IP saliente contra las listas que importan, corrijan la fuente de las quejas o del compromiso y después soliciten la remoción. El hub de colocación en spam conecta las inclusiones en listas de bloqueo con el patrón de síntomas cuando todos los proveedores los rechazan a la vez.

3. El contenido o las quejas activaron un límite del proveedor

Menos común como 5.7.1 puro, pero ocurre cuando el rebote menciona spam, bulk o user complaints. El diferimiento 421 4.7.0 [TSS04] de Yahoo suele aparecer primero mientras las quejas suben. Su autenticación puede estar perfecta aquí y aun así el correo se detiene. Extraigan la tasa de quejas de Google Postmaster Tools para el tráfico de Gmail y comparen la marca de tiempo del rebote con la campaña que salió ese día.

Relay denegado: las tres causas, en orden de prioridad

Cuando el rebote menciona relaying, su correo llegó a un servidor que no lo enviará por ustedes.

1. Host o puerto SMTP equivocado para la cuenta

Las plataformas de marketing, las API transaccionales y los proveedores de buzones documentan cada uno un host de envío. Si apuntan un script o un plugin mal configurado a smtp.gmail.com con credenciales que no pueden hacer relay, obtienen exactamente esta forma. Comparen su configuración con la documentación actual del proveedor y usen el endpoint de envío que este indica para clientes autenticados.

2. Credenciales ausentes, vencidas o de un buzón equivocado

El permiso de relay pertenece a la cuenta que inició sesión. Una clave de API rotada, una contraseña de aplicación revocada o credenciales SMTP de un servidor de pruebas que terminaron en producción aparecen como errores de relay, no como fallas de SPF. Regeneren las credenciales y envíen un mensaje de prueba a su propia dirección antes de reabrir la cola.

3. El servidor no permite su IP

Algunos hosts de correo antiguos y autoadministrados solo hacen relay desde rangos de IP de oficina. El envío desde la nube con una IP nueva de centro de datos falla con relay denegado incluso cuando su autenticación DNS está bien. Agreguen la IP de envío a la lista de permitidos o enruten el correo a través del relay autenticado del proveedor en lugar del host MX.

La corrección y cómo verificarla

Los rechazos por política terminan cuando la verificación en falla pasa en un mensaje nuevo. Editen el DNS, esperen a que se propague y después envíen una prueba. Los encabezados de ayer no prueban nada sobre el registro de hoy.

Pasen el dominio de envío por el email health check para ver SPF, DKIM y DMARC juntos. Envíen una prueba a un buzón que controlen y abran el código fuente sin procesar en el header analyzer. Lo que buscan es spf=pass, dkim=pass y dmarc=pass en el dominio From que realmente usan.

Los rechazos de relay terminan cuando la sesión SMTP inicia sesión en el host correcto. La comprobación es un envío exitoso en el registro del proveedor sin ningún 5.7.1. No reenvíen en bloque la cola fallida hasta que una prueba limpia pase.

El costo a escala

Un 5.7.1 en un panel es fácil de pasar por alto cuando golpea un segmento o un proveedor. La versión peligrosa es la deriva lenta: un selector DKIM vence un martes, un proveedor nuevo envía sin un include de SPF, una IP compartida recibe una inclusión por culpa de un vecino. Cada falla parece un rebote aislado hasta que una campaña entera devuelve el mismo código.

Una lectura de encabezados responde la pregunta de hoy para un mensaje. No puede decirles que SPF pasó de pass a fail hace seis días mientras no miraban. Por eso existe la vigilancia automatizada. LitInboxes vuelve a verificar autenticación, listas de bloqueo y reputación en cada dominio monitoreado cada seis horas, conserva un historial con fechas para que puedan emparejar un pico de rebotes con el día en que un registro cambió, y les avisa por email, Slack, Discord o webhook cuando algo se mueve. Hay un recorrido aquí por si quieren verlo sobre un dominio en vivo.

Lista de verificación

1. Copien el texto completo de la respuesta SMTP, no solo 550 5.7.1.
2. Decidan: rechazo por política o relay denegado, según la redacción.
3. Ruta de política: lean Authentication-Results, corrijan el registro en falla y hagan el chequeo de salud del dominio.
4. Ruta de relay: confirmen host, credenciales y lista de IP permitidas contra la documentación del proveedor.
5. Envíen un mensaje de prueba y confirmen que el código desapareció antes de reintentar la cola pendiente.
6. Si los rechazos se concentran en un proveedor, revisen Postmaster y las listas de bloqueo en busca de las señales de ese proveedor.