Anatomía de un rebote: soft vs hard, qué los causa y cómo reaccionar
Diferencia técnica entre soft bounce y hard bounce, qué códigos SMTP los identifican, cómo afecta cada uno a la reputación y qué hacer con la lista después de cada rebote.
Por qué un rebote bien procesado cuesta menos que uno mal procesado
Tu lista de envío recibe un bounce y la mayoría de las plataformas SaaS lo procesan automáticamente: lo marcan como inactivo y lo sacan de la lista activa. Eso funciona en el 80% de los casos, pero el 20% restante es donde se rompe la reputación del dominio remitente.
Hay dos errores frecuentes en operaciones de email panameñas que vemos en auditorías: tratar todos los bounces como hard (perdiendo contactos recuperables) o tratar todos como soft (acumulando hard bounces y dañando reputación de IP). Ambos cuestan dinero. El primero pierde revenue legítimo; el segundo cuesta semanas de recovery con Gmail Postmaster cuando la reputación baja a estado Bad.
Este post explica la anatomía técnica de cada tipo de rebote, los códigos SMTP que los identifican, qué hacer en cada caso y cuándo conviene reactivar un contacto previamente rebotado.
Definición técnica: soft vs hard
Un bounce es un mensaje de no-entrega que devuelve el servidor receptor al remitente. Técnicamente, todos los bounces son notificaciones MAIL FROM al return-path declarado en el envelope SMTP. La distinción soft/hard no es del protocolo SMTP estándar; es una convención de la industria sobre cómo interpretar los códigos de respuesta.
Los códigos SMTP siguen el formato CCC X.Y.Z, donde:
- CCC: código numérico de 3 dígitos (2xx success, 4xx temporary failure, 5xx permanent failure)
- X: clase de error (1=address, 2=mailbox, 3=system, 4=network, 5=protocol, 6=content, 7=security)
- Y.Z: subdetalle específico
La convención operativa:
- Hard bounce: cualquier código 5xx (rechazo permanente). Implica que la dirección o el dominio receptor no aceptan ni aceptarán el mensaje. Acción: remover el contacto de la lista activa.
- Soft bounce: cualquier código 4xx (rechazo temporal). Implica condición transitoria que puede resolverse. Acción: reintento con backoff (24-72 horas, hasta 3-5 veces).
El problema es que algunos códigos 5xx en realidad reflejan condiciones temporales (typo del receptor en una regla anti-spam) y algunos códigos 4xx en realidad reflejan condiciones permanentes (mailbox abandonado que sigue rechazando hasta que se purge). De ahí la importancia de no automatizar ciegamente la decisión por el primer dígito.
Los 10 códigos de bounce más frecuentes en operaciones panameñas
De las auditorías de logs de bounce de los últimos 18 meses de clientes CMP, estos son los códigos que cubren el 87% de los rechazos:
550 5.1.1 — Mailbox does not exist (HARD)
La dirección email no existe en el dominio receptor. Causa operativa más frecuente: typo en el formulario de captura de leads o address roleo en una empresa donde el empleado se fue.
Tratamiento: remover de lista en menos de 24 horas. Cualquier reintento daña reputación.
550 5.1.2 — Bad destination system address (HARD)
El dominio receptor no resuelve DNS o el registro MX está mal configurado. Causa: typo del dominio (gmal.com en vez de gmail.com), o dominio que cerró operaciones.
Tratamiento: remover. Para typos detectables (gmial.com, hotnail.com), conviene un script de fuzzy-matching antes de remover, que sugiera la corrección al usuario en el siguiente formulario.
550 5.7.1 — Relaying denied / message rejected (HARD pero matizar)
El servidor receptor rechaza el mensaje por política. Variantes:
550 5.7.1 Message rejected due to content: el contenido activa un filtro permanente (palabras prohibidas, dominio en blocklist). Tratamiento: investigar contenido, no remover contacto.550 5.7.1 Sender IP rejected: la IP remitente está en blocklist del receptor. Tratamiento: investigar IP, no remover contacto.550 5.7.1 Relay access denied: configuración. Tratamiento: revisar SPF y SMTP relay.
Tratamiento general: no remover el contacto automáticamente; investigar la causa raíz primero. Si después de revisar contenido e IP el rechazo persiste, entonces sí remover.
550 5.7.26 — DMARC alignment failed (HARD)
El receptor (típicamente Gmail o Yahoo) verificó DMARC y la alineación falló. El mensaje no llega y no llegará hasta que se arregle la autenticación.
Tratamiento: no remover el contacto. Pausar envíos al dominio receptor, revisar SPF/DKIM alignment, corregir, reanudar. Este código apareció masivamente desde febrero 2024 con el enforcement de Gmail/Yahoo bulk sender requirements.
421 4.7.0 — Sender throttled (SOFT, peligroso)
El receptor está aplicando throttling explícito al remitente por reputación pobre o spike de complaints. No es un soft bounce normal: es Gmail diciendo “estás enviando mal, baja el ritmo”.
Tratamiento: pausar campaña inmediatamente si más del 3% del envío recibe 421 4.7.0. Revisar Postmaster Tools, spam rate, IP reputation. Reintentar en este estado garantiza más bounces y daño compuesto a la reputación.
451 4.2.1 — Mailbox temporarily disabled (SOFT)
Buzón temporalmente desactivado por el proveedor (cuenta suspendida, mantenimiento, política temporal).
Tratamiento: reintento con backoff. Después de 5 días seguidos de 451 4.2.1 al mismo destino, tratar como hard bounce.
421 4.2.2 — Mailbox full (SOFT)
Buzón del destinatario lleno.
Tratamiento: reintento por 7 días. Si persiste, mover a inactivo (probabilidad alta de cuenta abandonada). No tratar como hard bounce inmediato; algunos buzones se vacían en pocos días.
552 5.3.4 — Message size exceeds limit (HARD para ese mensaje)
El mensaje excede el tamaño máximo del receptor. Gmail acepta hasta 25 MB, pero proveedores corporativos pueden tener límites de 5-10 MB.
Tratamiento: no remover contacto. Revisar peso del mensaje, optimizar imágenes, considerar enviar versión liviana. Es un problema del envío, no del contacto.
554 5.7.1 — Message contains spam-like content (HARD para ese envío)
El contenido del mensaje activa filtros que lo categorizan como spam permanentemente para ese receptor.
Tratamiento: no remover contacto. Revisar contenido, simplificar HTML, quitar palabras gatillo (free, urgent, $$$, etc.), validar con tools como mail-tester.com antes de reenvío.
250 OK no message accepted — Acceptance with silent drop (HARD enmascarado)
El servidor acepta el mensaje con 250 OK pero después lo descarta silenciosamente. No genera bounce, pero el mensaje nunca llega al destinatario. Difícil de detectar sin Postmaster Tools.
Tratamiento: solo detectable agregando reports de Google Postmaster Tools, comparando deliveries reportadas vs aceptaciones reportadas. Si ratio acceptance/delivery está bajo en un dominio receptor específico, hay drop silencioso.
La matriz de decisión: qué hacer con cada bounce
Matriz de decisión de bounce
Ingresa el código SMTP exacto del bounce que recibiste y obtén el tratamiento recomendado.
El error operativo que vemos en 6 de cada 10 auditorías
La configuración por default en Mailchimp, Brevo y SendGrid maneja bounces así:
- Hard bounce: 1 ocurrencia → contacto pasa a estado “cleaned” automáticamente
- Soft bounce: 7 ocurrencias en 30 días → contacto pasa a estado “cleaned”
Esto funciona para operaciones pequeñas (menos de 10.000 envíos mensuales), pero a partir de cierta escala genera dos problemas:
Problema 1: La automatización no distingue 550 5.1.1 (dirección inexistente, remover) de 550 5.7.26 (DMARC failed, problema del remitente). Trata todo como hard y pierde contactos legítimos cuya autenticación se arreglaba en una hora.
Problema 2: La automatización trata todos los 4xx como soft normales, sin detectar el 421 4.7.0 que es throttling crítico. La operación sigue enviando mientras Gmail acumula la señal negativa de “remitente que ignora throttling”.
La solución operativa es agregar una capa de procesamiento de bounce logs propia que distingue por subcódigo, no solo por primer dígito. PowerMTA y KumoMTA permiten esto nativamente con accounting files. Mailchimp y Brevo no, pero exponen webhooks de bounce que un sistema externo puede procesar.
Procesamiento de bounce logs: qué buscar
Cuando recibís el bounce log del MTA (o el webhook de la plataforma), estos son los campos críticos:
timestamp: 2025-01-08T14:32:18Z
recipient: [email protected]
sender: campañ[email protected]
smtp_code: 550
enhanced_status: 5.1.1
diagnostic: "User unknown in virtual mailbox table"
attempts: 1
final: trueLos puntos clave del análisis:
- enhanced_status (X.Y.Z): tiene más información que
smtp_code. 5.1.1 ≠ 5.7.1 ≠ 5.7.26. - diagnostic: el texto libre del receptor explica la causa real. “User unknown” es diferente a “blocked by policy”.
- final: si es false, el MTA reintentará. Si es true, es decisión definitiva.
- attempts: cuántos reintentos antes del bounce final. Si >5 con 4xx, el contacto está agotado.
Un dashboard básico de bounce health debería agrupar por:
- enhanced_status (top 10 códigos)
- domain del receptor (donde están los problemas)
- tipo (hard/soft/investigar)
- tendencia 7/30 días
Si hard bounces sube del 0.3% al 1.2% en una semana, hay calidad de captura cayendo (formulario sin double opt-in, list-broker entrando) y la operación debe pausar nuevas captaciones hasta diagnosticar.
Cuándo conviene reactivar un contacto que rebotó
La pregunta que aparece en cada reunión de planning: ¿podemos recuperar los contactos que limpiamos hace 6 meses?
La respuesta depende del código de bounce original, no del tiempo transcurrido:
Hard 5.1.1 (dirección no existe): probabilidad de recuperación cercana al 0%. Una dirección que no existió hace 6 meses no va a existir ahora. Reactivar es regenerar el bounce.
Hard 5.7.1 por contenido: posible recuperación si el contenido cambió. La dirección existe; solo el mensaje anterior fue rechazado. Conviene re-incluir con campaña nueva tras revisar contenido.
Hard 5.7.26 (DMARC failed): alta probabilidad de recuperación una vez arreglada la autenticación del remitente. La dirección existe; solo la configuración impedía la entrega.
Soft 4.2.2 cerrado como inactivo: probabilidad media-baja (5-15%). Probable cuenta abandonada, pero algunos buzones se vacían tras meses.
Soft 4.7.x cerrado como inactivo: probabilidad alta (40-60%) si el remitente arregló la causa raíz de la reputación. Conviene reactivar vía canal alternativo primero (WhatsApp opt-in, SMS) para confirmar que el contacto sigue interesado, y solo después re-incluir en email.
La regla operativa de CMP en auditorías: nunca reactivar más del 5% de los bounces históricos en una sola oleada. Hacerlo dispara el ratio de bounce de nuevo y daña reputación. Reactivaciones se hacen en batches de 200-500 contactos por semana, midiendo el bounce rate del subset antes de continuar.
Cómo configurar el procesamiento de bounce en PowerMTA y KumoMTA
En PowerMTA, el comportamiento de bounce se controla con la directiva bounce-after:
<bounce-after>
retry-attempts = 5
retry-after = 3h, 6h, 12h, 24h, 48h
max-soft-bounces = 5
permanent-bounce-codes = 5.1.1, 5.1.2, 5.1.10
</bounce-after>En KumoMTA (sintaxis Lua):
kumo.on('smtp_server_message_received', function(msg)
msg:set_meta('queue_attempts', 5)
msg:set_meta('retry_intervals', {180, 360, 720, 1440, 2880}) -- minutos
end)
kumo.on('bounce_processed', function(msg, response)
if response.code:match('^5%.7%.26') then
-- DMARC failed: NO sacar contacto, alertar a operaciones
kumo.log_event('dmarc_bounce', { recipient = msg:recipient() })
return 'investigate'
end
if response.code:match('^4%.7%.0') then
-- Throttling: pausar campaña
kumo.queue.pause('current')
return 'paused'
end
end)En plataformas SaaS sin acceso al MTA (Mailchimp, Brevo), el manejo se hace con webhooks. Configurar el webhook de bounce para que pase a un sistema externo (incluso un Google Sheet con Apps Script o una función Lambda) los bounces que no son 5.1.1 ni 5.1.2 ni 5.1.10, y revisarlos manualmente antes de que la plataforma los marque como cleaned automáticamente.
Resumen operativo
Tres reglas que aplicamos en todas las auditorías de CMP:
-
Distinguir por subcódigo, no por primer dígito. 5xx no significa siempre “borrar contacto”. 4xx no significa siempre “reintentar”.
-
El 421 4.7.0 es alerta crítica, no soft normal. Si más del 3% del envío recibe este código, pausar la campaña inmediatamente.
-
Reactivar bounces antiguos es trabajo de canal alternativo, no de email. Re-incluir directo en lista activa regenera el bounce. Validar primero por WhatsApp/SMS.
Aplicar estas reglas reduce el daño compuesto a la reputación, preserva contactos legítimos que se hubieran perdido por automatización ciega, y permite que la operación de envíos siga creciendo sin tener que recuperar reputación cada trimestre.