117 de 117 códigos
Códigos de respuesta básicos
Estado del sistema o respuesta de ayuda del sistema. Poco usado en la práctica.
Mensaje de ayuda en respuesta al comando HELP, con información sobre cómo usar el servidor o un comando concreto.
Saludo inicial del servidor al abrir la conexión: el servicio está listo. También responde a STARTTLS para indicar que puede comenzar la negociación TLS.
El servidor cierra la conexión, normalmente en respuesta al comando QUIT.
La autenticación con AUTH se ha completado correctamente. Suele acompañarse del código mejorado 2.7.0.
La acción solicitada se ha completado. Es la respuesta habitual a EHLO, MAIL FROM, RCPT TO y al final de DATA, cuando el servidor acepta el mensaje.
El destinatario no es local, pero el servidor acepta el mensaje y lo reenviará a la dirección indicada.
El servidor no confirma si el usuario existe (VRFY deshabilitado para evitar la enumeración de cuentas), pero aceptará el mensaje e intentará entregarlo.
Respuesta a ETRN: el servidor ha empezado a entregar los mensajes que tenía en cola para el dominio o nodo solicitado.
Desafío del servidor durante AUTH, codificado en Base64. El cliente debe responder con el siguiente dato del mecanismo (por ejemplo, el usuario o la contraseña en AUTH LOGIN).
Respuesta a DATA: el servidor espera el contenido del mensaje, que termina con una línea que contiene solo un punto.
El servicio no está disponible y el servidor cierra la conexión: apagado, sobrecarga, demasiadas conexiones o límite de envío temporal. El remitente debe reintentarlo más tarde.
El usuario debe cambiar su contraseña o migrar a otro mecanismo de autenticación antes de poder autenticarse. Se acompaña del código mejorado 4.7.12.
El buzón no está disponible temporalmente: ocupado, bloqueado o rechazado de forma transitoria por políticas. El greylisting suele responder con este código o con 451.
Se ha abortado la acción por un error local del servidor, como un fallo al consultar el DNS o un filtro que no ha respondido. El remitente debe reintentarlo más tarde.
El servidor no tiene espacio suficiente para aceptar el mensaje por ahora. También indica que se ha superado el número de destinatarios por mensaje: el cliente debe enviar el resto en otra transacción.
Fallo temporal de autenticación (por ejemplo, el servidor de credenciales no responde) o TLS no disponible momentáneamente al pedir STARTTLS.
El servidor no puede atender por ahora los parámetros enviados en MAIL FROM o RCPT TO, pero podría aceptarlos más tarde.
Respuesta a ETRN: el servidor no puede procesar por ahora la cola de mensajes del nodo solicitado.
Respuesta a ETRN: el nodo o dominio solicitado no tiene permitido pedir la entrega de su cola.
El servidor no reconoce el comando o la línea es demasiado larga. También lo usa AUTH cuando una línea del intercambio supera el máximo permitido.
El comando es válido, pero sus parámetros o argumentos no: por ejemplo, una dirección mal formada en MAIL FROM o un nombre no válido en EHLO.
El servidor reconoce el comando pero no lo implementa o lo tiene deshabilitado, como VRFY o EXPN en muchos servidores.
Los comandos han llegado en un orden incorrecto, por ejemplo RCPT TO antes de MAIL FROM, o DATA sin destinatarios válidos. Algunos servidores lo devuelven si se intenta enviar sin autenticarse.
El servidor no admite el parámetro indicado, por ejemplo un mecanismo de AUTH que no soporta.
El host no acepta correo de ningún tipo. Se envía como saludo en lugar de 220 y el cliente no debe reintentar.
El servidor exige autenticarse, o iniciar TLS con STARTTLS, antes de aceptar el comando. Típico al usar el puerto de envío 587 sin credenciales.
El mecanismo de autenticación elegido es demasiado débil según la política del servidor. Algunos proveedores lo devuelven cuando exigen contraseñas de aplicación u OAuth.
Usuario o contraseña incorrectos, o credenciales rechazadas. Se acompaña del código mejorado 5.7.8.
El mecanismo de autenticación elegido solo se permite sobre una conexión cifrada: hay que ejecutar STARTTLS primero.
El buzón no existe o no está disponible, o el mensaje se ha rechazado por políticas (spam, listas negras, SPF, DKIM o DMARC). El código mejorado que lo acompaña indica la causa concreta.
El destinatario no es local y el servidor no reenvía el mensaje; puede indicar a qué dirección enviarlo.
Se ha superado el espacio asignado: el buzón del destinatario está lleno o el mensaje excede el tamaño máximo que anuncia la extensión SIZE.
La dirección de correo no es válida o no está permitida, por ejemplo por una sintaxis incorrecta o porque el remitente no puede usar esa dirección.
La transacción ha fallado. Como saludo inicial significa que no hay servicio SMTP para ese cliente; tras DATA, que el mensaje se ha rechazado, a menudo por su contenido o por la reputación del remitente.
El servidor no reconoce o no implementa un parámetro de extensión enviado en MAIL FROM o RCPT TO.
El dominio del destinatario publica un null MX (un registro MX que apunta a «.»): declara que no recibe correo, así que no tiene sentido reintentar.
Códigos de estado mejorados (RFC 3463)
Estado sin más detalle: se usa cuando solo se conoce la clase del resultado (éxito, fallo transitorio o permanente).
Hay un problema con alguna dirección del mensaje que no encaja en los códigos más específicos.
El buzón del destinatario no existe en el servidor de destino. Es el rebote clásico por una dirección mal escrita o una cuenta dada de baja.
El dominio o sistema de destino no existe o no puede aceptar correo, por ejemplo porque el dominio no resuelve.
La dirección del destinatario tiene una sintaxis no válida.
La dirección del destinatario coincide con más de un buzón en el sistema de destino.
La dirección del destinatario es válida. Aparece como 2.1.5 en la respuesta positiva a RCPT TO.
El buzón existía, pero se ha trasladado y no hay una dirección de reenvío conocida.
La dirección del remitente tiene una sintaxis no válida.
El dominio del remitente no existe o no acepta respuestas, por ejemplo porque no tiene registros MX ni A.
El mensaje se ha entregado a un sistema que no admite notificaciones de estado, así que no se podrá confirmar su entrega final.
El dominio del destinatario publica un null MX: declara que no recibe correo.
El buzón existe, pero algo relacionado con él ha impedido la entrega y no hay un código más específico.
El buzón existe, pero está deshabilitado y no acepta mensajes, por ejemplo una cuenta suspendida.
El buzón del destinatario ha superado su cuota de almacenamiento.
El mensaje supera el tamaño máximo que el destinatario tiene permitido recibir.
El destinatario es una lista de distribución y no se ha podido expandir en sus miembros.
El sistema de destino ha tenido un problema que no encaja en los códigos más específicos.
El almacenamiento del sistema de correo de destino está lleno.
El host de destino no está aceptando mensajes, por un apagado inminente, sobrecarga o mantenimiento.
El sistema de destino no soporta alguna función que el mensaje requiere.
El mensaje supera el tamaño máximo que acepta el servidor para cualquier destinatario.
El sistema de destino está mal configurado y no puede aceptar el mensaje.
El mensaje se ha aceptado, pero con una prioridad distinta a la solicitada (extensión MT-PRIORITY).
Ha habido un problema de red o de enrutamiento que no encaja en los códigos más específicos.
El servidor de destino no ha respondido al intentar conectarse.
La conexión se ha establecido, pero se ha cortado o se ha vuelto inestable antes de completar la entrega.
Ha fallado un servicio de directorio necesario para la entrega, normalmente la resolución DNS.
No se ha encontrado una ruta hacia el destino, por ejemplo porque el dominio no tiene registros MX ni A utilizables.
El sistema de correo está congestionado y no puede procesar el mensaje por ahora.
Se ha detectado un bucle de enrutamiento: el mensaje ha pasado demasiadas veces por los mismos servidores.
Se ha agotado el tiempo máximo de reintentos y el mensaje se descarta sin haberse entregado.
Ha habido un problema con el protocolo de entrega que no encaja en los códigos más específicos.
El comando no es válido, no está permitido en ese momento o no se reconoce.
El comando tiene un error de sintaxis y el servidor no lo puede interpretar.
El mensaje tiene más destinatarios de los que el servidor acepta en una transacción.
El comando es válido, pero sus argumentos no lo son o no están soportados.
Hay una incompatibilidad de versión del protocolo entre el cliente y el servidor.
Una línea del intercambio de AUTH supera la longitud máxima que admite el servidor.
Ha habido un problema con el contenido del mensaje que no encaja en los códigos más específicos.
El destino no admite el tipo de contenido del mensaje o de alguno de sus adjuntos.
Para entregar el mensaje habría que convertir su contenido, pero el remitente lo ha prohibido.
Para entregar el mensaje habría que convertir su contenido, y el servidor no sabe hacerlo.
El mensaje se ha entregado, pero en la conversión del contenido se ha perdido información.
Ha fallado la conversión del contenido del mensaje.
No se ha podido obtener el contenido del mensaje referenciado por URL (extensión BURL).
El remitente o el destinatario no admiten direcciones con caracteres fuera de ASCII (correo internacionalizado, SMTPUTF8).
El servidor necesita responder con texto UTF-8, pero el cliente no ha anunciado soporte para SMTPUTF8.
El mensaje tiene cabeceras UTF-8 y no puede transferirse a uno o más destinatarios que no las admiten, así que se rechaza.
Estado de seguridad sin más detalle. Aparece en autenticaciones correctas (2.7.0), en fallos temporales de AUTH (4.7.0) y en rechazos por política.
El remitente no está autorizado a enviar a ese destinatario: bloqueo por lista negra, reputación, antispam o intento de relay no permitido. En su variante 4.7.1 suele indicar greylisting.
El remitente no tiene permiso para enviar a esa lista de distribución.
Habría que convertir el mensaje de un protocolo de seguridad a otro y no es posible.
El mensaje requiere funciones de seguridad que el destino no soporta.
Ha fallado una operación criptográfica en el transporte, por ejemplo la verificación de una firma o el descifrado.
El destino no soporta el algoritmo criptográfico usado en el mensaje.
Ha fallado la verificación de integridad: el mensaje se ha modificado en tránsito o la suma de verificación no coincide.
Las credenciales de autenticación no son válidas: usuario o contraseña incorrectos.
El mecanismo de autenticación elegido es más débil de lo que exige la política del servidor.
Hace falta una capa de cifrado externa, como TLS, para usar el mecanismo de autenticación pedido. Pensado sobre todo para mecanismos que envían la contraseña en texto plano.
El mecanismo de autenticación pedido solo se permite sobre una conexión cifrada.
El usuario debe cambiar su contraseña o pasar a otro mecanismo de autenticación.
La cuenta del usuario que intenta autenticarse está deshabilitada.
El servidor solo acepta mensajes de sistemas con los que tiene una relación de confianza establecida.
La prioridad del mensaje es demasiado baja para aceptarlo en este momento (extensión MT-PRIORITY).
El mensaje es demasiado grande para la prioridad indicada (extensión MT-PRIORITY).
El buzón ha cambiado de propietario desde la fecha que ha indicado el remitente, así que el mensaje no se entrega (extensión RRVS).
El dominio del destinatario ha cambiado de propietario desde la fecha que ha indicado el remitente (extensión RRVS).
El servidor no puede verificar si el buzón ha cambiado de propietario, como ha pedido el remitente (extensión RRVS).
El mensaje no tiene ninguna firma DKIM válida y la política del receptor la exige.
El mensaje tiene firmas DKIM válidas, pero ninguna cumple la política del receptor (por ejemplo, por el dominio firmante o el algoritmo).
El mensaje no tiene una firma DKIM válida del mismo dominio que aparece en la cabecera From.
La IP que envía no está autorizada en el registro SPF del dominio remitente.
La evaluación del SPF ha dado error, por ejemplo por un registro mal formado o demasiadas consultas DNS.
La IP que envía no tiene DNS inverso (PTR), o el nombre que devuelve no resuelve de vuelta a esa IP.
Han fallado varios controles de autenticación del mensaje a la vez, como SPF y DKIM.
El dominio del remitente publica un null MX, así que no podría recibir respuestas ni rebotes y el mensaje se rechaza.
El mensaje parece formar parte de un envío masivo de mensajes abusivos similares.
Ha fallado la validación de la cadena ARC, que conserva los resultados de autenticación cuando el mensaje pasa por reenviadores o listas de correo.
El mensaje exige REQUIRETLS y el siguiente servidor de la ruta no soporta esa extensión, así que no puede entregarse con garantía de cifrado.
Pega la respuesta completa del servidor, por ejemplo 550 5.7.1 Message rejected, para ver a la vez el código básico y el mejorado. En un código básico, la búsqueda también muestra los códigos mejorados que suelen acompañarlo.
Cómo funciona
En una sesión SMTP, cada comando del cliente (EHLO, MAIL FROM, RCPT TO, DATA…) recibe una respuesta del servidor que empieza con un código de tres dígitos. El primero dice cómo ha terminado: 2 significa éxito, 3 que el servidor espera más datos, 4 un error transitorio y 5 un error permanente. El segundo indica el área: x0z sintaxis, x1z información, x2z conexión y x5z sistema de correo. El texto que sigue al código es libre y cada servidor escribe el suyo; los programas solo miran el número.
Como tres dígitos dicen poco sobre la causa, la RFC 3463 definió los códigos de estado mejorados, con formato clase.sujeto.detalle: 5.1.1 es un fallo permanente (5) de direcciones (1) porque el buzón no existe (1). La clase repite el sentido del primer dígito (2, 4 o 5), el sujeto agrupa la causa y el detalle la precisa. Los servidores que los usan lo anuncian con la extensión ENHANCEDSTATUSCODES en la respuesta a EHLO, y el mismo código aparece en el campo Status de los mensajes de rebote.
La tabla reúne los códigos básicos de la RFC 5321 y los que añaden las extensiones de uso habitual (AUTH, STARTTLS, ETRN y null MX), además de todos los códigos mejorados del registro de la IANA, con los códigos básicos con los que suele aparecer cada uno. Los grandes proveedores añaden sus propios textos y enlaces de ayuda, pero siempre sobre estos mismos números.
Ejemplos
550 5.1.1 <nadie@example.com>: Recipient address rejected: User unknown in local recipient table5xx Permanent · X.1.1 Bad destination mailbox addressEl rebote típico de Postfix cuando la cuenta no existe. Reintentar no sirve: hay que corregir la dirección. Si el mismo destinatario funcionaba antes, lo más probable es que la cuenta se haya dado de baja.450 4.2.0 <ana@example.com>: Recipient address rejected: Greylisted4xx Transient · X.2.0 Other or undefined mailbox statusGreylisting: el servidor rechaza temporalmente al remitente desconocido y espera que lo reintente. Un servidor de correo legítimo lo hace solo a los pocos minutos y el mensaje entra; muchos programas de spam no reintentan nunca.AUTH LOGIN334 VXNlcm5hbWU6El 334 trae el desafío en Base64: VXNlcm5hbWU6 es «Username:» y el siguiente, UGFzc3dvcmQ6, es «Password:». Si las credenciales son incorrectas, el servidor responde 535 5.7.8; si pide cifrar antes, 538 o 530.Casos de uso
- Entender por qué ha rebotado un correo a partir del mensaje de error que ha devuelto el servidor.
- Distinguir si un error es transitorio y la cola lo reintentará, o permanente y hay que actuar.
- Diagnosticar fallos de autenticación al configurar el envío de correo desde una aplicación, una impresora o un servidor.
- Interpretar rechazos por SPF, DKIM, DMARC, DNS inverso o listas negras en los logs del servidor de correo.
- Clasificar rebotes en una plataforma de envíos masivos para dar de baja las direcciones inexistentes.
- Leer una sesión SMTP capturada con telnet, openssl s_client o swaks.
Preguntas frecuentes
¿Qué diferencia hay entre un error 4xx y uno 5xx?
Un 4xx es transitorio: el servidor que envía deja el mensaje en cola y lo reintenta cada cierto tiempo, en general durante cuatro o cinco días, antes de rendirse y generar un rebote. Un 5xx es permanente: el rebote es inmediato y reintentar el mismo mensaje sin cambiar nada volverá a fallar.
¿Por qué la respuesta trae dos códigos, como 550 5.1.1?
El primero es el código básico de tres dígitos que exige la RFC 5321. El segundo es el código de estado mejorado de la RFC 3463, que precisa la causa: un 550 puede deberse a un buzón inexistente (5.1.1), a un bloqueo por política (5.7.1) o a un fallo de SPF (5.7.23). Para diagnosticar, conviene fijarse sobre todo en el mejorado.
¿Qué significa el guion en 550-5.7.1?
Que la respuesta ocupa varias líneas. Todas llevan el mismo código, pero las intermedias lo separan del texto con un guion y la última con un espacio, y así el cliente sabe cuándo ha terminado la respuesta. Es lo mismo que se ve en la lista de extensiones que devuelve EHLO.
¿Por qué me rechazan con 550 5.7.1 si la dirección existe?
Porque el 5.7.1 no habla del destinatario sino del remitente: el servidor no te autoriza a entregarle ese mensaje. Las causas habituales son que la IP que envía esté en una lista negra, que falle la verificación SPF, DKIM o DMARC del dominio, que la IP no tenga DNS inverso o que se haya intentado usar el servidor como relay sin autenticarse. El texto que acompaña al código suele dar la pista.
¿Por qué obtengo 530 o 535 al enviar correo desde una aplicación?
El 530 indica que el servidor exige autenticarse, o iniciar TLS, antes de aceptar el mensaje; el 535, que el usuario o la contraseña son incorrectos. Comprueba que la aplicación use el puerto 587 con STARTTLS o el 465 con TLS implícito, que tenga activada la autenticación y, en proveedores como Gmail o Microsoft 365, que uses una contraseña de aplicación u OAuth en lugar de la contraseña habitual.