Su servidor SMTP interno ha rechazado conexiones durante cuarenta minutos: certificado caducado, cuota excedida o IP recién incluida. La falla está corregida. El administrador hace clic en "relanzar los 12.000 correos electrónicos fallidos". Una hora más tarde, Gmail acelera su dominio, los registros muestran 452 y 550, y los correos electrónicos transaccionales reales (restablecer contraseña) rebotan.
El reintento ingenuo recrea el error a mayor escala.
¿Por qué es peligroso reintentar la explosión?
| Riesgo | Mecanismo | Consecuencia |
|---|---|---|
| Límite de tarifa ESP/FAI | Demasiadas conexiones/min | 421, 452 en cascada temporal |
| Lista negra | Pico sospechoso de su IP | Todos los envíos afectados |
| Cola SMTP local | Postfix/qmail lleno | Tiempos de espera de aplicaciones |
| Experiencia de usuario | Duplicados no deduplicados | 3 facturas idénticas |
Un correo electrónico fallido no es información que deba desecharse: es un mensaje con una causa, una prioridad y una ventana de validez.
Clasificar antes de reiniciar
Rebote total (5xx): dirección inexistente, política de rechazo: no volver a intentarlo. Mark falló, limpie la base.
Rebote suave (4xx): cuota, lista gris, temperatura no disponible: reintentar con retroceso.
Tiempo de espera de la aplicación: su código no tuvo respuesta: investigue por separado del rebote SMTP.
Almacene el código SMTP, DSN y número de intentos por mensaje.
Retraso exponencial y límite de tasa
Diagrama típico:
| Intento | Fecha límite | Acción |
|---|---|---|
| 1 | 5 minutos | Reintento automático |
| 2 | 30 minutos | Reintento automático |
| 3 | 2 a. m. | Reintento + alerta de explotación |
| 4 | 24 horas | Último intento |
| 5 | — | Fallido permanentemente |
Limite el flujo general: p.e. 100 correos electrónicos/minuto como máximo en recuperación, incluso si su ESP permite más.
Implementación: reintento de Sidekiq, retroceso de cola de Laravel, Celery retry_backoff o cron que lee una tabla outbound_mail con next_retry_at.
Priorizar los correos electrónicos críticos
No todos los mensajes merecen el mismo SLA:
- P0 — restablecer contraseña, 2FA, alertas de seguridad.
- P1 — confirmaciones de pedidos, facturas.
- P2: boletines informativos, marketing retrasado.
En recuperación, procese P0 primero con un canal separado si es posible (ESP transaccional dedicado).
Inicio ESP vs SMTP en hosting
En compartido o VPS, enviar directamente desde Postfix expone su IP compartida. Los ESP transaccionales absorben los picos de reintentos y manejan SPF/DKIM/DMARC.
Si es autohospedador: supervise herramientas postmaster, rDNS y limite el volumen desde una IP dedicada.
Lo mejor: el reintento es una prueba de reputación, no de persistencia
Mida los rebotes después de un reintento, no solo los envíos "aceptados" por su SMTP.
Decide y avanza sin puntos ciegos
Estado persistente, código de error y número de intentos por mensaje antes de necesitar recuperación. Implemente la reducción y la limitación de velocidad desde el principio, no el día de la interrupción. Separe las transacciones y el marketing a través de dominios o ESP separados. Pruebe un escenario de falla + recuperación en puesta en escena con un volumen realista. Compare hosts y límites de correo electrónico en nuestro directorio.
Preguntas frecuentes
¿Deberíamos reiniciar inmediatamente después de una falla de SMTP?
No. Espere hasta que el servicio esté estable, identifique la causa (autenticación, cuota, lista negra) y luego reinicie por lotes con retroceso, no un volcado de miles de mensajes simultáneos.
¿Cuál es la diferencia entre el error SMTP 4xx y 5xx?
4xx = temporal (lista gris, cuota) → reintentar con retroceso. 5xx = permanente (dirección, política no válida) → no insistir, marca fallida y alerta.
¿Cómo evitar la lista negra durante un gran reintento?
Limite el rendimiento (mensajes/minuto), distribuido en varias horas, utilice un ESP transaccional (Brevo, Mailgun, Postmark) con reputación administrada y controle las tasas de rebote.
¿Cola interna o servicio gestionado?
Cola casera (Redis, base de datos) si el volumen y el equipo de operaciones son modestos. Los webhooks ESP + rebotan o se quejan tan pronto como el volumen o la capacidad de entrega se vuelven críticos.
Después de una interrupción de SMTP, la pregunta no es "cuánto reiniciar", sino qué tan rápido su reputación puede absorber la recuperación.