# Soft bounce vs hard bounce: guía técnica para email URL: https://notificationharbor.com/es/journal/soft-bounce-hard-bounce-email-marketing-guia Type: blog Locale: es Published: 2026-09-22 Updated: 2026-09-22 --- > Los fallos de entrega se reducen a un dígito SMTP: 4xx reintentar, 5xx suprimir. Equivocarte erosiona tu reputación de dominio. Guía técnica completa. ## Soft bounce vs hard bounce en email marketing: la guía técnica de infraestructura Los fallos de entrega de email por soft bounce y hard bounce se reducen a un único dígito SMTP: 4xx significa "reintenta más tarde", 5xx significa "esta dirección ya no existe". Envía a una bandeja saturada y obtendrás un 4xx; el stack reintenta. Envía a una dirección inexistente y el servidor remoto devuelve un 5xx; tu lista de supresión debería actualizarse en el mismo minuto. Equivocarte en esta clasificación erosiona la reputación de tu dominio más rápido que casi cualquier otro error operacional. ## Los códigos SMTP son la única clasificación que importa Cada fallo de entrega de email reporta un código de respuesta SMTP de tres dígitos. El primer dígito es el que tu procesador de bounces debería usar para ramificar la lógica. Los códigos 4xx indican una condición transitoria: el servidor receptor aceptó la conexión, evaluó el mensaje, y decidió que no puede entregar ahora. Los códigos 5xx indican una condición permanente: el servidor receptor te dice que dejes de intentar con esta dirección completamente. Esta lógica de ramificación es de nivel de infraestructura. Tu aplicación no debería necesitar leer el texto de diagnóstico legible por humanos para decidir si suprimir; el primer dígito toma esa decisión. El segundo y tercer dígito añaden especificidad. Un 452 te dice que el buzón está lleno. Un 550 te dice que la dirección no existe. Un 421 te dice que el servidor está temporalmente no disponible. La mayoría de los clasificadores de bounces mapean estos sub-códigos a tipos de evento internos, pero la división 4/5 sigue siendo la rama principal. Si tu pipeline trata todos los 4xx como reintentables y todos los 5xx como terminales, cubrirás aproximadamente el 95% de los casos de producción correctamente. ## Qué causa un soft bounce y cuánto tiempo reintentar Los escenarios 4xx más comunes que una pipeline de email de producción encuentra, en orden aproximado de frecuencia: **Buzón lleno (452)**: La cuota del destinatario está agotada. La mayoría de los ESPs reintentan durante 24 a 72 horas antes de convertir a fallo. Este código está sobrerrepresentado en bandejas de consumidores; las direcciones B2B rara vez lo producen aisladamente. **Greylisting (451)**: El MTA receptor difiere temporalmente remitentes desconocidos como precaución antispam. Un reintento 10 a 30 minutos después usualmente funciona. Esta es una parte normal del handshake de primer envío en un dominio o IP nuevos, no es señal de problemas de calidad de lista por sí sola. **Servidor temporalmente no disponible (421)**: El servidor remoto está caído, rate-limiting, o sobrecargado. Reintenta con backoff exponencial. La mayoría de servidores se recuperan en pocas horas; si esto persiste durante varios días para el mismo dominio, el dominio en sí puede estar en problemas. **Mensaje demasiado grande (552/554 variante soft)**: El email excede el límite de tamaño del servidor para este buzón. Reintentar sin reducir el tamaño de payload siempre fallará; enruta esto a una cola de manejo separada y alerta al remitente. ![Email envelope deflecting off a metallic surface, representing a soft bounce event](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/788605-image-inline1.webp) Las ventanas de reintento estándar en producción: primer reintento después de 5 minutos, luego 30 minutos, luego 2 horas, luego 6 horas, luego 24 horas. Después de 5 días sin entrega exitosa, la convención SMTP es generar un reporte de no entrega (NDR) y devolver el mensaje al remitente. Si tu ESP se adhiere a esa ventana de 5 días o la acorta es algo que vale la pena verificar en tu configuración. Una métrica que vale la pena rastrear: la proporción de soft bounces que se resuelven en el primer reintento versus aquellos que requieren más de tres intentos. Una lista saludable verá la mayoría de códigos 452 y 421 resolverse dentro de dos reintentos. Alta persistencia en muchos ciclos de reintento es una señal que vale la pena investigar a nivel de segmento. ## Los tres modos de hard bounce que tu pipeline verá Los códigos 5xx no son monolíticos. Los sub-códigos te dicen cosas diferentes sobre qué hacer después de suprimir. **Dirección inexistente (550/551)**: El dominio es válido pero la parte local no mapea a un buzón real. Este es el hard bounce más común en productos dirigidos al consumidor: typos en signup, cuentas abandonadas, direcciones que eran válidas hace seis meses y luego se eliminaron. Suprime inmediatamente. No hay ruta de recuperación. **Dominio no existe o no acepta correo (550/553/554)**: La búsqueda del registro MX falló, o el dominio explícitamente rechaza todo correo entrante. Suprime a nivel de dominio, no solo la dirección. Cualquier otro contacto en ese dominio es igualmente inalcanzable, y una consulta a nivel de dominio los surfacerá más rápido que esperar a que cada uno rebote individualmente. **Bloqueado permanentemente por política (550/5.7.1)**: El servidor receptor tiene un bloqueo a nivel de política contra tu dominio o IP de envío. Esto es más raro pero operacionalmente más serio porque puede afectar una clase de direcciones en toda una organización. Haz referencia cruzada con tus logs de reputación de IP antes de decidir si suprimir solo la dirección disparadora o escalar a tu equipo de deliverability. ![Abstract network routing paths diverging, one path connected, one returning as a bounce](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/6b5951-image-inline2.webp) Una matiz que causa bugs en producción: algunos MTAs devuelven códigos 4xx para condiciones que son efectivamente permanentes. Un dominio que ha expirado y ha sido aparcado puede devolver 450 en lugar de 550 durante semanas mientras el registrador lentamente desactiva el registro MX. Tu pipeline debería tratar cualquier dirección que devuelva 4xx en cinco intentos consecutivos durante dos semanas como candidato para estado de hard-bounce, independientemente del prefijo SMTP. ## Cuándo los soft bounces se vuelven funcionalmente permanentes El límite de categoría limpio entre 4xx y 5xx no se mantiene bajo condiciones de producción. Tres patrones deberían desencadenar la misma lógica de supresión que un hard bounce incluso cuando el código permanece en el rango 4xx. Primero: **bounces repetidos de buzón lleno con cero engagement previo**. Si una dirección nunca ha abierto, nunca ha clickado, y ha rebotado 452 cinco veces en los últimos 30 días, el buzón está casi ciertamente abandonado. Continuar intentando entrega incrementa tu bounce rate sin ninguna oportunidad realista de activación. Trata esto como hard. Segundo: **greylisting persistente sin resolución**. El greylisting se resuelve en reintento para remitentes legítimos. Si la misma dirección consistentemente se retrasa más allá de 48 horas, estás en una lista negra o enviando a una spam trap. Ninguno de los dos casos justifica intentos continuados; los ciclos de reintento componen el daño de reputación. Tercero: **códigos 4xx que aparecen solo para tu dominio de envío**. Si otros remitentes llegan exitosamente a la misma dirección pero tus envíos consistentemente se difieren, el problema es reputación del remitente, no estado del buzón. Reintentar más agresivamente lo empeora. La regla operacional a codificar: después de tres soft bounces sin resolución, mueve la dirección a un estado de supresión probatoria. Detén el envío de emails de lifecycle a ella. Mantén la elegibilidad para email transaccional crítico (reset de contraseña, alerta de facturación) hasta que hayas confirmado que es verdaderamente inalcanzable. ## Lógica de supresión: Eliminar vs. Estacionar vs. Reintentar No cada evento de bounce garantiza eliminación completa de tu tienda de contactos. La llamada correcta depende del tipo de bounce y del historial de engagement previo del contacto. **5xx hard bounce (cualquier engagement previo)** -- Supresión inmediata, sin reintentos. **4xx, primera ocurrencia (engagement activo)** -- Reintenta por horario, sin supresión. **4xx, tres o más ocurrencias (sin engagement previo)** -- Supresión probatoria. **4xx, cinco o más ocurrencias (cualquier engagement)** -- Trata como hard bounce. **4xx buzón lleno solo (LTV alto o transaccional)** -- Reintenta semanalmente durante 30 días. La distinción entre "eliminar" y "estacionar" importa en práctica. Una dirección eliminada cae completamente de tu tienda de contactos. Una dirección estacionada permanece con estado suprimido: aún puedes consultarla, surfacearla en un dashboard de salud, y reactivarla si el contacto se vuelve a conectar a través de un nuevo envío de formulario. Para flows transaccionales de alto valor, estacionar es la llamada correcta. Para listas de alcance frío, eliminación es más limpio. Un punto operacional que vale la pena forzar en código: cualquier acción que tomes debería ser registrada con el código SMTP y timestamp como la razón de supresión. Eventos de supresión sin razones explícitas son casi imposibles de auditar después cuando quieres entender por qué una cohorte de direcciones oscureció entre dos campañas. ## Umbrales de bounce rate que cambian el comportamiento del ISP La cifra de bounce rate del 2% total que circula como benchmark de industria es un piso, no un objetivo. Los umbrales reales que importan son más granulares. Gmail y Outlook reportan spam rates a nivel de remitente a través de Google Postmaster Tools y Microsoft SNDS respectivamente. Esos dashboards no exponen directamente tu bounce rate, pero los dos señales correlacionan estrechamente. Un bounce rate sostenido por encima del 2% casi siempre precede un aumento en spam placement rate visible en esas herramientas, típicamente con lag de 3 a 5 días. Umbrales prácticos a monitorear por dominio de envío: - **Por debajo del 0.5%**: Rango normal. No se requiere acción correctiva. - **0.5 a 1.5%**: Monitorea de cerca. Investiga razones de bounce por segmento; usualmente pocas cohortes con calidad de datos degradada. - **1.5 a 2.5%**: Pausa la campaña e investiga antes de reanudar. La mayoría de ESPs comienzan rate-limiting automatizado en este rango. - **Por encima del 2.5%**: Detén el envío. Limpia los segmentos afectados antes de reiniciar. A este nivel, algunos ISPs ya han comenzado a filtrar mensajes a spam o a diferir conexiones en el gateway. ![Engineer monitoring email delivery metrics on multiple screens in a server operations center](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/bc5931-image-inline3.webp) Un detalle operacional que se pasa por alto: los bounce rates se calculan contra intentos de entrega, no tamaño de lista total. Si segmentas fuertemente y envías solo a suscriptores engaged, tu conteo de bounces absoluto cae pero la tasa calculada puede no cambiar proporcionalmente. Rastrear tanto conteo absoluto como tasa por envío. Picos en conteo absoluto son frecuentemente la señal de alerta más temprana, especialmente después de un import de lista o una campaña de re-engagement. ## Leyendo señales de bounce en tu delivery trace Los eventos de bounce deberían aparecer en tu delivery trace con la misma fidelidad que opens y clicks. Si no lo hacen, tu setup de observabilidad tiene un gap. Como mínimo, cada evento de bounce debería registrar: timestamp, código de respuesta SMTP, mensaje de diagnóstico completo del servidor remoto, IP de envío, dominio receptor, e ID de contacto. El dominio receptor es frecuentemente omitido y frecuentemente necesario. Cuando un dominio comienza a devolver 550 5.7.1 en múltiples contactos, quieres detectar ese patrón a nivel de dominio antes de que dañe tu score de reputación a través de todo el dominio de envío. Con esos datos modelados correctamente, tres vistas cubren la mayoría de necesidades de monitoreo de bounce: una tasa diaria de bounce por dominio de envío, una tasa de conversión soft-a-hard por cohorte (cuántos de los eventos 4xx de hoy seguirán rebotando en 10 días), y una tabla de frecuencia de bounce a nivel de dominio para atrapar supresiones organizacionales antes de que se compongan. El objetivo no es una bounce rate cero. Eso no es alcanzable en una lista que crece. El objetivo es una pipeline de procesamiento de bounces que clasifique con precisión en la primera respuesta SMTP, suprima al umbral correcto, y surfaces los señales que indican un problema sistémico antes de que escale en un incidente de deliverability. ## FAQ ### ¿Cuál es la diferencia principal entre soft bounce y hard bounce? Los soft bounces devuelven código SMTP 4xx (condición temporal: buzón lleno, servidor no disponible) y son reintentables. Los hard bounces devuelven 5xx (condición permanente: dirección no existe, dominio inválido) y requieren supresión inmediata. ### ¿Cuántas veces debería reintentar un soft bounce? La mayoría de ESPs siguen este esquema: reintentos en 5 min, 30 min, 2h, 6h y 24h. Después de 5 días sin entrega, se genera un NDR. Las direcciones con persistencia de 4xx sin resolución tras 3 intentos deben tratarse como hard bounce. ### ¿A qué bounce rate debo preocuparme? Por debajo de 0.5% es normal. Entre 0.5-1.5% investiga por segmento. Entre 1.5-2.5% pausa y revisa. Por encima de 2.5% detén el envío: los ISPs comienzan a filtrar a spam e incrementan la latencia del gateway. ### ¿Debo eliminar o estacionar direcciones que bounced? Elimina los hard bounces (5xx). Para soft bounces, estaciona (marca como suprimida pero mantenla en BD) si el LTV es alto o es email transaccional; esto permite reactivación si el contacto se reenganche. ### ¿Qué es el greylisting y cómo afecta mis reintentos? El greylisting es una defensa antispam que rechaza temporalmente (451) el primer envío de un remitente desconocido. Un reintento 10-30 minutos después usualmente funciona. Es normal en primeros envíos desde dominios o IPs nuevas. ### ¿Cómo monitoreo la salud de bounces en mi infraestructura? Registra timestamp, código SMTP, mensaje diagnóstico completo, IP de envío, dominio receptor e ID de contacto. Monitorea: tasa diaria por dominio, conversión soft-a-hard por cohorte, y frecuencia a nivel de dominio.