Códigos de rechazo SMTP explicados: qué significan 421, 451, 550 y los 5.7.x

Cuando un correo no llega, casi siempre hay un código esperando en los registros que explica por qué. Los servidores de correo no rechazan en silencio: devuelven un código SMTP, y aprender a leerlo convierte un misterio en un diagnóstico de un minuto. Desde que Gmail, Yahoo y Microsoft pasaron de filtrar el correo no conforme a rechazarlo en el propio SMTP, esos códigos dejaron de ser cosa de administradores de sistemas y se volvieron la diferencia entre una campaña que entra y una que rebota. Esta es la referencia que usamos nosotros, ordenada para que encuentres el tuyo rápido.

Anatomía de un código SMTP

Un mensaje de error SMTP tiene hasta tres partes, y cada una añade precisión. Primero, un código básico de tres dígitos, como 421, 450 o 550. Después, de forma opcional, un código de estado mejorado de tres números separados por puntos, como 4.2.2 o 5.7.1. Y por último, a menudo, un texto legible, como «Authentication required». Las tres juntas te dicen si reintentar o corregir algo antes.

El primer dígito del código básico es el que más decide. Marca la clase de la respuesta, y solo con él ya sabes si tienes tiempo o un problema definitivo.

Qué dice el código de estado mejorado

El código de estado mejorado, definido en el RFC 3463, es donde está el detalle útil. Tiene la forma clase.tema.detalle: el primer número repite la clase (2, 4 o 5), el segundo señala el tema del problema y el tercero afina el motivo. El segundo número es el que conviene memorizar, porque te lleva directo a la familia de la causa.

En la práctica, el .7 es el que más vas a ver hoy. Un 5.7.x es un rechazo de política y seguridad —autenticación, reputación, reglas del receptor— y es justo la familia que los grandes proveedores endurecieron en 2024 y 2025. Cuando veas un segundo dígito 7, piensa en SPF, DKIM, DMARC y reputación antes que en buzones o direcciones.

Temporal frente a permanente: la distinción que más importa

Antes de leer nada más, mira el primer dígito. Un 4xx es un fallo transitorio persistente: el receptor te dice «ahora no», y los sistemas de correo reintentan la entrega durante un tiempo. Un buzón lleno, un servidor ocupado o un límite de frecuencia caen aquí. Un 5xx es un fallo permanente: el receptor marca el intento como rebote duro y no lo reintentará. Una dirección inexistente, un dominio mal configurado o un rechazo por política caen aquí.

La consecuencia operativa es sencilla y se ignora a menudo. Un 4xx que se repite no es ruido para reintentar a ciegas: es el aviso previo a un 5xx, sobre todo cuando el motivo es de autenticación. Y un 5xx no se arregla reenviando; se arregla corrigiendo lo que el código señala. Confundir los dos es lo que convierte una incidencia menor en una cola atascada o en una reputación dañada.

Códigos temporales (4xx) más habituales

Estos te piden esperar, reintentar o aflojar el ritmo. Son recuperables, pero algunos —los de autenticación— son una cuenta atrás.

El greylisting merece una nota, porque asusta sin motivo: muchos servidores devuelven un 450 o un 451 la primera vez que te ven y aceptan el mensaje en el reintento, como filtro antispam barato. Si tu MTA reintenta con normalidad, no tienes que hacer nada. Donde sí hay que actuar es en los 4.7.26: una postergación por correo no autenticado es Gmail pidiéndote SPF o DKIM alineado antes de que el aviso se convierta en rechazo.

Códigos permanentes (5xx) más habituales

Estos son rebotes. El mensaje no ha llegado y no llegará hasta que cambies algo; el código te dice qué.

Conviene separar dos grupos que se confunden. El 550 5.1.1 es un problema de dirección: el destinatario no existe, y por más reputación que tengas, ese correo nunca llegará; revisa la dirección o limpia la lista. El 550 5.7.1 y compañía son de política: el receptor te conoce y decide no aceptarte, casi siempre por autenticación o reputación. Tratar un problema de dirección como si fuera de reputación —o al revés— es perder horas en la causa equivocada.

Los rechazos de autenticación que más vemos hoy

Si hoy te rebota correo legítimo hacia los grandes proveedores, lo más probable es que sea uno de tres códigos, y los tres apuntan a lo mismo: autenticación ausente o mal alineada. El 550 5.7.26 de Gmail bloquea el correo no autenticado. El 550 5.7.515 de Microsoft rechaza al remitente que no cumple los requisitos que exige desde mayo de 2025. Y el 4.7.26 —en 421 o 451— es la postergación previa, por falta de autenticación o por la política DMARC del dominio.

La traducción a tareas es directa. Publica un SPF que cubra todas tus fuentes de envío y no supere el límite de diez consultas. Firma con DKIM y comprueba que el dominio de la firma se alinea con el del remitente visible. Publica DMARC y hazlo avanzar de p=none a quarantine y reject a medida que tus informes se limpian. Tres de cada cuatro rechazos de la familia 5.7 que nos piden explicar se resuelven en ese trío, y casi siempre el fallo está en la alineación, no en la mera presencia de los registros. Lo desarrollamos en nuestra guía de por qué Gmail rechaza tus correos.

