Recuperación · Gestión de rebotes

Guía de gestión de rebotes de email

Los rebotes son parte normal del email transaccional. La forma de clasificarlos, suprimirlos y recuperarlos determina si tu reputación de envío resiste operaciones de alto volumen.

events · ciclo de vida del mensaje · msg_01HF2K…
03:14:02 aceptado api · idempotency_key=otp_8842
03:14:02 en cola pool=transactional-critical
03:14:03 enviado relay=eu-primary
03:14:051 deferred 421 limitado · eu-primary
03:14:06 reruteado policy=failover → us-relay
03:14:07 entregado inbox

UI de producto representativa — datos ilustrativos, no métricas reales de clientes.

Plano de control

Cómo Sendarix clasifica, suprime y enruta según señales de rebote

Los eventos de rebote alimentan decisiones de routing y supresión por tenant, no solo una blocklist estática. Los hard bounces se suprimen de inmediato; los soft bounces siguen tu política de reintentos antes de escalar.

El aislamiento por tenant evita que una mala lista de un cliente afecte a los demás. Los eventos webhook (bounce, soft_bounce, complaint) dan a tu aplicación el detalle necesario para actualizar CRM y activar flujos de recuperación. Consulta email routing para configurar políticas.

deliverability · salud del relay · 24h
Ruta relaySeñalEstado
Transaccional UEEntrega establesaludable
Bulk EE. UU.Deferrals bajossaludable
Dedicated tenantDeferrals elevadosdegradado

UI de producto representativa — datos ilustrativos, no métricas reales de clientes.

Hard bounce vs soft bounce - clasificación

No todos los rebotes son iguales. El código de respuesta del servidor receptor indica si el fallo es permanente o temporal, y tu sistema debe tratar cada caso de forma distinta.

Hard bounce

Fallo permanente de entrega. El buzón no existe, el dominio no es válido o el destinatario ha rechazado permanentemente el correo de tu dominio.

Códigos de respuesta:
550 Mailbox unavailable, 550 User unknown, 550 No such recipient

Acción requerida: Añadir de inmediato a la lista global de supresión. No volver a enviar a esta dirección.

Soft bounce

Fallo temporal de entrega. El buzón está lleno, el servidor no está disponible temporalmente o hay un problema de conexión.

Códigos de respuesta:
450 Mailbox full, 421 Service temporarily unavailable, 451 Server busy

Acción requerida: Reintentar con backoff exponencial. Convertir a hard bounce tras N fallos consecutivos.

Estrategia de reintento y backoff

Los soft bounces deben reintentarse, pero no inmediatamente ni de forma indefinida. Un calendario estructurado evita que tu sistema presione servidores ya degradados.

MomentoAcción
InmediatoPrimer intento en el momento del envío
+15 minPrimer reintento - error de servidor o red
+1 horaSegundo reintento
+4 horasTercer reintento
+12 horasCuarto reintento
DescartarTras 5 fallos consecutivos, convertir a hard bounce y suprimir

Gestión de listas de supresión

La lista de supresión es tu defensa principal contra envíos a direcciones que no pueden recibir correo.

Hard bounces

Permanentes. No intentar reentrega. Guardar permanentemente con marca de tiempo.

Quejas (FBL)

El usuario marcó como spam. Supresión a largo plazo. Guardar con fecha de queja.

Solicitudes de baja

Deben suprimirse de inmediato según requisitos CAN-SPAM y GDPR.

Fallos transitorios

No suprimir durante la ventana de reintentos. Suprimir solo cuando se excedan los reintentos máximos.

En plataformas SaaS multi-tenant, las listas de supresión deben aislarse por tenant. Consulta tenant isolation para límites de supresión por dominio.

Seguimiento de eventos webhook para rebotes

Los eventos de rebote enviados mediante email webhooks aportan el mayor detalle. Sigue estos tipos de evento:

  • bounce — hard bounce. Suprimir el destinatario de inmediato.
  • soft_bounce — fallo temporal. Programar reintento según tu política de backoff.
  • complaint — destinatario marcó como spam. Supresión a largo plazo.
  • delivery — confirma aceptación por el servidor receptor.
  • reject — el servidor rechazó antes de poner en cola. Revisar registros SPF/DKIM/DMARC.

Sendarix gestiona automáticamente la clasificación de rebotes

Los eventos de rebote se rastrean por mensaje, se clasifican como hard o soft y las listas de supresión se actualizan automáticamente. Los calendarios de reintento y la lógica de failover se configuran mediante la API de email routing.