En el Deliverability Summit 2026 en Barcelona, Syed Alam de Postmastery presentó un dataset donde aproximadamente el 18% de las direcciones suprimidas bajo un modelo estándar de hard/soft seguían siendo destinatarios válidos. Habían sido eliminadas porque un código 5xx parecía terminal, o porque un 4xx se repetía. Ambas suposiciones eran erróneas, y ambas estaban costando ingresos a los remitentes en cada envío.
Este es el argumento para retirar el modelo binario de bounce. El reemplazo que propuso Alam, y que varios operadores en deliverabilitysummit.com respaldaron, es un sistema de tres categorías: hard, soft, y lo que Alam llama “just-a-bounce”. La distinción importa porque las decisiones de supresión basadas únicamente en códigos de respuesta reducen tu lista direccionable más rápido de lo que jamás lo hará el churn.
Por qué el binario Hard/Soft se rompe
La lógica heredada es simple: 5xx significa permanente, suprimir; 4xx significa temporal, reintentar. Los mailbox providers dejaron de honrar ese contrato hace años. Un 5xx puede significar “rechazo por política en este momento exacto” y un 4xx puede significar “esta dirección lleva dos años inactiva, simplemente no devolvemos un 550 para ella”.
La clasificación de bounces de email en tres categorías de Alam reformula la decisión en torno al estado del destinatario, no al código SMTP:
- Categoría 1 – Hard: “User unknown”, “no such mailbox”, “address rejected”. El destinatario no existe. Suprimir inmediatamente en la primera ocurrencia.
- Categoría 2 – Soft: “Mailbox full”, “over quota”, “temporarily deferred”. El destinatario existe pero no puede recibir ahora mismo. Reintentar con exponential backoff, suprimir solo tras un fallo sostenido (típicamente 7-14 días).
- Categoría 3 – Just-a-bounce: “Policy rejection”, “too many connections”, “rate limited”, “content rejected”, “IP reputation”. El bounce tiene que ver contigo, el remitente, o la conexión. El destinatario está bien. No suprimir.
La tercera categoría es donde la mayoría de ESPs y sistemas internos pierden suscriptores. Un rechazo por política desde un gateway corporativo durante una breve caída de reputación no es señal de que la dirección del destinatario sea mala. Suprimir basándose en eso significa perder un contacto legítimo en el que invertiste presupuesto de adquisición.
Acción esta semana: extrae tus logs de bounce de los últimos 30 días y etiqueta cada cadena de motivo de bounce contra las tres categorías. Si tu automatización actual suprime por motivos de Categoría 3, ese es tu primer arreglo.
Construyendo la capa de clasificación
Mapear las respuestas SMTP a categorías no es trivial porque los proveedores no estandarizan sus cadenas de motivo. Gmail, Microsoft, Seznam, Yahoo y los servidores corporativos Exchange formulan la misma condición de manera diferente, y los enhanced status codes (los tripletes 5.x.x y 4.x.x) se rellenan de forma inconsistente.
Un clasificador funcional necesita tres entradas:
- El código de respuesta SMTP (4xx o 5xx).
- El enhanced status code cuando esté presente.
- La cadena de texto libre del motivo, parseada contra un diccionario mantenido.
Postmastery y otros vendors de deliverability mantienen diccionarios que mapean miles de variantes de cadenas de motivo a categorías de bounce. Si lo estás haciendo internamente, empieza con las 50 cadenas de motivo principales de tus propios logs, que típicamente cubrirán más del 90% del volumen. La long tail se puede añadir de forma incremental.
Un matiz que destacó Alam: la misma cadena de motivo puede cambiar de categoría con el tiempo. “Message rejected for policy reasons” era Categoría 3 en 2022. Para 2026, cuando se envía repetidamente a la misma dirección sin entrega exitosa entre medias, varios mailbox providers la usan como señal soft de que la dirección está inactiva. Reetiquetar tu diccionario cada trimestre es un mantenimiento razonable.
Acción esta semana: exporta las 50 cadenas de motivo de bounce principales, clasifícalas manualmente y guarda el mapeo como un archivo de configuración versionado en lugar de hardcodearlo.
El volumen absoluto de quejas supera a la tasa de quejas
La conversación sobre bounces conecta directamente con un segundo fallo de monitorización que Chris Adams de Bird presentó en Barcelona. Adams describió una red de afiliados de 22 cuentas que enviaba 2.800 millones de mensajes al mes manteniendo tasas de queja por debajo del 0,03%, muy por debajo del umbral del 0,1% que la mayoría de remitentes considera su techo.
La tasa parecía bien. El número absoluto no. Esa red generaba 78.000 quejas al día, que es lo que los mailbox providers realmente ponderaron cuando tomaron acción.
La implicación para cualquiera que gestione una lista: una tasa de quejas baja en un envío grande no es seguridad. Si duplicas tu volumen y tu tasa se mantiene plana, has duplicado el número de personas haciendo clic en “esto es spam” sobre tu dominio. Los postmasters a escala ven cifras absolutas. Construyen modelos de reputación sobre cifras absolutas. Mirar solo la tasa oculta la trayectoria hasta que es demasiado tarde para corregirla.
Combina esto con el trabajo sobre bounces de arriba. Los remitentes que no eliminan los hard bounces de Categoría 1 inflan su volumen con direcciones que no pueden quejarse pero tampoco pueden engagement, mientras su recuento absoluto de quejas de los destinatarios reales restantes sigue creciendo en línea con los envíos.
Acción esta semana: construye un dashboard diario que rastree el recuento absoluto de quejas por dominio remitente, junto con la tasa. Establece umbrales de alerta sobre el número absoluto, no solo sobre el porcentaje.
Checklist de implementación
Poner en producción el modelo de tres categorías y la monitorización de volumen absoluto típicamente lleva uno o dos sprints. El orden de abajo refleja lo que produjo las mejoras de deliverability más rápidas entre los operadores que compartieron datos en DS2026:
- Semana 1: Exporta 30-90 días de logs de bounce. Identifica las 50 cadenas de motivo principales por volumen. Clasifica manualmente cada una en Hard, Soft o Just-a-bounce.
- Semana 2: Actualiza la lógica de supresión. Suprime inmediatamente en Categoría 1. Mueve Categoría 2 a una cola de reintentos con una ventana de fallo de 7-14 días. Elimina por completo los disparadores de supresión en Categoría 3.
- Semana 3: Audita tu CRM en busca de direcciones suprimidas bajo el viejo modelo binario en los últimos 12 meses. Reclasifícalas. Las direcciones suprimidas únicamente por motivos de Categoría 3 pueden ser reactivadas, idealmente detrás de un gate de re-engagement.
- Semana 4: Añade el volumen absoluto de quejas a tu monitorización diaria. Establece umbrales por dominio remitente basados en la línea base actual más un 25%, no en benchmarks de tasa de la industria.
- Continuo: Reetiqueta tu diccionario de cadenas de motivo cada trimestre. Revisa las direcciones reactivadas en busca de engagement; si interactúan, nunca fueron malas. Si no lo hacen, se descartan a través de la política normal de sunset.
Extrae tus logs de bounce hoy y cuenta cuántas de tus últimas 1.000 supresiones fueron Categoría 3. Ese número es tu estimación mínima del valor recuperable de tu lista, y está sentado en una tabla de base de datos esperando a que hagas la pregunta.