Gmail devuelve el mismo buzón lleno con dos códigos opuestos: un 452 4.2.2 temporal y un 552 5.2.2 definitivo cuando, además, la cuenta está inactiva (documentación de Google Workspace, consultada en octubre de 2026). El primero es un soft bounce y el segundo un hard bounce, para un mismo buzón lleno según esté activo o inactivo. Un hard bounce (rebote duro) es un rechazo permanente: el mensaje no se entregará mientras no cambie la dirección o el mensaje. Un soft bounce (rebote blando) es un fallo temporal que el proveedor de envío reintenta. Regla de baja: elimine la dirección al primer hard bounce y retírela al tercer soft bounce consecutivo, en 3 envíos repartidos en al menos 14 días. A continuación se desmenuza un NDR línea por línea y cada umbral numérico se enlaza con su fuente.
Hard bounce y soft bounce: comparación punto por punto
| Criterio | Hard bounce | Soft bounce |
|---|---|---|
| Código SMTP | 5yz (550, 552) | 4yz (421, 450, 451, 452) |
| Enhanced status code | 5.x.x, por ejemplo 5.1.1 | 4.x.x, por ejemplo 4.2.2 |
| Causas habituales | dirección inexistente, dominio inexistente, cuenta desactivada, rechazo por política | buzón lleno, servidor no disponible, límite de velocidad, greylisting |
| Plazo de la señal | inmediato, durante la sesión SMTP (o NDR diferido, ver más abajo) | también inmediato; el rebote solo se declara cuando el proveedor de envío abandona los reintentos |
| Reintento | ninguno: el cliente no debería repetir la misma solicitud | sí: intervalo recomendado de al menos 30 minutos, abandono como pronto a los 4 o 5 días |
| Acción | baja inmediata (salvo la familia 5.7.x) | recuento por envío, baja al tercer rebote consecutivo |
Los valores de la fila «Reintento» proceden de la RFC 5321 (secciones 4.2.1 y 4.5.4.1). Después, cada proveedor fija su propio plazo de abandono, que figura en su documentación.
¿Qué códigos SMTP separan un hard bounce de un soft bounce?
Un código 4xx anuncia un fallo temporal (soft bounce) y un código 5xx un fallo permanente (hard bounce): el primer dígito de la respuesta SMTP fija la clase.
El detalle está en el enhanced status code, definido por la RFC 3463 (enero de 2003). Consta de tres campos separados por puntos: clase, asunto, detalle. La clase vale 2 (éxito), 4 (fallo temporal persistente) o 5 (fallo permanente). El asunto señala la zona afectada. El 1 apunta a la dirección, el 2 al buzón, el 3 al sistema de correo, el 4 a la red, el 5 al protocolo, el 6 al contenido y el 7 a la seguridad y la política.
El código 5.1.1 se lee así: fallo permanente (5), problema de dirección (1), parte izquierda de la arroba no válida (1). La RFC reserva este código para fallos permanentes. El catálogo completo de respuestas está en la guía de códigos de respuesta SMTP. El detalle de los casos 550 5.4.1 y 552 se lee, uno por uno, en los códigos de error SMTP.
Leer un NDR línea por línea: el ejemplo del 550 5.1.1
El NDR (non-delivery report) es un mensaje en formato DSN, descrito en la RFC 3464, que se devuelve al remitente. El ejemplo siguiente es una reconstrucción: los campos siguen la RFC 3464 y el diagnóstico reproduce el texto que Google documenta para el 550 5.1.1. Las direcciones y el host remitente son ficticios.
Reporting-MTA: dns; smtp.ejemplo.es
Final-Recipient: rfc822; nombre.apellido@gmail.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.
Reporting-MTAnombra el servidor que redacta el informe: aquí, su proveedor de envío.Final-Recipientda la dirección fallida. Es la clave para cruzarla con su lista.Action: failedindica que la entrega ha fallado de forma definitiva.Status: 5.1.1es el enhanced status code: el 5 clasifica el fallo como permanente y el 1.1 señala un buzón inexistente.Remote-MTAidentifica el servidor que ha rechazado el mensaje, aquí la entrada MX de Gmail.Diagnostic-Codecopia la respuesta bruta del servidor: el 550 de la capa SMTP, luego el 5.1.1 y por último el texto legible. Google recomienda comprobar si hay una errata o un espacio de más.
El mismo informe para un buzón que se está llenando cambia tres líneas, según el texto de Google para el 452 4.2.2:
Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 The recipient's inbox is out of storage space.
El informe delayed avisa de que el proveedor sigue reintentando. Hay un detalle que cambia cómo se lee un panel de control. Una notificación final puede mostrar Action: failed con un Status: 4.2.2. La RFC 3463 define la clase 4 como una condición temporal que ha provocado el abandono o el retraso del envío. El proveedor ha desistido tras sus intentos, sin rechazo definitivo del servidor. Este caso se clasifica como soft bounce agotado.
Tabla de decisión: del código a la acción
Las descripciones proceden de la documentación de Google Workspace sobre los errores SMTP de Gmail y de las definiciones de la RFC 3463.
| Código | Causa | Tipo | Acción |
|---|---|---|---|
| 550 5.1.1 | el buzón no existe | hard | baja inmediata |
| 5.1.2 | dominio inexistente o incapaz de recibir correo | hard | baja inmediata, revisar si hubo una errata en el dominio al captar el dato |
| 5.2.1 | buzón desactivado | hard, a veces temporal según la RFC | baja inmediata |
| 552 5.2.2 | buzón lleno e inactivo (redacción de Gmail) | hard | baja inmediata |
| 452 4.2.2 | buzón lleno | soft | recuento por envío, baja al tercer rebote |
| 4.4.x | red o enrutamiento, por ejemplo sin respuesta del host o tiempo agotado | soft | recuento por envío |
| 4.7.x | rechazo temporal por política (el greylisting es un caso habitual, fuera de la RFC) | soft | esperar al segundo intento, sin baja |
| 550 5.7.1 o 5.7.26 | política del destinatario o autenticación ausente | hard por su clase | conservar el contacto, corregir el envío |
La última fila es la más costosa de interpretar mal. Según Google, un 5.7.26 significa que el mensaje se bloquea por falta de autenticación (SPF o DKIM) o porque la política DMARC del dominio lo rechaza. La dirección es válida: es su dominio el que falla. Eliminar esos contactos vacía la lista sin resolver la causa. El greylisting corresponde a la fila 4.7.x: el servidor rechaza a propósito el primer intento de un remitente desconocido. El segundo pasa.
Bounce síncrono y asíncrono: cuándo llega el rechazo
Un rechazo síncrono se produce durante la sesión SMTP. El servidor responde 550 5.1.1 al comando RCPT TO (o al final de DATA): su proveedor de envío conoce el resultado antes de cerrar la conexión y no hay ningún NDR que esperar.
El bounce asíncrono sigue otro camino. El servidor responde primero 250 y se hace cargo del mensaje. Si la entrega falla después, internamente, la RFC 5321 (sección 6.1) le obliga a redactar una notificación. Se envía a la dirección de retorno con remitente vacío: el comando MAIL FROM contiene entonces <> (sección 3.6.3), lo que evita los bucles de notificaciones. Ese NDR aterriza en el buzón de rebotes de su dominio, a veces varios días después del envío, en el formato DSN descrito más arriba. Para su lista, la consecuencia es directa: un rebote asíncrono no aparece en el resumen inmediato del envío. Se asocia a la dirección mediante el campo Final-Recipient y luego sigue las mismas reglas que un rechazo síncrono: hard bounce, baja inmediata. Un proveedor que no lee ese buzón de retorno deja esas direcciones en circulación e infla la tasa de rebote de la campaña siguiente.
Según su configuración, los dominios catch-all producen este segundo caso: aceptan cualquier dirección durante la sesión SMTP y clasifican el correo después. Una dirección inexistente puede acabar en un NDR diferido o desaparecer sin respuesta alguna. Ningún código recibido durante la sesión permite anticiparlo. Por eso, no dé por cerrada la tasa de rebote de una campaña hasta que pase la ventana de abandono de su proveedor. Trate también el silencio de un dominio catch-all como información incompleta. Los correos no entregados reúnen estos casos límite, con la forma de clasificarlos.
Trampas de lectura: el 5xx que se conserva y la caché de supresión
El primer dígito clasifica el rebote y no dice nada sobre la validez de la dirección. Las familias 5.7.x descritas más arriba llevan a menudo un 5 sobre contactos válidos.
Hay otras dos trampas que falsean la lectura. La respuesta automática demuestra que el mensaje llegó al buzón: no cuenta como rebote. Clasificarla como soft bounce sacaría de la lista a un contacto activo. La caché de supresión actúa en sentido contrario: una dirección incluida en la lista de supresión interna del proveedor ya no recibe envíos, aunque el buzón se haya recreado entretanto. Un contacto que jura no recibir nada con una dirección válida se busca primero en esa lista. El mismo reflejo sirve tras corregir una errata: la dirección nueva es desconocida para el proveedor y pasa. La antigua, mal escrita, sigue suprimida. Nunca volverá a salir de una exportación de rebotes. Cruce, pues, las dos filas antes de concluir que se ha perdido un contacto.
Regla de baja: cuántos envíos y en qué plazo
Para un hard bounce, el plazo es cero. Klaviyo elimina estos perfiles automáticamente. Mailchimp depura la dirección de la audiencia (páginas de ayuda consultadas en octubre de 2026). Los 5.7.x son la excepción: apuntan a su configuración. Una errata al captar el dato se corrige en origen, con doble opt-in.
Para un soft bounce, aplique cuatro reglas:
- Cuente un rebote por envío. Los intentos de un mismo proveedor, repartidos en varios días, cuentan como uno solo.
- Retire la dirección al tercer soft bounce consecutivo, en envíos distintos.
- Aconsejamos al menos 14 días entre el primer y el tercer rebote, para distinguir un buzón fuera de servicio de forma duradera de una avería pasajera en el destinatario. Este plazo es una decisión editorial: ninguna norma lo impone.
- Ponga el contador a cero en cuanto un envío se entregue.
Ejemplo: una dirección con 452 4.2.2 en las campañas del 2 y del 9 de octubre y después del 23 sale de la lista el 23. Con tres campañas enviadas del 2 al 4 de octubre, se queda: tres rebotes en 2 días son una sola avería y la dirección aún no ha superado los 14 días exigidos.
Esta regla de baja es una recomendación editorial. Los proveedores publican umbrales distintos. MailerLite indica en su guía de bounces que una dirección que rebota 3 veces seguidas se convierte en hard bounce y pasa a inactiva. Mailchimp convierte un soft bounce en hard bounce tras 7 rebotes en una dirección sin actividad de suscriptor. Para un contacto con actividad previa, el límite sube a 15. Después la dirección se depura (ayuda oficial de Mailchimp, consultada en octubre de 2026). Klaviyo aplica un umbral más alto: según su página de ayuda «Suppressed profiles» (actualizada el 30 de marzo de 2026), el perfil se elimina tras más de 7 soft bounces consecutivos. Solo cuentan los de los 2 últimos años. Una misma dirección puede, por tanto, sobrevivir a 7 rebotes en una herramienta y salir al tercero en la otra. En un proveedor permisivo, saque usted mismo la dirección con un segmento de exclusión.
La duración depende también de su ritmo de envío. El recuento se hace por envío: una campaña semanal alcanza el tercer rebote en 3 semanas y una mensual en 3 meses. Una frecuencia demasiado baja retrasa, pues, la baja: con un envío al mes, una dirección muerta se queda en la lista un trimestre.
Umbrales de bounce: qué mide cada porcentaje
Los umbrales que conviene recordar son el 2 % y el 5 % para los rebotes, y el 0,3 % para el spam denunciado. No miden lo mismo.
La primera, 2 %, es una referencia del sector para la tasa de rebote (MailerLite). La segunda, 5 %, es un límite contractual: la política antispam de MailerLite se reserva el derecho de suspender una cuenta e investigar por encima del 5 % de bounces o del 0,2 % de quejas.
La tercera, 0,3 %, viene de Google y se refiere a otra cosa: la tasa de spam que muestra Postmaster Tools, es decir, la proporción de mensajes que los destinatarios marcan como no deseados. Desde el 1 de febrero de 2024, todos los remitentes hacia Gmail deben mantenerla por debajo del 0,3 %. Google recomienda no pasar del 0,10 %.
Rebote y denuncia son dos medidas distintas: el proveedor cuenta las primeras y Postmaster Tools las segundas. Una lista puede mostrar un 1,5 % de bounces, por debajo del 2 %, con un 0,05 % de spam y no cruzar ningún umbral. También ocurre lo contrario: un 0,4 % de spam con un 0,2 % de bounces supera la regla de Google. El umbral del 2 % se aplica a la media de una campaña: en 10 000 envíos son 200 rebotes en total. Basta una sola oleada de hard bounces en una lista antigua para superarlo. Para bajar una tasa de rebote alta por debajo de la referencia del 2 %, véase la gestión de la tasa de rebote.
Bounces, reputación del remitente y listas de bloqueo
Un envío a una lista antigua hace aflorar 5.1.1 en el informe de campaña. Cada 5.1.1 demuestra que una dirección se captó y nunca se volvió a verificar: el informe de campaña hace entonces el inventario de lo que la lista ha perdido desde la captación. Para leer la tendencia, compare el número de 5.1.1 por envío en tres campañas sucesivas. Una curva ascendente señala una lista que envejece; una curva plana, un problema puntual de importación. El seguimiento pasa por Postmaster Tools en Gmail (allí la tasa de spam se compara con el tope del 0,3 %) y por el seguimiento del Sender Score para la nota de la dirección IP.
En una IP nueva en calentamiento, cada 5.1.1 pesa más: Google pide empezar con destinatarios comprometidos, lo que contradice una lista sin depurar. El método se describe en el calentamiento de una IP.
Las spam traps (direcciones trampa) se esconden en listas antiguas o compradas y pueden llevar a las listas de bloqueo. Las trampas de spam y honeypots se explican aparte. Una vez en Spamhaus u otra lista, la salida pasa por una solicitud al gestor, cuyos pasos se describen para salir de una lista de bloqueo. La clasificación de listas de bloqueo que vigilar o ignorar indica cuáles merecen una alerta.
Causas de fondo que se tratan desde la captación
Las listas compradas concentran direcciones inválidas y trampas: el primer envío produce un pico de hard bounces y, con él, una tasa de rebote que supera todas las referencias. El doble opt-in elimina las erratas y los correos falsos al registrarse. Un nombre de dominio caducado o sin registro MX produce un 5.1.2. Los rechazos 5.7.x de autenticación se resuelven en SPF, DKIM y DMARC, cuya versión DKIM2, en proceso de normalización en el grupo de trabajo DKIM del IETF (datatracker.ietf.org, consultado en octubre de 2026), busca mejorar el valor de las notificaciones de no entrega. Un contenido o un asunto de correo considerado sospechoso provoca el mismo tipo de rechazo por política, sin que la dirección tenga culpa alguna.
Preguntas frecuentes sobre los rebotes
¿Hay que eliminar una dirección tras un solo soft bounce?
No. Un soft bounce aislado suele deberse a un buzón lleno o a una avería pasajera. Cuéntelo en su regla: baja al tercer rebote consecutivo en envíos repartidos en al menos 14 días. El contador vuelve a cero en cuanto se entrega un mensaje.
¿Puede un hard bounce volver a ser válido?
Sí, en casos poco frecuentes: buzón recreado o errata corregida. El proveedor mantiene la dirección en supresión y ya no lo intenta. Sáquela de esa lista caso por caso, con la confirmación del contacto.
¿Cuánto tiempo reintenta un proveedor un soft bounce?
La RFC 5321 recomienda al menos 30 minutos entre dos intentos y un plazo de abandono de al menos 4 o 5 días. Cada proveedor aplica el suyo: compruébelo en su documentación antes de calcular una tasa de rebote final.
Verificar la lista antes del envío
Filtrar a posteriori equivale a enviar una vez a cada dirección muerta: el hard bounce ya está contado en la campaña cuando el proveedor elimina el perfil. La verificación previa retira esas direcciones antes del primer envío. Un verificador comprueba el dominio y la existencia del buzón: exactamente lo que el 5.1.1 y el 5.1.2 sancionan después. Las herramientas de verificación de correos se comparan en una guía. El mantenimiento regular de una base de datos limpia evita que la lista vuelva a perder lo ganado.
Antes de su próxima campaña, pase una muestra de la lista por la herramienta de verificación de listas de correo de CaptainVerify y compare el resultado con su tasa de hard bounce actual.