Un ejemplo real: dos rebotes, dos causas

Dos rebotes muy parecidos pueden pedir acciones opuestas. Un 550 5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM te dice exactamente qué falta: ni SPF ni DKIM se validaron y alinearon, así que la tarea es publicar y alinear esos registros, no tocar el contenido ni la lista. Un 550 5.7.515 Access denied, sender does not meet authentication requirements de Microsoft apunta a lo mismo desde otro proveedor, con un matiz: Microsoft exige además una política DMARC mínima, de modo que un dominio con SPF y DKIM pero sin DMARC publicado puede seguir rebotando aquí aunque pase en Gmail.

El método es siempre el mismo: aísla el código básico, lee el estado mejorado para situar la familia, y quédate con el texto solo para confirmar. Un envío que rebota en Microsoft con 5.7.515 y entra en Gmail no tiene «mala suerte con Microsoft»: tiene un hueco de DMARC que Gmail todavía no penaliza con la misma dureza. Leer los dos códigos juntos te ahorra tratar un único problema como si fueran dos.

Códigos de conexión y red: la familia 4.4.x

No todos los fallos son de autenticación o de buzón; algunos ocurren antes, en la propia conexión. La familia 4.4.x cubre red y enrutamiento, y conviene reconocerla porque rara vez se arregla en el contenido del mensaje. Un 4.4.2 es una conexión que se cortó a mitad de la entrega. Un 4.4.5 indica congestión o demasiadas conexiones simultáneas desde tu host —el receptor se ha quedado sin capacidad para ti en ese momento—. Un 4.4.7 señala que el mensaje esperó demasiado en cola y expiró su tiempo de entrega, y un 4.4.6, un bucle de enrutamiento por tablas mal configuradas.

La respuesta a casi toda la familia 4.4.x es la misma: dejar que el MTA reintente con intervalos crecientes y, si el 4.4.5 persiste, reducir el número de conexiones concurrentes hacia ese proveedor. Un host que abre demasiadas conexiones a la vez se castiga solo, y bajar la concurrencia suele resolver el síntoma sin tocar nada más.

La mecánica del 4xx: colas, reintentos y cuándo se rinde tu servidor

Un 4xx no rebota de inmediato: el mensaje vuelve a la cola del emisor, que lo reintentará durante una ventana de tiempo —típicamente, horas o algún día— con intervalos cada vez más largos. Si la causa se resuelve dentro de esa ventana, el correo acaba entregándose y nadie se entera. Si no, el emisor agota los reintentos y genera un rebote: ese es el momento en que un problema «temporal» se convierte, de hecho, en una no entrega. Por eso un 4xx repetido no es inofensivo. Una postergación por límite de frecuencia que no cede porque sigues enviando al mismo ritmo terminará en correo sin entregar y en una señal de mala conducta hacia el proveedor. La lectura correcta de un 4xx persistente es «afloja y corrige la causa», no «reintenta más fuerte».

Por qué los códigos pesan más que hace dos años

Durante mucho tiempo, el correo no conforme acababa en la carpeta de spam, y los códigos de rechazo eran un asunto de nicho. Eso cambió por fases: Google y Yahoo anunciaron sus requisitos en octubre de 2023, empezaron a aplicarlos en febrero de 2024, Microsoft se sumó con su enforcement en mayo de 2025 y Gmail pasó a rechazos activos a finales de 2025. El efecto acumulado es que hoy una parte del correo que antes se filtraba se devuelve con un código, y ese código es la única explicación que vas a recibir. Saber leerlo dejó de ser una habilidad de administrador para convertirse en una competencia de cualquiera que envíe a escala, porque es la diferencia entre corregir la causa en una tarde y perseguir un síntoma durante una semana.

Cómo leer un rebote real

Un rebote trae más información de la que parece. Además del código básico y el estado mejorado, suele incluir un texto que nombra el motivo y, según el proveedor, identificadores que ubican la causa. Gmail añade gsmtp a todos sus errores y gcdp cuando el rechazo viene de una regla personalizada creada por un administrador de Google Workspace, así que un 550 5.7.1 con gcdp no es un problema de tu autenticación, sino de una política del dominio receptor. Lee también el nombre del host que rechaza y la marca de tiempo: te dicen qué servidor y qué envío concreto fallaron, que es por donde empieza cualquier diagnóstico serio.

Códigos que se confunden

Algunos pares se parecen y llevan a soluciones opuestas. Un 4.2.2 es un buzón temporalmente lleno —del destinatario, no tuyo— y se resuelve solo cuando hace hueco; no toques tu configuración por él. Un 5.1.1 es una dirección que no existe y pide higiene de lista, no reputación. Un 5.7.1 es política y pide revisar autenticación y listas negras. Y un 4.4.x es red y enrutamiento —conexiones agotadas, bucles, entregas expiradas— que rara vez se arregla en el contenido del mensaje. Identificar bien la familia con el segundo dígito del estado mejorado evita gastar el esfuerzo en el sitio equivocado.

