Rebote duro vs. rebote suave: códigos, reglas y qué hace cada ESP

Un rebote duro (hard bounce) es una falla de entrega permanente: la dirección no existe o el servidor receptor rechazó el mensaje para siempre. Un rebote suave (soft bounce) es una falla temporal: el buzón está lleno, el servidor está ocupado o la entrega se aplazó. Los rebotes duros deben suprimirse desde el primero. Los suaves deben reintentarse, y suprimirse solo si siguen ocurriendo.

La forma fiable de distinguirlos es el código SMTP del rebote, no la etiqueta que le pone tu plataforma. Las tablas de abajo relacionan los códigos comunes con cada tipo y enlazan a nuestra explicación de cada código. Puedes buscar cualquier código en el directorio de códigos SMTP, que marca los comunes como duro, suave o bloqueo, y si estás viendo rebotes duros, el verificador de correo individual gratuito muestra si una dirección todavía existe antes de volver a enviarle.

Las definiciones, según el estándar

Dos números en un mensaje de rebote te dicen qué pasó. Primero viene la respuesta SMTP de tres dígitos (550, 452) y luego el código de estado extendido (5.1.1, 4.2.2) definido en el RFC 3463.

El primer dígito del código extendido es la clase. El RFC 3463 define dos clases de falla:

• 4.x.x, "Persistent Transient Failure" (falla transitoria persistente): el mensaje era válido, pero una condición temporal impidió la entrega. "Sending in the future may be successful." (Un envío futuro puede tener éxito).
• 5.x.x, "Permanent Failure" (falla permanente): "not likely to be resolved by resending the message in the current form" (es poco probable que se resuelva reenviando el mensaje en su forma actual).

Eso corresponde directamente a suave y duro. El segundo dígito, el asunto, te dice qué falló:

Asunto	Significado (RFC 3463)	Quién suele tener que actuar
X.1.X	Estado de la dirección	El remitente: la dirección está mal
X.2.X	Estado del buzón	El destinatario: su buzón tiene un problema
X.3.X	Estado del sistema de correo	El administrador del sistema receptor
X.4.X	Estado de red y enrutamiento	La red de cualquiera de los dos lados
X.7.X	Estado de seguridad o política	El remitente: reputación, autenticación o contenido

El asunto importa tanto como la clase. Un 5.1.1 y un 5.7.1 son ambos permanentes, pero el primero significa que la dirección no existe y el segundo que el servidor te rechazó a ti. Tratarlos igual o borra direcciones buenas o esconde un problema de envío.

Rebotes duros, por código

Código	Qué significa	Qué hacer
550 5.1.1	El buzón no existe	Suprimir de inmediato
550 5.2.1	Buzón desactivado, no acepta mensajes	Suprimir; el RFC 3463 indica que puede ser permanente o temporal, pero las cuentas desactivadas rara vez vuelven
550 5.4.1	Dirección del destinatario rechazada, acceso denegado	Normalmente una dirección inexistente en dominios alojados en Microsoft; suprimir
550 5.7.1	Rechazado por política	No suprimir por una sola vez; revisa reputación y autenticación
554 5.7.1	Rechazado como spam	Un problema de contenido o reputación, no de la dirección
571 5.7.1	Entrega no autorizada	A menudo una lista de permitidos o un bloqueo del lado del destinatario

Solo los tres primeros son fallas reales de la dirección. Los códigos 5.7.x son rechazos permanentes de un mensaje concreto de un remitente concreto, y la misma dirección puede aceptar correo de otra persona. Las plataformas los clasifican de forma distinta: HubSpot, por ejemplo, incluye "Content", "Spam" y "Policy" junto a "Unknown user" entre los motivos de rebote duro (base de conocimientos de HubSpot). Si tu plataforma cuenta los bloqueos por política como rebotes duros, tu lista parece peor de lo que es y tu configuración de envío parece mejor de lo que es.

Rebotes suaves, por código

Código	Qué significa	Qué hacer
450 4.2.1	Buzón temporalmente no disponible	Reintentar
452 4.2.2	Buzón lleno	Reintentar; suprimir si persiste entre envíos
552 5.2.2	Buzón lleno, devuelto como permanente	Tratarlo como suave al principio; suprimir si se repite
421 4.7.0	Aplazado, inténtalo más tarde	Reintentar y bajar la velocidad; suele ser limitación de velocidad o reputación
451 4.3.0	Error local temporal	Reintentar

La fila del buzón lleno muestra por qué hay que leer los códigos y no solo contarlos. El RFC 3463 dice que el código de buzón lleno X.2.2 "should be used as a persistent transient failure" (debe usarse como falla transitoria persistente), pero los servidores suelen devolverlo como 552 5.2.2, de clase permanente. Algunas plataformas toman la postura contraria y tratan los buzones llenos a largo plazo como muertos: entre los motivos de rebote duro de HubSpot está "Mailbox full" para una bandeja inactiva o por encima de su cuota durante mucho tiempo.

