El mensaje salió a las 09:14 y el rebote entró seis segundos después: un correo de Mail Delivery Subsystem lamentando que no pudo entregarse. La mayoría lee esa frase, se encoge de hombros y vuelve a pulsar enviar. Es justo lo que no hay que hacer, porque unas líneas más abajo, en un bloque que casi nadie despliega, está el diagnóstico exacto del servidor remoto.
Un rebote es un informe técnico legible por máquina: un código numérico, una clase de error y una frase del administrador remoto. Saber leerlo cambia la reacción correcta: a veces toca esperar, a veces limpiar la lista, y a veces parar el envío porque el problema no es la dirección, es tu reputación.
La primera cifra decide si debes reintentar
Todo se apoya en un detalle mínimo: el primer dígito de la respuesta SMTP. Un código que empieza por 4 es un fallo temporal: el servidor remoto está diciendo "ahora no puedo, vuelve más tarde". Tu servidor de salida guarda el mensaje en cola y lo reintenta solo, con intervalos crecientes. No tienes que hacer nada.
Un código que empieza por 5 es un fallo permanente. El servidor no pide paciencia, cierra la puerta. Reintentar no cambia la respuesta y suele empeorarla, porque cada intento queda registrado como tráfico rechazado desde tu dominio o tu IP. Esa distinción, 4xx contra 5xx, es la única regla que conviene memorizar sin excepciones; su equivalente comercial está en rebote duro frente a rebote suave.
Dónde está el código de verdad
El texto amable que encabeza el rebote es una reescritura del proveedor y pierde detalle. El dato útil está en el DSN, el informe estructurado que viaja adjunto en el mismo correo. Busca dos cabeceras: Status:, con el código de estado extendido en tres números separados por puntos, y Diagnostic-Code:, que reproduce literalmente la respuesta SMTP del servidor remoto.
En Gmail se llega con "Mostrar original"; en escritorio, viendo el código fuente. Si administras el envío, ese par de valores está también en el registro de tu MTA. Y antes de diagnosticar nada, confirma que la dirección estaba bien escrita: una verificación rápida de la dirección descarta la mitad de los casos.
Los códigos que vas a ver de verdad
- 550 / 5.1.1 — el buzón no existe. La dirección nunca fue válida o fue eliminada.
- 552 / 5.2.2 — buzón lleno o mensaje que supera el límite de tamaño. El 552 clásico apunta al peso del correo, adjuntos ya codificados incluidos.
- 550 / 5.7.1 — rechazo por política: reputación, fallo de SPF, DKIM o DMARC, IP en lista negra o una regla del destinatario. No depende de que la dirección exista.
- 421 — el servidor no está disponible ahora y cierra la conexión: saturación, mantenimiento o demasiadas conexiones simultáneas desde tu origen.
- 4.7.x — greylisting o límite de tasa. El destino rechaza a propósito el primer intento y acepta el segundo minutos después.
- 4.2.2 — buzón lleno, pero tratado como temporal. Si el usuario libera espacio, el mensaje entra en el siguiente reintento.
El 550 a secas es el comodín del protocolo: muchos servidores lo devuelven tanto para un buzón inexistente como para un bloqueo de política. Por eso el código extendido importa más que el numérico: 5.1.1 y 5.7.1 llegan los dos como 550 y son problemas opuestos.
Qué hacer con cada clase
Si es 4xx, no hagas nada: tu servidor reintenta solo. Interviene solo si un destinatario acumula 4xx varios días: ahí ya no es congestión, sino un buzón abandonado o un filtro que te frena en silencio.
Si es 5.1.1, tienes un problema de lista, no de entrega. Esa dirección jamás existió o dejó de existir, y ninguna configuración la va a resucitar. La corrección ocurre antes del envío: eliminarla, arreglar el error tipográfico si lo hay y validar el resto del listado. Un porcentaje alto de 5.1.1 delata datos viejos o comprados, y los filtros lo interpretan igual.
Si es 5.7.1, tienes un problema de reputación, y reintentar es contraproducente: cada intento confirma al filtro el patrón que ya le desagradaba. Toca revisar la autenticación del dominio, ver si tu IP figura en alguna lista y bajar el volumen. Nuestra guía sobre por qué los correos terminan en spam cubre esa parte.
Si es 552, comprime el adjunto, súbelo a un enlace o divide el envío. No es reputación ni lista, es aritmética.
Los dos errores que cuestan más caro
El primero es reintentar códigos 5xx. Los sistemas serios suprimen la dirección tras un rebote permanente, porque insistir es la firma de un remitente descuidado. Si tu herramienta no lo hace sola, hazlo tú.
El segundo es recargar meses después la misma lista con las direcciones que ya rebotaron en firme. Ese ciclo infla tu tasa de rebote y arrastra a spam los mensajes que sí iban a buzones reales. Mantener una supresión y comprobar las direcciones nuevas antes del primer envío evita ambos.
Preguntas frecuentes
¿Cuánto tiempo reintenta mi servidor un código 4xx?
Depende del MTA, pero lo habitual es reintentar con intervalos crecientes durante uno o varios días antes de rendirse. Al agotarse ese plazo recibes un rebote definitivo que convierte el problema temporal en permanente. Si el destinatario es importante, contáctalo por otro canal sin esperar al último aviso.
¿Un rebote 5.7.1 significa que estoy en una lista negra?
No siempre. El 5.7.1 abarca cualquier rechazo por política: fallos de DMARC, reglas internas de la empresa destinataria o límites del propio dominio. El texto del Diagnostic-Code suele señalar la causa concreta y a veces incluye una dirección web con la explicación del proveedor.
¿Puedo reenviar a una dirección que rebotó con 5.1.1 si el cliente jura que existe?
Verifica primero la escritura exacta, porque casi siempre hay una letra cambiada o un dominio mal escrito. Si la dirección es idéntica y el servidor sigue devolviendo 5.1.1, el buzón no existe del lado del destino. Pide una alternativa en lugar de insistir.
