We Manegit
Resumen ejecutivo
Cuando una empresa piensa en rebotes de correo electrónico, suele asociarlos únicamente con campañas de marketing masivo. Sin embargo, el punto más peligroso y desatendido de degradación de reputación ocurre dentro de tus propios sistemas: tiendas online, portales de clientes, plataformas SaaS y sistemas ERP que disparan facturas, enlaces de recuperación de contraseña y alertas automáticas sin procesar las respuestas de error del servidor receptor. Ignorar un rebote duro (código 5xx) y permitir que tu aplicación insista día tras día contra casillas inexistentes le demuestra a Google y Microsoft que tu servidor no tiene control técnico, y eso termina retrasando o enviando a spam las notificaciones críticas de tus clientes reales. Diferenciar los rebotes duros de los blandos, espaciar los reintentos ante los errores temporales 4xx (exponential backoff) y mantener listas de supresión automáticas conectadas con tu aplicación por webhooks es lo que protege la entregabilidad transaccional de tu negocio.
1. El enemigo silencioso en tu backend: Por qué los sistemas transaccionales también destruyen tu dominio
En la mayoría de las PyMEs y empresas digitales en crecimiento, el flujo de envío de una notificación transaccional fue programado bajo una lógica lineal: el usuario ejecuta una acción en la plataforma (crea su cuenta, pide restablecer su contraseña o confirma una compra), el servidor web invoca la función de envío SMTP y registra en su base interna que el correo fue enviado. Rara vez el equipo de desarrollo programó un circuito de retorno que escuche qué ocurrió segundos después frente al servidor de correo del destinatario.
Este punto ciego genera una erosión constante en tu activo digital más sensible. Piensa en un sistema ERP que envía facturas electrónicas automáticas todos los meses, o en una aplicación SaaS que manda resúmenes operativos diarios. Basta con que algunos usuarios hayan escrito mal su correo al registrarse, o que empleados de tus empresas clientes hayan dejado su puesto y sus buzones corporativos hayan sido eliminados, para que tu servidor empiece a acumular rechazos todos los días.
Para los filtros de Google Workspace, Microsoft 365 y Yahoo, un servidor que ignora sistemáticamente las respuestas de error y vuelve a golpear día tras día las mismas direcciones inexistentes muestra el mismo patrón técnico que una red de spam o un ataque de diccionario. La sanción no tarda en llegar: limitación en la velocidad de recepción (throttling), retención preventiva en colas grises o el desvío directo a la carpeta de correo no deseado de tus notificaciones más urgentes.
2. Glosario de respuestas SMTP: Códigos 4xx, 5xx, DSN, Backoff Exponencial y Lista de Supresión
Para revisar cómo tu plataforma procesa cada intento fallido de entrega, conviene conocer el vocabulario técnico del protocolo SMTP:
- Código SMTP 4xx (Soft Bounce o rebote blando)
- Respuesta transitoria del servidor receptor (como 421 o 452). Indica que el buzón de destino existe, pero atraviesa un impedimento momentáneo (casilla llena, saturación o control temporal de tráfico) y pide volver a intentar más tarde.
- Código SMTP 5xx (Hard Bounce o rebote duro)
- Respuesta negativa definitiva (como 550, 551 o 553). Confirma que la dirección de correo no existe, que el dominio de destino es inválido o que el servidor rechaza el mensaje por políticas de seguridad.
- Código extendido DSN (Delivery Status Notification, RFC 3463)
- Subcódigo de tres dígitos separados por puntos (por ejemplo, 5.1.1 para casilla inexistente, 4.2.2 para buzón lleno o 5.7.1 para rechazo por política o autenticación) que permite clasificar con exactitud la causa del rebote.
- Lista de supresión (Suppression List)
- Registro de protección en la capa de salida SMTP que bloquea automáticamente los envíos futuros a cualquier dirección que haya devuelto un rebote duro 5xx o una queja, incluso si tu aplicación intenta enviar el correo por error.
- Backoff exponencial (Exponential Backoff)
- Estrategia de reintentos que aumenta de forma progresiva el tiempo de espera entre cada intento ante un fallo 4xx (por ejemplo: 15 minutos, 1 hora, 4 horas y 24 horas), respetando la capacidad del servidor receptor.
- Webhook de eventos transaccionales
- Aviso automático de servidor a servidor, una petición HTTP POST en formato JSON, que le informa a tu base de datos cuándo un correo fue entregado, demorado o suprimido por rebote.
3. Rebotes duros (Hard Bounces, códigos 5xx): Qué significan y por qué exigen supresión inmediata
Un rebote duro no admite segundas oportunidades técnicas. Cuando un servidor de destino responde con un código de la familia 5xx, te está avisando que no debes volver a enviar mensajes a ese destinatario hasta que una persona corrija el problema de origen.
Causas principales de rebote duro en sistemas web
- Errores de tipeo en formularios sin doble validación (SMTP 550 5.1.1): usuarios reales que, durante una compra rápida o un registro desde el celular, escriben dominios mal formados (como "@gmial.com", "@hotmial.com" o con espacios invisibles). El sistema crea la cuenta e intenta enviar el correo de bienvenida a un destino inexistente.
- Rotación de personal en clientes corporativos B2B (SMTP 550 5.1.1 o 551): en plataformas B2B, portales de proveedores y sistemas de cobranza, una parte de las casillas nominales cambia cada año. Cuando el administrador de sistemas del cliente da de baja el buzón de un exempleado, cada aviso mensual devuelve un 550 inmediato.
- Dominios empresariales vencidos o sin registros MX (SMTP 550 5.1.2 o NXDOMAIN): empresas clientes que cerraron, cambiaron de razón social y de dominio principal, o desconfiguraron por accidente sus registros MX en el DNS, lo que provoca fallos permanentes de entrega.
- Bloqueos por reputación o falta de autenticación (SMTP 550 5.7.1 o 5.7.26): un caso crítico que exige atención técnica inmediata. La casilla del cliente sí existe, pero su servidor rechaza tu envío con un código 5.7.x porque tu IP figura en una lista de bloqueo o tu subdominio no tiene SPF, DKIM y DMARC alineados.
4. Rebotes blandos (Soft Bounces, códigos 4xx): Cómo gestionar fallos temporales sin saturar al receptor
A diferencia del código 5xx, un rebote blando (4xx) nunca debe provocar la baja inmediata del contacto en el primer intento. Si el buzón corporativo de un gerente financiero está lleno por un momento (452 4.2.2 Over quota) o el filtro de su banco aplica greylisting preventivo (421 4.7.0 Try again later), suprimir la dirección al primer aviso impediría que reciba sus facturas y notificaciones futuras cuando el inconveniente se resuelva, horas después.
Sin embargo, el extremo opuesto es igual de destructivo: muchos servidores web mal configurados entran en un bucle de reintentos cada 60 segundos ante un código 421. Ese martilleo constante agota las conexiones simultáneas permitidas y convierte una demora preventiva en un bloqueo definitivo de la dirección IP emisora. Un esquema de reintentos espaciados se ve así:
- Intento 1, espera de 15 minutos: resuelve pausas breves de greylisting o microcortes en el servidor MX del cliente.
- Intento 2, espera de 1 hora: permite absorber picos de congestión horaria o reinicios por mantenimiento en servidores corporativos.
- Intento 3, espera de 4 horas: da margen a que el destinatario libere espacio en casillas con la cuota excedida (452).
- Intento 4 y cierre, espera de 24 a 48 horas: si después de varios reintentos escalonados el código 4xx persiste en distintos envíos, la dirección pasa a una cuarentena preventiva para proteger la reputación del dominio.
5. Arquitectura de webhooks y supresión automática: Cómo conectar el correo con tu aplicación
La solución es cerrar el circuito entre el motor de envío y la lógica de tu software, para que ningún error quede flotando en el vacío. El flujo completo tiene tres pasos:
- Envío autenticado: tu sistema envía el código de acceso, el enlace de recuperación de clave o el comprobante desde un dominio de envío propio (por ejemplo,
auth.tuempresa.com), con SPF, DKIM y DMARC alineados. - Lectura de la respuesta SMTP: si el servidor de destino responde
250 OK, la entrega queda registrada. Si responde un 4xx (rebote blando), el mensaje entra en la cola de reintentos espaciados (15 minutos, 1 hora, 4 horas, 24 horas). Si responde un 5xx (rebote duro), la dirección pasa de inmediato a la lista de supresión. - Aviso a tu aplicación: un webhook en formato JSON le informa a tu aplicación o a tu ERP qué pasó, para que marque el correo del usuario como inválido y le pida actualizarlo en pantalla.
Cuando ocurre un rebote duro por dirección inexistente (550 5.1.1), el motor de envío agrega la dirección a la lista de supresión y le envía a tu plataforma un aviso con datos como estos:
| Dato del webhook | Ejemplo | Para qué sirve |
|---|---|---|
| Evento | smtp.hard_bounce | Indica que fue un rebote duro. |
| Remitente | seguridad@auth.tuempresa.com | Muestra desde qué dominio de envío salió el correo. |
| Destinatario | administracion@clienteb2b-inexistente.com | La dirección que hay que corregir en tu base. |
| Código y estado extendido | 550 y 5.1.1 | Casilla inexistente: no se vuelve a intentar. |
| Diagnóstico | The email account that you tried to reach does not exist. | El texto que devolvió el servidor de destino. |
| Supresión aplicada | true | La dirección ya está bloqueada para los próximos envíos. |
| Acción recomendada | flag_user_email_invalid_and_prompt_update | Marcar el correo como inválido y pedirle al usuario que lo actualice. |
Protección en doble capa (motor de envío y aplicación)
Aunque tu ERP o tu tienda online intente volver a enviar una factura a un correo que ya rebotó antes de que tu equipo actualice la ficha, la lista de supresión frena el envío antes de abrir una conexión SMTP externa, y tu reputación frente a Google y Microsoft queda intacta.
Distinción entre casilla inválida (5.1.1) y bloqueo de política (5.7.1)
Un error común en configuraciones caseras es bloquear para siempre a clientes válidos cuyos servidores rechazaron un mensaje por un problema puntual de DNS o de filtro corporativo (5.7.1). Conviene separar los dos eventos: suprimir las direcciones inexistentes (5.1.1) y revisar cada código 5.7.x, porque suele señalar un problema de autenticación o de reputación que hay que corregir para destrabar la entrega.
Recuperación del contacto en la interfaz del cliente
Gracias al webhook, la próxima vez que ese usuario inicie sesión en tu portal o se comunique con soporte, tu sistema puede mostrarle un aviso claro ("Detectamos un error al enviarte tus comprobantes a este correo; por favor confirma tu dirección actual") y reactivar la entrega cuando la corrige.
6. Diagnóstico y comparativa: Sistema sin gestión de rebotes vs. Infraestructura transaccional ROW
| Parámetro | Sistema sin gestión de rebotes | Infraestructura transaccional ROW (We Manegit) |
|---|---|---|
| Lectura de códigos SMTP | El sistema ignora las respuestas 4xx y 5xx; los fallos quedan ocultos en registros que nadie revisa. | Cada respuesta queda clasificada como entrega, rebote blando o rebote duro, con monitoreo de rebotes, quejas y reputación. |
| Ante un rebote duro (5xx) | Sigue enviando recibos, alertas y contraseñas cada mes a la misma casilla inexistente. | La dirección pasa a la lista de supresión y no se vuelve a intentar. |
| Ante un rebote blando (4xx) | Reintentos agresivos cada pocos segundos que saturan al receptor, o descarte prematuro del correo. | Reintentos espaciados hasta lograr la entrega o dar el correo por perdido. |
| Sincronización con la aplicación o el ERP | Nula: atención al cliente y facturación creen que el usuario recibió la notificación. | Integración con tu sistema, ERP, CRM o aplicación para que se entere de cada rebote. |
| Riesgo de listas negras | Alto: reenviar a direcciones muertas o a trampas de spam degrada la IP y bloquea el dominio. | Dominio de envío configurado y autenticado, separado de tus campañas, con rebotes y quejas bajo control. |
| Seguimiento | El problema se detecta cuando los clientes reclaman que no pueden entrar a su cuenta. | Un Relay Owner que vigila que los correos lleguen y mira los rebotes antes de que se quejen los clientes. |
7. Preguntas frecuentes sobre códigos SMTP, listas de supresión y correos operativos
¿Qué ocurre si un usuario corrige su casilla o su empresa reactiva un buzón que estaba en la lista de supresión?
La lista de supresión es una protección dinámica, no una caja cerrada. Si el cliente corrige un error de tipeo en su perfil y carga una dirección nueva válida, el envío fluye de inmediato porque se trata de un destinatario distinto. Y si la empresa del cliente tuvo una caída temporal de sus registros MX que provocó un rebote duro y después restableció su servidor de correo, se verifica que el buzón vuelva a funcionar y se quita esa dirección puntual de la lista de supresión desde el panel o la API del motor de envío. En Row lo pides por ticket y lo resuelve tu Relay Owner.
¿Un código OTP que vence en 5 minutos debe usar el mismo esquema de reintentos de 24 horas ante un rebote blando?
No. No todos los mensajes transaccionales tienen la misma vida útil (TTL, Time To Live). Una factura electrónica o un contrato en PDF sí conviene reintentarlos durante 24 o 48 horas hasta entregarlos. En cambio, un código OTP que vence a los pocos minutos no sirve si llega seis horas tarde. Lo recomendable es configurar políticas distintas por tipo de mensaje: para los códigos de acceso, reintentos cortos dentro de su ventana de validez y, si el servidor de destino demora, un aviso a tu interfaz para que ofrezca reenviar el código o usar otro canal.
¿Por qué no alcanza con revisar la casilla donde caen los mensajes "Mail Delivery Subsystem"?
Porque la revisión manual de los avisos de rebote (NDR) no escala ni frena a un sistema automatizado. Mientras una persona abre esa bandeja una vez por semana, tu plataforma ya pudo disparar cientos de intentos fallidos durante la madrugada y encender las alarmas de reputación en Gmail o Microsoft. El procesamiento automático, en cambio, lee las cabeceras técnicas (Diagnostic-Code y Status) y bloquea la dirección en el momento, a cualquier hora.
¿Cómo implementa We Manegit el servicio ROW si nuestro sistema solo permite configurar usuario y clave SMTP?
Si tu ERP, tu tienda online o tu sistema heredado solo admite salida SMTP clásica, sin webhooks propios, tu Relay Owner configura el envío por SMTP con el motor de envío que mejor se ajusta a tu caso y autentica tu dominio de envío. La supresión de los rebotes duros y los reintentos de los blandos los hace el motor de envío aunque tu sistema no reciba webhooks, y tu Relay Owner monitorea rebotes, quejas y reputación para que la limpieza de tu base no dependa de que alguien lea los avisos de rebote.
Revisemos cómo tu sistema maneja los rebotes
Cuéntanos qué correos envía tu plataforma y por dónde salen. Revisamos tus rebotes, la autenticación de tu dominio de envío y cómo tu sistema procesa los errores de entrega, y te respondemos con el próximo paso para que tus correos críticos lleguen.
Hablemos