Los aplazamientos 4.7.x también son distintos de los demás. No dicen nada sobre la dirección. Significan que el servidor receptor te está limitando, y reintentar más rápido lo empeora.

Cómo los maneja cada plataforma

Todas las plataformas suprimen los rebotes duros. Las diferencias están en la rapidez y en cuántos rebotes suaves permiten antes de dar una dirección por muerta. Cada fila viene de la página de ayuda del propio proveedor, leída el 8 de octubre de 2026.

Plataforma	Rebote duro	Límite de rebotes suaves	Fuente
Mailchimp	La dirección se limpia y se excluye de envíos futuros	7 rebotes suaves sin actividad del suscriptor; hasta 15 con actividad previa, y luego se convierte en rebote duro	Ayuda de Mailchimp
Klaviyo	"Automatically suppresses any email address that hard bounces" (suprime automáticamente cualquier dirección con rebote duro)	Se suprime tras "more than 7 consecutive" (más de 7 consecutivos) rebotes suaves; solo cuentan los últimos 2 años	Ayuda de Klaviyo
Brevo	Va a la lista de bloqueo	A la lista de bloqueo tras 5 rebotes suaves consecutivos en campañas; no se aplica al correo transaccional	Ayuda de Brevo
HubSpot	Se excluye de correos futuros; un rebote duro en 3 o más cuentas de HubSpot se convierte en un "global bounce" (rebote global) suprimido en todas partes	No indica límite; los contactos con rebote suave "are eligible to receive future emails" (pueden recibir correos futuros). Los rebotes pendientes se reintentan hasta 72 horas	Base de conocimientos de HubSpot
Constant Contact	"Non-Existent" (inexistente); una dirección que rebota así repetidamente en cualquier cuenta de Constant Contact pasa a "Suspended" (suspendida)	"Undeliverable" (no entregable) se reintenta hasta tres días; no indica un número de supresión	Base de conocimientos de Constant Contact

Destacan tres cosas.

Los conteos son por envío, no por día. Los siete rebotes suaves de Mailchimp tardan siete semanas en un boletín semanal y más de medio año en uno mensual. Un buzón abandonado se queda mucho tiempo en una lista mensual.

La supresión compartida es común. El rebote global de HubSpot y el estado "Suspended" de Constant Contact usan los envíos de otros clientes. Una dirección puede quedar suprimida en tu cuenta antes de que le hayas enviado nada, una de las razones por las que las listas importadas muestran menos envíos que contactos.

Los flujos transaccionales suelen quedar exentos. La regla de rebotes suaves de Brevo solo se aplica a campañas. Si envías recibos y restablecimientos de contraseña por la misma plataforma, una dirección con rebotes suaves puede seguir recibiéndolos.

Para las plataformas transaccionales (SendGrid, Mailgun, Amazon SES y Postmark) y cuánto reintenta cada una dentro de un mismo envío, consulta cómo manejar los rebotes suaves. Amazon SES además solo cuenta los rebotes duros para su tasa de rebote, así que allí los rebotes suaves afectan la entrega pero no la cifra que dispara una revisión.

¿Qué tipo cuenta para tu tasa de rebote?

Normalmente los rebotes duros, pero compruébalo. La mayoría de los umbrales de control se definen como tasas de rebote duro: tanto el 2% de Brevo como el 5% de HubSpot lo son. Algunos paneles muestran una cifra combinada que incluye los rebotes suaves y, en el caso de Constant Contact, las respuestas automáticas que en realidad sí se entregaron. Antes de comparar tu número con cualquier umbral, averigua qué rebotes cuenta tu plataforma. Los umbrales están en límites de tasa de rebote por plataforma, y la fórmula en cómo calcular la tasa de rebote.

Una política simple que puedes aplicar

1. Suprime 5.1.x y 5.2.1 desde el primer rebote. Son fallas de la dirección. Volver a enviar solo aumenta tu conteo de rebotes duros.
2. No suprimas 5.7.x por un solo rebote. Busca un patrón por dominio receptor. Si un proveedor lo rechaza todo, el problema es tu reputación o tu autenticación, no las direcciones. Nuestra guía de mensajes de rebote de los proveedores descifra los textos que usan Gmail, Microsoft y Yahoo.
3. Reintenta los códigos de buzón 4.x.x y suprime tras tres a cinco envíos consecutivos con el mismo código. Es más estricto que Mailchimp y Klaviyo, y está en línea con Brevo. Es nuestra recomendación, no un estándar.
4. Trata los aplazamientos 4.7.x como un problema de envío. Baja la velocidad, revisa tu estado en listas negras y no elimines las direcciones.
5. Verifica antes de importar. Una lista a la que nunca se le ha enviado no tiene historial de rebotes, y las plataformas con supresión compartida pueden contar igualmente sus direcciones muertas en tu contra. Revisarla primero encuentra los buzones inexistentes antes de que se conviertan en rebotes duros.

Las etiquetas "duro" y "suave" son un resumen. El código de debajo te dice si el problema es la dirección, el buzón o tú, y cada caso necesita una solución distinta.