DMARCbis: lo que viene

El estándar DMARC está en revisión —el sector se refiere a la versión actualizada como DMARCbis—, y conviene tenerlo en el radar sin alarmarse. Entre sus cambios, sustituye el uso de la lista de sufijos públicos por una búsqueda en árbol para identificar el dominio organizativo, y aclara cómo se evalúan la alineación y las políticas. Para quien envía, lo esencial no cambia: SPF y DKIM válidos y alineados, una política DMARC publicada y un avance ordenado hacia reject. Quien ya tiene esa base montada y leída en sus informes llegará a DMARCbis sin sobresaltos; quien sigue en p=none «porque cumple» tendrá un motivo más para terminar el trabajo. No es una urgencia de esta semana, pero sí la dirección del viaje.

Dónde ver los códigos antes de que lleguen como rebote

Lo mejor es no esperar al rebote. Cada gran proveedor ofrece una ventana a cómo te ve, y revisarla te adelanta a los códigos. En Google, Postmaster Tools v2 muestra desde finales de 2025 un estado de cumplimiento que te dice sin rodeos si tu dominio pasa los requisitos. En Microsoft, los Smart Network Data Services y el programa de bucle de retroalimentación de quejas exponen la reputación de tus IPs y las quejas que generan. En Yahoo, el panel para remitentes y su bucle de quejas cumplen un papel parecido. Conectar estas tres fuentes y mirarlas con regularidad convierte el diagnóstico reactivo —leer rebotes cuando ya duelen— en uno preventivo, donde corriges la causa antes de que un 4.x se endurezca en un 5.x.

Lo que no debes hacer

Ante una racha de rebotes, la reacción instintiva suele empeorar las cosas. Reintentar un 5xx permanente no cambia el resultado y le repite al proveedor una señal mala. Cambiar de IP sin corregir la autenticación solo traslada el problema a una IP nueva y sin historial, que parte de cero. Bajar el volumen ayuda a la reputación, pero no resuelve un fallo de alineación: un correo no autenticado seguirá rechazándose envíes mil o cien mil. Y no existe una palanca para «pedir que te dejen pasar»: el enforcement es automático y se basa en lo que tu correo demuestra en cada conexión. Lo único que reabre la puerta es corregir lo que el código señala.

Si operas tu propio MTA

Para quien envía con su propia infraestructura de PowerMTA o KumoMTA, estos códigos no son teoría: son el lenguaje en el que el MTA decide qué hacer con cada mensaje. Un buen MTA distingue el rebote duro del transitorio, registra ambos por separado y aplica reglas de reintento por código: reintenta los 4xx con intervalos crecientes y un tope sensato, y trata los 5xx como rebote sin machacar la cola. La parte que más se descuida es el backoff: cuando un receptor responde con un 421 de límite de frecuencia, está pidiendo que aflojes, y un MTA que lo ignora golpeando la misma cola se gana el trato duro antes. Modelar el tráfico por proveedor y respetar de verdad las postergaciones es, hoy, parte de cumplir y no solo de enviar rápido. Esa es la capa en la que trabajamos, y donde leer bien los códigos se traduce directamente en entrega.

Conviene ser concreto sobre lo que «leer bien los códigos» significa en un MTA. La clasificación importa: un servidor que mete todos los 5xx en el mismo cajón no distingue una dirección inexistente —un 5.1.1, que pide retirar ese contacto de la lista— de un rechazo por reputación —un 5.7.1, que pide trabajar la IP y la autenticación—, y acaba tratando dos problemas distintos con la misma reacción. Las reglas de reintento también deben mirar el código: reintentar un 5xx desperdicia capacidad y repite una mala señal, mientras que un 4xx merece una cadena de reintentos con backoff y un tope antes de rendirse. Y conviene actuar sobre patrones, no sobre rebotes sueltos: un repunte de 4.7.26 desde un dominio concreto delata una fuente de envío que perdió la alineación, y un goteo de 5.7.515 hacia Microsoft, un DMARC que falta. Un MTA que registra el código básico, el estado mejorado y el host receptor por separado convierte esos patrones en algo consultable, y un problema de entrega en una consulta de una línea.

En resumen

Si te quedas con cuatro ideas, que sean estas. El primer dígito manda: 4xx es temporal y se reintenta, 5xx es permanente y se corrige. El segundo número del estado mejorado te lleva a la familia de la causa, y el .7 —política y seguridad— es el que más vas a ver hoy. Los tres rechazos de autenticación del momento —5.7.26, 5.7.515 y 4.7.26— se resuelven con el mismo trío de SPF, DKIM y DMARC alineados. Y un código repetido no es ruido: es la causa hablándote, así que léela antes de reenviar.

Fuentes: documentación de errores SMTP de Gmail y «Acerca de los mensajes de error de SMTP» (Google Workspace); requisitos de autenticación de Microsoft (mayo de 2025); RFC 3463 (códigos de estado mejorados); cobertura del sector, 2025–2026. Verifica el texto exacto de cada código en la documentación del proveedor.