Error 550 5.7.1: causas y cómo solucionarlo

¿Por qué se rechazan los correos electrónicos con un error 550 5.7.1?

Una respuesta 550 5.7.1 significa que un servidor de correo ha rechazado un mensaje por motivos relacionados con sus políticas. El código, por sí solo, no identifica la política concreta: un servidor puede indicar un fallo de autenticación, mientras que otro puede bloquear a un remitente, una dirección o el contenido del mensaje. Si buscas qué significa el error 550 5.7.1, el texto de diagnóstico que acompaña al código y el servidor que lo emite son los puntos de partida para solucionar el problema.

Si el informe de entrega solo indica que se ha rechazado el mensaje, busca la respuesta SMTP completa en el registro de eventos o en el informe de rebote de tu servicio de envío. Una investigación útil empieza por esa información, no por cambiar la configuración DNS ni por pedir al destinatario que revise la carpeta de spam.

¿Qué significa un rechazo 550 5.7.1 durante el intercambio SMTP?

Los servidores SMTP intercambian códigos de estado mientras procesan un mensaje. El primer dígito de 550 indica un fallo permanente: no se espera que volver a intentarlo sin modificar el mensaje dé resultado. El código ampliado 5.7.1 apunta a un problema de seguridad o de políticas, pero no especifica qué regla se ha activado.

El texto que aparece después del código es importante. Por ejemplo, «remitente no autorizado» sugiere un problema distinto de «mensaje rechazado por una política local». Estas frases son solo ejemplos, no definiciones universales: cada proveedor de correo redacta sus propios diagnósticos, y las mismas palabras pueden tener distintos significados según el sistema.

Considera el 550 5.7.1 una categoría, no un diagnóstico. Si te preguntas por qué se rechazan mis correos electrónicos cuando aparece este error, la respuesta práctica es que un sistema receptor ha aplicado una política y necesitas la respuesta completa para saber cuál.

¿Cómo puedes saber si el mensaje lo rechazó el servidor del destinatario o una pasarela intermedia?

Consulta la transcripción SMTP o el informe de rebote detallado para identificar el host que devolvió la respuesta 550. El host que rechaza el mensaje suele aparecer junto al diagnóstico, a veces como nombre de servidor o dirección IP. Compáralo con el dominio del destinatario y con cualquier servicio de seguridad de correo que sepas que está delante de ese dominio.

El correo del destinatario puede pasar por una pasarela de filtrado antes de llegar al servidor de su buzón. Si esa pasarela devuelve el rechazo durante el intercambio SMTP, es posible que el servidor del buzón del destinatario ni siquiera llegue a ver el mensaje. El informe de rebote puede indicar directamente el nombre de la pasarela, o mostrar un nombre de host que tendrás que confirmar con el administrador del destinatario.

Fíjate en la secuencia de respuestas del servidor, en lugar de confiar en los campos «De» o «Para» de una notificación. Por ejemplo, una transcripción podría mostrar que tu sistema de envío se conecta a un host, transmite los datos del mensaje y recibe de ese host una respuesta 550. Esa respuesta identifica el sistema que tomó la decisión, aunque otro proveedor gestione la bandeja de entrada del destinatario.

Algunas plataformas de envío solo muestran un breve resumen en el panel de control. Abre los detalles del evento o exporta el informe de rebote sin procesar, si está disponible. Las líneas adicionales pueden revelar qué host rechazó el mensaje y en qué momento.

¿Por qué pueden rechazar un mensaje después de aceptar la conexión al servidor?

Que se acepte una conexión SMTP solo significa que el sistema receptor ha permitido iniciar la comunicación. No significa que haya aprobado al remitente, al destinatario ni al mensaje. Las comprobaciones de políticas pueden realizarse en varias etapas: después de indicar la dirección del remitente, después de especificar el destinatario o una vez transmitido el contenido del mensaje.

Un servidor puede aceptar la conexión y luego rechazar una dirección concreta del destinatario. En otro caso, puede aceptar el sobre del mensaje y analizarlo después de que el servidor remitente transmita el contenido. Por eso, la respuesta final puede llegar más adelante durante el intercambio, aunque la conexión inicial pareciera normal.

El momento del rechazo ayuda a acotar la investigación. Si aparece antes de que se envíe el cuerpo del mensaje, el problema podría estar relacionado con el host de envío, la identidad del remitente o las políticas del destinatario. Si aparece después del envío del cuerpo, puede que el sistema haya evaluado el contenido o la combinación de remitente, destinatario y detalles del mensaje. El texto de la respuesta sigue siendo la prueba clave.

¿Qué debes revisar en el informe de rebote completo antes de cambiar la configuración del correo?

Guarda el informe de rebote original antes de editar registros DNS, cambiar la dirección de envío o volver a enviar el mensaje. Un informe completo deja constancia de la decisión del sistema receptor y facilita la comparación con intentos posteriores. Revisa estos datos:

