Plan de disaster recovery para infraestructura de email: qué proteger y cómo
Los 6 escenarios de fallo que pueden tumbar tu operación de email: cuáles son críticos, cómo prepararse, qué tener documentado y cómo recuperarse de cada uno sin perder reputación.
Por qué la mayoría de operaciones no tiene DR de email
Cuando una operación piensa en disaster recovery, suele cubrir: servidores de aplicación, base de datos, archivos críticos. Email queda fuera del scope porque “es solo email, no es crítico”.
Hasta que algo pasa. Y email, especialmente si la operación depende de él para revenue (e-commerce, SaaS B2B, fintech), es tan crítico como cualquier otro sistema. Una operación que pierde su capacidad de enviar emails por 72 horas pierde:
- Revenue directo del email marketing pausado
- Transacciones que no se confirman (carritos abandonados, cancelaciones)
- Trust del cliente que no recibe la factura o OTP esperado
- Reputación de dominio en construcción se erosiona
Este post cubre los 6 escenarios típicos de disaster, qué preparar para cada uno, y cómo construir un runbook de DR sin sobre-engineering.
Escenario 1: IP en blocklist (Spamhaus, SpamCop, Barracuda)
Probabilidad: media (22% de operaciones en 3 años)
Causa típica
Spike de hard bounces, complaint rate alto en una campaña, IP heredada con historial, asociación con sender problemático.
Tiempo de recovery sin plan
5-14 días (mientras tramita delisting + tiempo para que blocklists se actualicen + reconstrucción de reputación afectada).
Tiempo de recovery con plan
24-48 horas operativas (cambiar a IP backup mientras se tramita delisting).
Qué preparar
Antes del incidente:
- Tener IP secundaria pre-warmeada al 10-20% del volumen, lista para asumir 100%
- Monitorear blocklists con tool como MXToolbox Blacklist Monitor (USD 15-49/mes) para detectar entrada temprana
- Documentar el proceso de delisting de cada blocklist principal (Spamhaus SBL, Spamhaus XBL, SpamCop, Barracuda)
- Tener contactos directos con BSP/proveedor que pueda ayudar con escalation
Durante el incidente:
- Confirmar el listing con MXToolbox y otras herramientas
- Iniciar trámite de delisting en cada blocklist afectada
- Switch operativo: redirigir 100% del tráfico a IP backup
- Comunicación interna: aviso a equipo + clientes si aplica
- Investigar causa raíz (revisar logs, identificar campaña problemática, evaluar si limpiar lista)
Después del incidente:
- Si la lista tenía contactos problemáticos, purgar
- Re-warmup gradual de la IP recuperada
- Documentar lessons learned en el runbook
Escenario 2: caída del proveedor SaaS
Probabilidad: baja-media (5-12% en 12 meses)
Causa típica
Outage del proveedor (Mailchimp, Brevo, Klaviyo), problemas regionales (AWS LATAM outage), suspensión preventiva de la cuenta por sospecha de spam, error de billing que pausa el servicio.
Tiempo de recovery sin plan
Depende del proveedor. Outage de Mailchimp histórico: 4-24 horas. Suspensión por sospecha de spam: 24-72 horas (review manual del proveedor). Caso peor: cancelación de cuenta, ahí son días-semanas para migrar.
Tiempo de recovery con plan
1-4 horas para activar fallback.
Qué preparar
- Cuenta secundaria en proveedor distinto, con la lista replicada (export mensual mínimo)
- Configuración DNS preparada para apuntar al proveedor backup (no activado, listo para activar)
- Template HTML guardado en formato exportable (MJML o HTML puro) para reactivar campañas urgentes
Caso real: la operación que perdió 4 días por outage de Mailchimp
E-commerce panameño con 350K envíos/mes en Mailchimp. En marzo 2024, Mailchimp tuvo outage de 8 horas. La operación tenía campaña promocional crítica programada esa noche; quedó suspendida.
Sin backup, la única opción fue esperar. Outage se resolvió en 8 horas pero la cola de Mailchimp tardó 36 horas más en procesar el backlog. Cuando los emails finalmente llegaron, la promoción ya había terminado (era oferta de 48h).
Pérdida estimada: USD 18.000 en revenue + daño de marca por confusión de clientes.
Post-incidente: cuenta backup en Brevo, lista sincronizada mensualmente, plantilla de campaña duplicada. Costo: USD 25/mes adicional. La próxima vez que pase outage, recovery en <2 horas.
Escenario 3: corrupción o pérdida de lista de contactos
Probabilidad: baja (1-3% pero alto impacto)
Causa típica
Error humano (delete masivo accidental), bug en integración con CRM/Shopify que duplica/borra contactos, hack que modifica la base.
Tiempo de recovery sin plan
Tiempo necesario para reconstruir desde fuentes secundarias (CRM, sistema de transacciones, backups de la plataforma) — típicamente 1-4 semanas con visibilidad parcial.
Tiempo de recovery con plan
Tiempo del último backup más restore, típicamente 4-24 horas.
Qué preparar
- Export semanal automatizado de la lista completa a S3, Google Drive, o storage propio
- Retención de exports por al menos 12 meses
- Sincronización en tiempo real entre fuente de verdad (CRM/database propio) y plataforma de email; la plataforma NO es la fuente de verdad
- Test trimestral de restore desde backup
El principio operativo
La lista de email no es de la plataforma; es tuya. La plataforma es solo el operador. Si tratás la lista como “los datos están en Mailchimp”, estás en riesgo. Si tratás la lista como “los datos están en mi CRM/database, Mailchimp es solo executor”, el riesgo es menor.
Escenario 4: pérdida de credenciales DKIM
Probabilidad: baja pero alto impacto
Causa típica
La persona que tenía la llave privada en su laptop se fue, su laptop falleció, no había backup, el archivo se eliminó por error en cleanup.
Tiempo de recovery sin plan
4-6 semanas (proceso de generación de llave nueva + warmup + reconstrucción de reputación + degradación durante el proceso).
Tiempo de recovery con plan
24 horas (recuperar backup, restaurar en MTA, validar).
Qué preparar
- Backup de TODAS las llaves privadas DKIM en password manager compartido (1Password Business, Bitwarden, LastPass)
- Acceso por al menos 2-3 personas autorizadas
- Versiones encriptadas en storage offline (USB encriptado en caja fuerte) para casos de compromise del password manager
- Rotación documentada: cuando se rota una llave, se actualiza el backup INMEDIATAMENTE
Operativa básica
# Generar llave (no perder el archivo)
openssl genrsa -out 2025jan.private.key 2048
# Backup inmediato a múltiples ubicaciones
cp 2025jan.private.key /encrypted-backup/dkim/
op item create --vault DKIM-backup --title "DKIM 2025jan empresa.com" \
--document 2025jan.private.key
# Solo después, activar en MTA
cp 2025jan.private.key /etc/postfix/dkim/El backup va ANTES de la activación, no después. Si algo falla en la activación, todavía tenés el backup.
Escenario 5: compromise del dominio
Probabilidad: baja pero catastrófica
Causa típica
Phishing exitoso a un admin del registrador del dominio, credenciales del DNS leakeadas, atacante que toma control del dominio y agrega registros maliciosos.
Tiempo de recovery sin plan
1-4 semanas (proceso legal para recuperar el dominio + arreglar daño hecho + reconstrucción de reputación).
Tiempo de recovery con plan
48-72 horas si hay procedimientos preparados.
Qué preparar
- 2FA obligatorio en registrador del dominio + en panel DNS (Cloudflare, Route 53)
- Domain lock activado (previene transferencias sin autenticación adicional)
- Backup periódico (export) de la configuración DNS completa
- Procedimiento documentado de respuesta: a quién contactar, cómo recuperar acceso, cómo evaluar daño
- Cuenta de email de respaldo para comunicaciones administrativas con registrador (no usar email del dominio comprometido)
Caso real: la fintech que perdió control de su dominio por 9 días
Fintech panameña con admin del DNS que cayó en phishing. Atacante tomó control de la cuenta Cloudflare, modificó MX records redirigiendo email hacia su servidor, suplantó al equipo de soporte por 6 días antes que el cliente se diera cuenta.
Sin plan de respuesta, la recuperación incluyó:
- 3 días para confirmar el incidente y contactar a Cloudflare con evidencia
- 2 días de proceso de Cloudflare para devolver acceso
- 4 días de auditoría forense para entender qué se modificó
Total: 9 días. Daño: imposible de cuantificar pero significativo (clientes que recibieron emails fraudulentos del “soporte”, pérdida de trust, costos de comunicación de incidente).
Post-incidente: 2FA hardware obligatorio (YubiKey) para admins, domain lock, monitoreo de cambios DNS con alertas.
Escenario 6: ataque dirigido de spam complaints
Probabilidad: baja pero impacto creciente
Causa típica
Competidor o actor malicioso que coordina marcado masivo de tus emails como spam (campañas en redes sociales pidiéndolo, scripts que generan reportes falsos).
Tiempo de recovery sin plan
3-8 semanas de reputación dañada.
Tiempo de recovery con plan
1-2 semanas con respuesta rápida.
Qué preparar
- Monitoreo automatizado de complaint rate (alerta si pasa de 0.10% en cualquier campaña)
- Capacidad de pausar campañas rápidamente
- Documentación de práctica de captación y consentimiento (para defender ante proveedores)
- Comunicación con proveedor (Mailchimp, Klaviyo) para respaldarte si hay reportes coordinados
Runbook mínimo viable
Documento de 5-10 páginas con secciones:
- Inventario: dominios, subdominios, IPs, proveedores, contratos, números directos de soporte
- Credenciales: dónde están los backups, quién tiene acceso, cómo solicitar acceso emergente
- Procedimientos por escenario: 6 escenarios x procedimiento paso a paso
- Comunicación: plantilla de mensaje a clientes, equipo interno, prensa si aplica
- Contactos clave: quién decide qué, escalation matrix
- Tests trimestrales: qué se prueba, cuándo, quién registra resultados
Mantener el runbook en formato que NO requiera acceso al email para consultar (Notion público con acceso de equipo, Google Drive con shortcut, archivo físico en caja fuerte para casos críticos).
Tests trimestrales: lo que NO se prueba se rompe en producción
Operaciones con runbook escrito pero sin tests trimestrales descubren en el incidente real que:
- La credencial DKIM “respaldada” en realidad estaba en una carpeta que ya no existe
- El contacto del proveedor en el runbook ya no trabaja ahí
- El export semanal automatizado falló silenciosamente hace 4 meses
Test trimestral mínimo (2-3 horas):
- Login al backup del password manager con cada credencial crítica
- Simulación de switch a IP backup (sin ejecutarla, validar procedimiento)
- Verificar que último backup de la lista existe y es íntegro
- Llamar a 3-5 contactos del runbook para verificar números actualizados
- Documentar tiempo total simulado de recovery
Tres casos reales de disaster recovery en Panamá
Caso 1: la fintech que perdió IP por compliance bug
Fintech panameña con IP dedicada para OTPs. Bug en su sistema generó 18.000 OTPs duplicados en una hora durante incidente operativo. Spamhaus detectó el spike, listó la IP en SBL en menos de 4 horas.
Sin plan: 6 horas para descubrir el listing (el equipo asumió que los emails llegaban). 12 horas más para identificar la causa raíz (el bug). 24 horas para tramitar delisting con Spamhaus.
Total: 42 horas de OTPs llegando degradados a usuarios, con tasa de abandono de transacciones del 19% durante el incidente.
Post-incidente: implementación de plan DR. Componentes:
- IP backup pre-warmeada con tráfico marketing al 15% de volumen
- Alerta automática si bounce rate de OTP pasa 1% en cualquier hora
- Procedimiento documentado de switch en 30 minutos
- Test trimestral del procedimiento
12 meses después, otro incidente similar: switch a IP backup en 28 minutos, tramitación de delisting en paralelo, impacto operativo medible casi nulo.
Caso 2: el e-commerce que perdió control de DNS
Retailer panameño cuyo admin del DNS cayó en phishing. Atacante modificó MX records redirigiendo email a su servidor por 36 horas antes de detección.
Daño durante el incidente:
- 8.400 emails de confirmación de pedidos no llegaron a clientes
- 23 cancelaciones de pedido por “no recibí confirmación”
- 14 clientes recibieron emails fraudulentos del “soporte”
- Pérdida de revenue inmediata: USD 12.400
- Daño reputacional: 47 reseñas negativas en 3 semanas siguientes
Recovery:
- Día 1-2: contactar Cloudflare con evidencia de takeover
- Día 3-5: Cloudflare devolvió acceso, equipo restauró DNS correcto
- Día 6-14: comunicación con clientes afectados, refunds para los 23 cancelados
- Semanas 3-8: recuperación reputacional con publicación de incidente y medidas correctivas
Post-incidente:
- 2FA con hardware key (YubiKey) obligatorio para admins
- Domain lock activado en Cloudflare
- Monitoreo automatizado de cambios DNS con alertas a 3 personas
- Revisión semanal de configuración DNS
Caso 3: la operación que perdió toda su lista de email
Operación de servicios profesionales con 32.000 contactos en Mailchimp. Empleado nuevo, en proceso de cleanup, ejecutó “delete all subscribers” en lugar de “delete inactive subscribers”. Acción confirmada con popup que el empleado no leyó.
Mailchimp permite restore de listas dentro de 30 días para clientes en plan paid. La operación tenía plan paid, restore exitoso en 2 horas.
PERO: durante esas 2 horas:
- Una campaña programada se envió a la lista vacía (no a nadie)
- Automaciones de carrito abandonado no triggearon
- 4 clientes que pidieron unsubscribe en esas 2 horas tuvieron experiencia rota
Recovery total: 2 horas con Mailchimp restore + 24 horas para validar integridad + 1 semana de monitoreo intensivo.
Post-incidente, implementaron:
- Backup semanal automatizado a S3 propio (no solo dentro de Mailchimp)
- Permisos restringidos: solo 2 personas pueden ejecutar acciones destructivas
- Confirmación adicional manual para acciones que afectan >1.000 contactos
- Capacitación trimestral del equipo en procedimientos críticos
El runbook de DR en formato práctico
Plantilla del runbook básico que aplica a operaciones medianas:
Sección 1: Información de contacto crítica
== Proveedores de email ==
Mailchimp Account ID: [ID]
Support: [email protected] / +1-678-999-0000 (premium phone)
Account Owner: [persona] / [email] / [teléfono directo]
Postmark Account: [ID]
Support: [email protected] (~4h response)
Account Owner: [persona]
== DNS / Registrador ==
Cloudflare Account: [email] (2FA con YubiKey)
Backup admin: [email] (YubiKey backup en caja fuerte oficina)
== IPs y servidores ==
IP principal: 190.83.124.56 (PowerMTA, server01.empresa.com)
IP backup: 190.83.124.57 (warmup constante, server02.empresa.com)
SSH access: documentado en password manager vault "Infrastructure"Sección 2: Procedimientos por escenario
== Escenario A: IP en blocklist ==
1. Confirmar listing:
- mxtoolbox.com/blacklists
- spamhaus.org/query/ip/XXX.XXX.XXX.XXX
2. Switch a IP backup (30 minutos):
- Login a PowerMTA admin (credentials: vault Infrastructure)
- Configuración → VirtualMTA → cambiar source IP de "production" a 190.83.124.57
- Restart PowerMTA: sudo systemctl restart pmta
- Validar: enviar test email a buzón propio, confirmar header Received
3. Tramitar delisting:
- Spamhaus: spamhaus.org/lookup/ip/XXX (formulario)
- SpamCop: spamcop.net (auto-delist 24-48h sin nuevos hits)
- Barracuda: barracudacentral.org/rbl/removal-request
4. Comunicación:
- Slack #ops: "Incidente IP principal en blocklist. Switch a backup activo."
- Email al equipo de Liderazgo si afecta SLA con clientesSección 3: Recursos críticos
== Backups de credenciales ==
DKIM private keys:
- Vault: 1Password "DKIM-empresa.com"
- Backup encriptado: /encrypted-backup/dkim/ en server02
- USB físico encriptado: caja fuerte oficina
DNS configuration:
- Export semanal automatizado: s3://empresa-dr/dns-backups/
- Última verificación: [fecha]
Lista de contactos email:
- Export diario automatizado: s3://empresa-dr/contacts/
- Retención: 12 meses
- Última validación de restore: [fecha]Sección 4: Calendario de tests
== Tests trimestrales ==
Q1 [año]:
- [ ] Verificar acceso a todos los vaults
- [ ] Simular switch a IP backup
- [ ] Restore prueba de lista desde backup S3
- [ ] Llamar 3 contactos del runbook
Q2 [año]:
- [ ] Verificar backups DKIM en 3 ubicaciones
- [ ] Test de procedimiento DNS recovery (simulación)
- [ ] Auditar permisos de acceso a plataformasEste runbook se mantiene en formato Notion compartido + PDF impreso en caja fuerte de la oficina. Acceso accesible aunque el dominio email esté caído.
Las prioridades de inversión en DR según madurez
No todas las operaciones necesitan DR enterprise. Priorización por etapa:
Operación temprana (MRR <USD 5K)
Mínimo viable:
- Export semanal manual de lista a Google Drive personal
- Credenciales DKIM en password manager personal (1Password, Bitwarden)
- 2FA en todos los servicios críticos
- Documento en Google Docs con contactos clave
Costo: USD 0-50/mes. Tiempo de implementación: 4-8 horas inicial.
Operación creciente (MRR USD 5-30K)
Adicional:
- Backup automatizado semanal a S3 o equivalente
- Password manager team (compartido con 2-3 personas)
- IP backup pre-warmeada al 10%
- Runbook escrito con 3-4 escenarios principales
- Test trimestral del runbook
Costo: USD 100-300/mes. Tiempo: 1 semana inicial + 4h/trimestre mantenimiento.
Operación madura (MRR >USD 30K)
Adicional:
- Infraestructura completamente duplicada
- Multi-region/multi-IP active-active
- DR runbook completo con 6 escenarios + tests trimestrales obligatorios
- Insurance de cyber/data breach si aplica
- DPO o responsable de continuidad de negocio designado
Costo: USD 800-3.000/mes. Tiempo: 2-4 semanas inicial + 1 día/mes mantenimiento.
Resumen operativo
Tres acciones para implementar en los próximos 30 días:
-
Hacer inventario completo de infraestructura crítica de email (dominios, IPs, proveedores, credenciales). Si tarda más de 2 horas en hacerse, hay gaps de visibilidad.
-
Implementar backup automatizado semanal de la lista de contactos a storage independiente de la plataforma de email. Sin esto, la plataforma es single point of failure.
-
Documentar runbook con los 6 escenarios y agendar test trimestral. La hoja de papel con procedimientos vale más que cualquier infraestructura redundante si el equipo no sabe usarla.
DR de email no es tarea de IT solamente; es responsabilidad operativa que combina infraestructura, procesos y disciplina. Las operaciones que la toman en serio recuperan en horas; las que no, recuperan en semanas con daño cumulativo.