Error 550 al enviar correo: causas y comprobaciones
Qué significa un error 550, cómo leer el rechazo completo y qué comprobar antes de cambiar contraseñas, servidores o registros del dominio.
Envía un documento y recibe una respuesta llena de números: 550. El mensaje parece técnico, pero la pregunta es práctica: ¿se equivocó de dirección, hay un problema en su correo o lo está rechazando el destinatario?
El número, por sí solo, no permite elegir una de esas respuestas. 550 indica que un servidor rechazó ese intento de envío. La explicación que viene después es la que ayuda a encontrar la causa. “Dirección inexistente” y “envío no permitido” pueden compartir ese número y exigir soluciones distintas.
Guarde el error completo antes de intentar otra vez
Conserve el aviso original. Busque la línea que empieza por 550, los números adicionales —por ejemplo, 5.1.1 o 5.7.1— y el texto que los acompaña. También importa qué servidor lo emitió.
Anote a quién intentaba escribir, desde qué aplicación y cuándo ocurrió. Si había varios destinatarios, revise el resultado de cada uno: el rechazo de una dirección no implica que todos hayan fallado.
En la terminología del correo, un error permanente como 550 no significa que el problema sea irreversible. Significa que ese intento no debe repetirse sin más esperando un resultado distinto. Los errores de la familia 4xx son temporales y reciben otro tratamiento. Esta distinción está definida en el estándar SMTP.
Qué puede estar diciendo el rechazo
| Si el aviso contiene… | Qué puede significar | Primera comprobación |
|---|---|---|
| 5.1.1, “user unknown” o “mailbox not found” | La dirección de destino no se reconoce. | Confirmar la dirección por otro canal y revisar el autocompletado. |
| 5.7.1, “not authorized” o una política de seguridad | Falta un permiso o el destino aplica una restricción. | Leer la política indicada y saber qué servidor rechazó. |
| “relay denied” o “unable to relay” | El servidor no permite reenviar ese mensaje por esa ruta. | Revisar la cuenta y el servidor de salida con el administrador. |
| 5.7.26 en una respuesta de Gmail | Hay un problema de autenticación descrito en el aviso. | Revisar el texto exacto y la ruta que envió el mensaje. |
La tabla orienta, no reemplaza el aviso. Los códigos ampliados del estándar y las tablas de cada proveedor deben leerse en su contexto. Gmail, por ejemplo, utiliza distintos textos para errores de autenticación.
Si el aviso dice que el buzón está lleno, siga esa explicación: los errores de cuota pueden aparecer con otros números, como 552 o 5.2.2. No todos los problemas de entrega son un 550.
Si la dirección no existe
Compruebe letras, puntos y dominio. Es frecuente que el autocompletado conserve una dirección antigua, especialmente si una persona cambió de cargo o de empresa.
Pida al destinatario que confirme su dirección mediante un canal conocido. Si es correcta, su administrador deberá comprobar que el buzón o alias exista y pueda recibir mensajes. Cambiar la contraseña de su propia cuenta no arregla un buzón inexistente en el otro extremo.
Si aparece una política o un permiso
Un grupo puede aceptar mensajes solo de personas autorizadas. Una organización puede rechazar ciertos remitentes o aplicar restricciones a un mensaje. Por eso 5.7.1 no equivale automáticamente a “estoy en una lista negra”. La guía de Microsoft sobre 550 5.7.1 recoge diferentes situaciones.
En ocasiones debe intervenir el administrador del destinatario. En otras, el problema está en su configuración de salida. El aviso y los registros permiten distinguirlas; no conviene cambiar el DNS al azar para probar suerte.
Si ocurre en Outlook, pero no en el correo web
La diferencia ayuda a localizar el problema. Compare qué cuenta y servidor de salida utiliza cada opción. Una aplicación puede conservar una configuración anterior o utilizar una ruta distinta.
Outlook es una aplicación: ver el error allí no demuestra que su servicio sea Microsoft 365. Envíe el aviso al proveedor que realmente administra su correo y explique desde dónde funciona y desde dónde falla.
No desactive el cifrado ni permita envíos sin control para eliminar el error. Si el aviso menciona relay, la solución debe conservar las restricciones que impiden que terceros abusen del servidor.
Si el rechazo menciona SPF, DKIM o DMARC
Estas comprobaciones ayudan a validar el origen del mensaje y su relación con el dominio visible. Si falla solo una aplicación —por ejemplo, facturación—, revise esa ruta antes de modificar toda la empresa.
No basta con comprobar que existen registros en el dominio: hay que ver cómo salió el mensaje que fue rechazado. Y no publique una política más permisiva como solución permanente sin entender qué está fallando. Podría dejar pasar usos que la protección buscaba evitar.
Un mensaje útil para pedir ayuda
Puede enviar a su proveedor una solicitud como esta, completándola por un canal privado:
Recibimos un rechazo al enviar correo. Adjuntamos el aviso original con el error completo. Ocurrió en esta fecha y hora, desde esta cuenta y aplicación, hacia este destinatario. Afecta solo a ese destino / a varios destinos. Desde el correo web funciona / también falla. ¿Pueden identificar qué servidor rechazó el mensaje, la causa y la comprobación posterior a la corrección?
No incluya su contraseña. Si comparte el caso públicamente, retire direcciones, identificadores y cualquier información de clientes.
Si el envío no puede esperar
Contacte al destinatario por un medio ya conocido y acuerde una alternativa autorizada. Para documentos sensibles, evite improvisar enlaces públicos o cuentas personales. Si el mensaje trata de un pago, confirme cualquier cambio de instrucciones por separado.