• Código de estado ampliado: Confirma si la respuesta es 5.7.1 u otro código. Es posible que el resumen del informe de rebote no incluya el código exacto devuelto durante la comunicación SMTP.
• Texto de diagnóstico: Copia la explicación completa del servidor, incluidos los números de referencia o las etiquetas de políticas. No te bases en el mensaje abreviado del panel de control.
• Host que rechazó el mensaje: Anota el nombre de host o la dirección IP que aparece junto a la respuesta. Esto ayuda a determinar si la decisión provino del servidor del destinatario o de una pasarela de filtrado.
• Marca de tiempo: Anota la fecha y la hora, incluida la zona horaria si aparece. El administrador receptor puede usarlas para buscar el evento en los registros de correo.
• Datos del mensaje y del destinatario: Conserva el ID del mensaje, la dirección del remitente, la del destinatario y cualquier intento de entrega que se indique. Estos datos permiten identificar la transacción sin hacer conjeturas.

Conserva intacto el texto original, aunque incluya encabezados técnicos. Puede ser conveniente ocultar información personal que no venga al caso antes de compartirlo, pero eliminar el host que rechazó el mensaje o la línea de diagnóstico puede dificultar mucho la investigación.

¿Cómo puedes distinguir un bloqueo por políticas del remitente de una regla específica del destinatario?

Compara los resultados entre destinatarios y dominios. Si varios dominios no relacionados rechazan el mismo mensaje con textos similares, es más probable que el problema esté del lado del remitente. Si lo rechaza una sola dirección o una organización, pero otros destinatarios lo reciben, es más probable que se deba a una regla local del destinatario o a una política de su pasarela.

Estos patrones son indicios, no pruebas. La pasarela de un destinatario puede aplicar una regla a todo un dominio de envío, por lo que el problema puede afectar a varias personas de la misma organización. A la inversa, un problema de configuración del remitente puede parecer selectivo si solo algunos proveedores receptores aplican la política correspondiente.

Busca en el diagnóstico expresiones que indiquen el alcance del problema, como un remitente bloqueado, un destinatario restringido o una regla de seguridad local. Después, realiza una prueba controlada: envía el mismo tipo de mensaje a otro destinatario autorizado sin cambiar varias opciones a la vez. Si el mensaje llega a otros dominios, pero falla sistemáticamente en una empresa, comparte la información con el administrador de correo de esa empresa.

Si el rechazo menciona la autenticación o las políticas del dominio, revisa los registros del dominio de envío y su alineación antes de solicitar una excepción. Una lista de comprobación específica, como la de esta guía sobre configuración de la autenticación del correo electrónico, puede ayudarte a verificar los registros pertinentes; no demuestra que la autenticación haya causado el error 550, a menos que el informe de rebote respalde esa conclusión.

¿Qué información debes facilitar al administrador de correo del destinatario?

Envía un informe breve con suficiente información para que el administrador encuentre el evento en sus registros. Incluye el informe de rebote o la transcripción SMTP completos, el ID del mensaje, las direcciones del remitente y del destinatario, y la hora aproximada del envío con su zona horaria. Añade el nombre de host que rechazó el mensaje y la línea exacta del diagnóstico 550 5.7.1.

Describe lo ocurrido sin hacer conjeturas sobre la causa. Por ejemplo: «Un mensaje enviado a alex@example.com a las 14:20 UTC fue rechazado por mx.example.net con el error 550 5.7.1; el informe de rebote adjunto contiene la respuesta completa». Así le das al administrador datos concretos para buscar el evento, sin presentar como un hecho una hipótesis aún no confirmada.

Si enviaste el mensaje mediante un proveedor o una aplicación, indica cuál y añade el identificador del evento de entrega, si está disponible. En el caso del correo transaccional, el registro de eventos puede ayudar a relacionar una acción de la aplicación con el intento SMTP. La información sobre webhooks de correo electrónico para mensajes transaccionales puede ayudar a los equipos a conservar esos eventos de entrega para revisarlos más adelante.

¿Cuándo conviene pedir al destinatario que añada un remitente a la lista de permitidos?

Pregunta si pueden añadirlo a la lista de permitidos cuando el administrador del destinatario confirme que una regla local bloquea a un remitente legítimo y explique qué identidad o dominio del remitente debe incluirse en la excepción. Facilita el informe de rebote exacto e indica la dirección o el dominio del remitente. El administrador debe decidir si esa excepción se ajusta a las políticas de su organización.

Añadir un remitente a la lista de permitidos no soluciona todos los errores 550 5.7.1. Si quieres saber cómo solucionar un rechazo de correo 550 5.7.1, empieza por el motivo de rechazo indicado y solicita una excepción local solo cuando el administrador de correo del destinatario confirme que el responsable es una política de su propio sistema. Si el informe de rebote apunta a un problema de autenticación del remitente, una dirección mal formada o un incumplimiento más general de las políticas, una excepción podría ocultar el síntoma sin corregir la causa.