Tasa de rebote de email: cómo medirla y qué corregir
Resumen
La tasa de rebote de email es la proporción de mensajes enviados que un servidor receptor rechaza. Mantenga los rebotes duros por debajo del 1% en una lista sana, investigue al 2% y trate el 5% como un incidente, porque Amazon SES pone en revisión a las cuentas en ese nivel. Desglose la tasa por flujo, origen y tipo de rebote, y guarde el código SMTP para distinguir una lista sucia de un problema de reputación.
La tasa de rebote de email es la proporción de mensajes enviados que el servidor receptor rechaza, calculada sobre el total de mensajes enviados. En una lista sana, conviene mantener los rebotes duros por debajo del 1%, investigar cuando lleguen al 2% y tratar el 5% como un incidente. La mayoría de equipos lee una sola cifra en el panel y no ve que el denominador, el tipo de rebote y la ventana temporal cambian la respuesta.
El resto de este artículo trata de obtener bien ese número antes de decidir qué hacer con él.
La fórmula es sencilla. El denominador es donde los equipos no coinciden.
La tasa de rebote es igual a los mensajes rebotados entre los mensajes enviados, por 100. Algunos ESP dividen entre los mensajes entregados, lo que hace que la tasa parezca más alta, porque los entregados ya excluyen los rebotes. Conviene comprobar qué cifra informa el proveedor antes de compararla con cualquier referencia.
Amazon SES, por ejemplo, calcula la tasa de rebote solo con rebotes duros, medida frente a lo enviado por la cuenta. Ese detalle importa: un panel que mezcla rebotes blandos y duros mostrará un número más alto que el que usa el proveedor para evaluar la cuenta.
Hay que elegir una definición y escribirla junto a la métrica, en el título del panel si hace falta. En nuestro caso usamos rebotes duros sobre envíos, por dominio de envío, en 24 horas y en 7 días. Si dos personas del equipo citan cifras distintas para la misma semana, lo primero que conviene comparar es el denominador.
Rebote duro, blando y bloqueo son tres señales distintas
Un rebote duro es un fallo permanente. La dirección no existe, el dominio no resuelve o el buzón se cerró. SMTP lo informa con un código de estado mejorado 5.x.x, definido en el RFC 3463.
Un rebote blando es un fallo transitorio: un buzón lleno, un servidor caído o un mensaje demasiado grande. Llegan con códigos 4.x.x y un remitente bien configurado los reintenta. Si se quiere la clasificación completa, en nuestra guía anterior sobre rebote blando frente a rebote duro explicamos la correspondencia de códigos SMTP.
La tercera categoría es la que los paneles ocultan. Un bloqueo es un rechazo 5.x.x que no dice nada sobre la dirección y todo sobre el emisor: una IP en lista negra, una comprobación de autenticación fallida o un filtro de contenido o de reputación. Contarlo como rebote duro hace que la lista parezca sucia cuando el problema es la configuración de envío.
Conviene descartar cualquier informe que muestre una sola línea de «rebotes». Hay que dividirlo en tres series, o se limpiará una lista que nunca fue el problema.
¿Qué es una buena tasa de rebote en 2026?
No existe una cifra única publicada, y conviene saberlo antes de citar una. Gmail y Yahoo publican umbrales para las quejas de spam, no para los rebotes. Google pide a los remitentes masivos mantener la tasa de spam informada en Postmaster Tools por debajo del 0.10% y no llegar nunca al 0.30%, según su guía de remitentes.
Para los rebotes, las cifras de trabajo vienen de los ESP y de la práctica. Son los umbrales que usamos como niveles de alerta, no garantías de ningún proveedor de buzón.
Tasa de rebote duro por dominio en 24 horas, y cómo la tratamos:
Menos del 0.5%: normal en una lista comprometida y verificada.
Del 0.5% al 1%: vigilar y revisar el origen de las direcciones nuevas.
Del 1% al 2%: investigar y pausar el segmento con la tasa más alta.
Del 2% al 5%: detener los envíos masivos de ese flujo y localizar la importación o el formulario que lo causa.
Más del 5%: incidente. Amazon SES pone las cuentas en este nivel en revisión.
La última fila es un límite documentado. En la documentación del panel de reputación, Amazon SES indica que una cuenta con una tasa de rebote del 5% o superior queda en revisión, y que el envío puede pausarse si la tasa se mantiene por encima del 10%. Otros proveedores usan cifras y redacciones distintas, así que hay que leer las condiciones del propio contrato.
Segmente primero: una tasa global oculta el flujo que falla
Un 0.8% global puede contener un flujo transaccional al 0.1% y una importación de reactivación al 6%. La media parece aceptable, y el segundo flujo está dañando en silencio el dominio de envío.
Conviene calcular la tasa por flujo, por origen y por dominio del destinatario. Cuatro cortes detectan la mayoría de problemas:
Por flujo. Transaccional, lifecycle y campañas masivas nunca deberían compartir una sola cifra.
Por origen de registro. Formularios, altas por API, importaciones CSV y listas de socios tienen calidades de dirección muy distintas.
Por dominio del destinatario. Un pico en un solo proveedor suele indicar una política de rechazo, no una lista sucia.
Por antigüedad de la dirección. Las direcciones recogidas hace más de 12 meses rebotan más que las recientes.
No es un adorno de informes. Es la diferencia entre corregir un error de validación de formulario en una hora y purgar una lista sana en pánico.
Un quinto corte que conviene añadir cuando los demás estén listos: por IP o dominio de envío. Si se usa una IP dedicada para correo transaccional y un pool compartido para campañas, un pico en uno de ellos indica dónde mirar antes de abrir una sola línea de log.
Leer los eventos de rebote del proveedor sin perder datos
Todo ESP serio expone los rebotes como eventos: un webhook, un tema de notificaciones o una API de eventos. Ese flujo debe tratarse como fuente de verdad y conviene guardarlo en un almacén propio, porque los paneles agregan datos y pierden el detalle que hará falta después.
Hay que guardar estos campos para cada evento: id del mensaje, destinatario, tipo de rebote, código de estado mejorado, texto de diagnóstico y marca de tiempo. Con esos seis se responde casi cualquier pregunta que surja en una revisión posterior.
{
"event": "bounce",
"message_id": "msg_01H9",
"recipient": "user@example.com",
"bounce_type": "permanent",
"status": "5.1.1",
"diagnostic": "550 5.1.1 user unknown",
"stream": "lifecycle",
"ts": "2026-11-02T09:14:03Z"
}El manejador debe ser idempotente, con clave en el id de evento del proveedor más el id del mensaje. Los proveedores reintentan los webhooks, y un evento de rebote duro duplicado que incrementa un contador dos veces distorsionará la tasa y puede suprimir una dirección que en realidad está bien.
Postmark y Resend separan los tipos de rebote en sus eventos y permiten consultarlos por flujo de mensajes, lo que hace barato construir la división por flujo descrita arriba.
La regla de supresión que hace casi todo el trabajo
El control con más palanca es la supresión automática. Tras un solo rebote duro, conviene dejar de enviar a esa dirección de forma permanente, en la capa de aplicación y no solo confiando en la lista del proveedor.
La mayoría de ESP suprimen los rebotes duros por su cuenta. El hueco aparece al cambiar de proveedor, al ejecutar dos en paralelo o al enviar desde un sistema que nunca consulta la lista de supresión. Una tabla propia con clave en la dirección normalizada cierra ese hueco.
Para los rebotes blandos conviene usar un contador en lugar de un evento aislado. El valor por defecto es suprimir tras tres rebotes blandos consecutivos durante al menos siete días. Un buzón lleno durante una semana, a efectos de lifecycle, está perdido.
No hay que borrar las direcciones rebotadas de la tabla de usuarios. Conviene marcarlas con el código de estado y la fecha. Una fila eliminada no puede indicar que la misma dirección rebotó dos veces el trimestre pasado. Ese registro evita reimportar la misma dirección desde el siguiente CSV, que es la forma más habitual de que una lista «limpia» vuelva a ensuciarse.
Por qué la tasa sube de golpe: las causas habituales, por orden
Cuando la tasa se mueve, conviene buscar la causa en este orden. Las tres primeras explican la mayoría de los picos.
Una importación nueva. Un CSV de un evento, de un socio o de una exportación antigua de CRM. Hay que revisar primero la tasa de rebote por origen.
Un formulario de registro sin validación. Errores tipográficos como gmial.com y dominios desechables. Una comprobación de sintaxis y de registros MX en el envío elimina la mayoría, y un email de confirmación elimina el resto antes de contar como envío en un flujo lifecycle.
Un cambio de envío. Una IP nueva, un dominio nuevo o un calentamiento que subió demasiado rápido, lo que se convierte en bloqueos en lugar de rebotes duros.
Una rotura de autenticación. Alineación de SPF, DKIM o DMARC que falla tras un cambio de DNS.
Una política de rechazo del proveedor. Un dominio de destinatarios endureció sus filtros. La tasa sube solo en ese dominio.
El diagnóstico es la distribución de códigos de estado, agrupada por flujo y por dominio del destinatario en la misma ventana que el pico. Un aumento de 5.1.1 (usuario desconocido) apunta a la lista. Un aumento de 5.7.x apunta a política, autenticación o reputación. Requieren arreglos opuestos, por eso conviene guardar el código.
Lo que alertaríamos
Alertar sobre una media diaria llega demasiado tarde. Una importación mala puede enviar 40000 mensajes en una hora. Conviene alertar sobre una ventana móvil:
Tasa de rebote duro superior al 1% en los últimos 1000 envíos de cualquier flujo.
Cualquier dominio de destinatario por encima del 5% con al menos 200 envíos en una hora.
Un recuento de bloqueos 5.7.x que supere claramente la base normal.
Los dos primeros deben disparar una pausa del flujo afectado, no un aviso para una persona. Una persona puede investigar después; la pausa es lo que protege la reputación en los siguientes diez minutos.
Conviene exportar la tasa al monitoreo que ya existe, sea Grafana, Datadog o una solución propia, y conservar la etiqueta del flujo en la serie para que la división sobreviva a la exportación.
Para informar a la dirección, lo útil es la tasa de rebote duro por flujo en una ventana de 7 días, más el recuento de bloqueos. Los rebotes blandos se dejan en la vista de ingeniería, donde son útiles, y fuera de la vista ejecutiva, donde generan confusión. Nunca conviene informar solo de la cifra global de la cuenta, porque se mueve por razones que nadie en la sala puede explicar.
Si alguien pide una sola cifra, lo adecuado es dar la tasa de rebote duro del flujo transaccional. Es el flujo donde un fallo cuesta un restablecimiento de contraseña o una factura, y la lectura más limpia de si la infraestructura está sana.
El siguiente paso concreto es pequeño: extraer los eventos de rebote de los últimos 30 días, agruparlos por flujo y código de estado, y buscar la fila que no se esperaba.