Runbook de incidentes de entregabilidad de correo: cómo responder ante una caída repentina

Un runbook de incidentes de entregabilidad de correo es el plan escrito que sigue su equipo cuando la entrega cae de repente: los rebotes se disparan, el correo se acumula en las colas, las quejas aumentan o los clientes dicen que los mensajes no llegan. Tener los pasos definidos de antemano importa porque la primera hora es cuando la mayor parte del daño se contiene o se agrava. Esta guía nos ofrece un runbook práctico: un triaje de 30 minutos, una tabla de decisión, evidencias que reunir, pasos de recuperación, plantillas de mensajes, un formato de revisión y salvaguardas.

Qué se considera un incidente de entregabilidad

No toda caída es un incidente. El tráfico normal varía con el calendario, la audiencia y el contenido. Llamamos incidente a una situación en la que una métrica clave sale rápidamente de su rango normal y la causa no es evidente: tasa de rebote, volumen de diferimientos, tasa de quejas, tiempo de entrega de los mensajes importantes o ubicación en la bandeja de entrada de un proveedor de correo importante. Recurrir al runbook pronto cuesta poco. Esperar cuesta reputación.

Escriba de antemano sus niveles de severidad. Funciona bien un esquema sencillo de tres niveles: un elemento de vigilancia de nivel bajo que supervisa una persona, un incidente estándar con un responsable designado y actualizaciones cada hora, y un incidente crítico en el que se ve afectado el correo transaccional, como los restablecimientos de contraseña o los recibos de pago, o en el que una credencial puede estar comprometida. Las definiciones siguientes son ejemplos que debe adaptar, no un estándar.

Nivel	Ejemplo de disparador (ajústelo a su tráfico)	Respuesta
Vigilancia	Una métrica sale de su rango habitual en un solo envío	El responsable lo revisa en una hora y anota sus hallazgos
Incidente	Una métrica se duplica respecto de su línea base, o un proveedor importante difiere o rechaza una gran parte del correo	Abrir el runbook, nombrar un responsable, pausar el envío masivo no crítico, informar a los stakeholders cada hora
Crítico	Correo transaccional retrasado o rechazado, sospecha de credenciales comprometidas o inclusión en una lista de bloqueo de una IP o dominio de envío principal	Runbook completo, los cuatro roles cubiertos, actualización cada 30 minutos hasta lograr la contención

Los primeros 30 minutos: triaje y contención

El objetivo de la primera media hora no es encontrar la causa raíz. Es evitar que el daño crezca y clasificar el problema lo suficiente como para saber dónde buscar. Siga estos pasos en orden y registre la hora de cada uno.

1. Minutos 0 a 5: declarar. Abra un canal compartido, nombre al responsable del incidente y anote la hora en que se notó el problema por primera vez y la hora en que probablemente comenzó. Use UTC en todas las marcas de tiempo para que los registros, los informes y las personas de distintos lugares coincidan.
2. Minutos 5 a 10: proteger el correo transaccional. Confirme que los restablecimientos de contraseña, los códigos de un solo uso y los recibos se siguen entregando enviando unos mensajes de prueba a buzones que usted controle en los principales proveedores. Si fallan, trate el incidente como crítico.
3. Minutos 10 a 15: pausar o limitar el resto. Pause las campañas promocionales, los boletines y cualquier automatización programada que pueda esperar. En los flujos que no pueda pausar por completo, reduzca la velocidad de envío. No elimine todavía el correo en cola, porque es evidencia.
4. Minutos 15 a 25: clasificar. Lea los recuentos de rebotes, diferimientos y quejas por proveedor de correo del último día, comparados con la semana anterior. Use la tabla de decisión siguiente para elegir la familia de causas más probable.
5. Minutos 25 a 30: asignar el trabajo y enviar la primera actualización. Dé a cada investigador una pregunta concreta y envíe una breve actualización interna con los hechos conocidos hasta el momento y la hora de la siguiente.

Mantener el correo transaccional en su propio flujo, dominio y grupo de IP facilita mucho este triaje, porque se pueden pausar las promociones sin tocar los recibos. Si aún no lo ha hecho, consulte cómo separar los flujos de correo transaccional y de marketing y conviértalo en un proyecto cuando termine el incidente.

Tabla de decisión de síntoma a causa

Use esta tabla para convertir lo que ve en lo primero que debe comprobar. Enumera causas probables, no certezas, y varias pueden darse a la vez. La primera columna es lo que muestran sus paneles. La segunda indica qué pregunta hacer. La tercera señala la comprobación que confirma o descarta la causa.

Síntoma	Alcance	Causas probables	Primeras comprobaciones
Pico de rebotes (rechazos 5xx)	Todos los proveedores, a partir de un momento exacto	Autenticación rota, registro DNS vencido o eliminado, credencial incorrecta, envío desde un dominio no verificado	Registros DNS de SPF, DKIM y DMARC; cambios recientes de DNS o de proveedor; texto de error en las respuestas de rebote
Pico de rebotes (rechazos 5xx)	Un proveedor	Bloqueo por política o inclusión en una lista de reputación en ese proveedor, cambio repentino de volumen o de contenido	Texto del rebote de ese proveedor, sus datos de postmaster, historial reciente de envíos a ese proveedor
Pico de rebotes con errores de usuario desconocido	Sobre todo una campaña o importación	Direcciones obsoletas, compradas o con errores de escritura añadidas a una lista	Origen de la lista, antigüedad de las direcciones, resultados de la validación
Pico de diferimientos (4xx)	Uno o dos proveedores	Limitación de velocidad, primeras dudas sobre la reputación, demasiadas conexiones	Texto del diferimiento, velocidad de envío y concurrencia actuales, antigüedad de la cola
Pico de diferimientos (4xx)	Todos los proveedores	Problemas de red o de DNS de su lado, fallos de TLS, límites de recursos en los servidores de envío	Tiempos de espera agotados y errores de TLS en los registros, resolución DNS desde los hosts de envío
Pico de quejas	Una campaña o segmento	Audiencia inesperada, origen de suscripción poco claro, enlace de baja difícil de encontrar	Definición del segmento, origen de la suscripción, visibilidad del enlace de baja, datos del bucle de retroalimentación
Caen aperturas y clics, rebotes estables	Un proveedor	Correo que pasa a la carpeta de spam sin ningún rechazo	Datos de postmaster, resultados de bandejas de prueba con semillas o paneles, cambios recientes de contenido o de volumen
Caen aperturas y clics, rebotes estables	Todos los proveedores	Problemas con el dominio de seguimiento, bloqueo de imágenes, enlaces rotos o un cambio en la medición	Certificado y DNS del dominio de seguimiento, pruebas de enlaces, cualquier cambio reciente de plantilla
Correo de fuentes desconocidas que pasa por su dominio en los informes DMARC	Aparece en los informes agregados	Suplantación, o una herramienta de terceros olvidada que envía en su nombre	Fuentes de los informes agregados de DMARC, lista de remitentes aprobados, registros de acceso de sus credenciales de envío

Dos patrones merecen especial cuidado. Un aumento repentino de volumen que usted no programó, junto con un pico de quejas, puede indicar una cuenta comprometida o una clave filtrada que envía en su nombre. Eso es primero un evento de seguridad y después un evento de entregabilidad. Y un problema en un solo proveedor suele ser una cuestión de reputación en ese proveedor, mientras que un problema en todos los proveedores que comenzó en un minuto exacto suele apuntar a algo que usted cambió o que expiró. Para profundizar en cada familia, nuestra guía sobre los códigos de rebote SMTP explica cómo leer las respuestas 4xx y 5xx, y la lista de verificación para solucionar problemas de la carpeta de spam cubre paso a paso los problemas de ubicación.

Evidencias que reunir antes de cambiar nada

Las evidencias desaparecen rápido. Los registros rotan, las colas se vacían y los informes se sobrescriben. Primero reúna, después corrija. Guarde todo en una carpeta compartida con la hora de inicio del incidente en su nombre y anote la zona horaria de cada exportación.

Evidencia	Qué nos dice	Cómo obtenerla
Registros de eventos de los últimos 7 días	Recuentos de aceptados, diferidos, rebotados y con queja por proveedor, flujo y campaña	Exportar desde su panel de MigoSMTP, la API o los webhooks; consulte su cuenta de MigoSMTP o la documentación de la API para conocer las opciones exactas
Respuestas de rebote y de diferimiento sin procesar	La redacción exacta que usan los proveedores para explicar el problema	Copiar una muestra de cada mensaje distinto, con el código de estado mejorado, por proveedor
Encabezados completos de mensajes de prueba entregados y enviados a spam	Resultados de autenticación, enrutamiento y cualquier veredicto de filtros	Enviar pruebas a buzones que usted controle y guardar el código fuente original de cada una
Informes agregados de DMARC	Qué fuentes envían en nombre de su dominio y si SPF y DKIM pasan y se alinean	Obtener los informes de los últimos 7 a 14 días y compararlos con el periodo anterior
Datos de postmaster de los proveedores de correo	Señales de reputación de dominio e IP, tasa de spam y resultados de autenticación cuando el proveedor los publica	Capturar o exportar los paneles de los dominios afectados
Verificaciones de listas de bloqueo y de DNS	Si las IP o los dominios de envío figuran en alguna lista y si los registros son correctos hoy	Consultar las principales listas de bloqueo en las que confía y resolver sus registros SPF, DKIM, DMARC, DNS inverso y de seguimiento
Historial de cambios	Qué se desplegó, editó o modificó en torno a la hora de inicio	Preguntar a todo el equipo: versiones de código, ediciones de DNS, herramientas nuevas, importaciones de listas, cambios de plantillas

Las comprobaciones rápidas de DNS se pueden ejecutar desde cualquier terminal. Los comandos siguientes usan un dominio y un selector inventados para mostrar el patrón; sustitúyalos por sus propios valores.

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

Para leer los encabezados, siga nuestra guía sobre cómo leer los encabezados del correo para depurar la entrega y la autenticación. Para los paneles de reputación, el artículo sobre Google Postmaster Tools explica qué significan las señales y cómo configurarlas antes de necesitarlas.

Pasos de contención y recuperación

La contención detiene el daño. La recuperación devuelve el volumen de forma segura. Son fases distintas, y mezclarlas es como los equipos vuelven a encender el fuego. No reanude los flujos pausados solo porque las métricas se vean mejor durante una hora.

Acciones de contención según la causa

• Fallo de autenticación: restaure o corrija el registro DNS, confirme con un mensaje de prueba que SPF, DKIM y DMARC pasan y se alinean, y solo entonces reanude el tráfico.
• Credencial o cuenta comprometida: desactive y sustituya la credencial, revise qué se envió, avise al propietario de la cuenta y siga su proceso de seguridad. La rotación de claves se trata en nuestra guía sobre seguridad de claves de API.
• Lista o segmento defectuoso: elimine el segmento, suprima las direcciones que rebotaron o se quejaron y rastree cómo entraron esas direcciones en la lista para que no vuelva a ocurrir.
• Problema de contenido o de enlaces: retire la plantilla, elimine el enlace o adjunto sospechoso y pruebe la versión corregida antes de enviarla de nuevo.
• Inclusión en una lista de bloqueo: averigüe primero por qué se produjo la inclusión, corrija esa causa y luego siga el proceso de exclusión de la lista concreta. Nuestra guía de exclusión de listas de bloqueo explica los pasos.
• Limitación de velocidad del proveedor: reduzca la concurrencia y los mensajes por conexión para ese proveedor y deje que la cola se vacíe al ritmo que permita.

Un plan de recuperación por etapas

1. Reanude primero los suscriptores más comprometidos y más recientes, con una fracción del volumen normal.
2. Mantenga cada etapa durante al menos un día completo de respuesta de los proveedores, y más tiempo en los proveedores que informan los datos con retraso.
3. Aumente el volumen solo mientras las tasas de rebote, diferimiento y quejas se mantengan en su línea base previa al incidente o por debajo.
4. Si una señal empeora, retroceda a la etapa anterior en lugar de mantener la posición.
5. Reincorpore los segmentos más fríos al final y considere una pasada de reactivación o la eliminación de los contactos que no han interactuado durante mucho tiempo.
6. Declare la recuperación solo después de que las señales se mantengan saludables con el volumen completo durante un periodo acordado al comienzo.

La misma rampa cuidadosa se describe para la infraestructura nueva en nuestro artículo sobre calentamiento, y aquí también se aplica. Piense en la recuperación como una versión reducida del calentamiento, que usa primero su mejor tráfico.

Plantillas de comunicación

Una buena comunicación reduce la cantidad de preguntas que interrumpen a quienes están resolviendo el problema. Mantenga los mensajes breves, factuales y regulares. Indique qué se sabe, qué no, qué estamos haciendo y cuándo llegará la siguiente actualización. Evite culpar y evite prometer una hora de solución que no puede controlar. Adapte el texto inventado de abajo a su propio tono.

Actualización interna para stakeholders

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

Mensaje para soporte y equipos de atención al cliente

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

Un ejemplo práctico con cifras inventadas

Un equipo envía normalmente unos 200 000 correos promocionales y 15 000 correos transaccionales al día. Su tasa de rebote normal ronda el 0,6 por ciento y su tasa de quejas normal ronda el 0,05 por ciento. Un martes a las 09:00 UTC sale una campaña a 80 000 contactos. A las 09:40 el panel muestra 2400 rebotes duros de esa campaña, es decir, un 3 por ciento, y un proveedor grande está difiriendo la mayoría de los mensajes restantes.

A las 09:45 el investigador de guardia abre el runbook. A las 09:55 el flujo promocional está en pausa y se ha confirmado la entrega de los recibos de prueba. La tabla de decisión apunta a un pico de rebotes con errores de usuario desconocido, concentrado en una campaña. Al revisar el historial de la lista se descubre que 30 000 de las 80 000 direcciones se importaron dos días antes desde una antigua hoja de cálculo de un evento y nunca se validaron. Unos 2000 de los 2400 rebotes provienen de esa importación.

La contención es sencilla: suprimir las direcciones rebotadas, retirar de todos los segmentos la importación sin validar y pasarla por validación antes de volver a usarla. El equipo reanuda el flujo al 10 por ciento del volumen normal, dirigido a sus contactos más comprometidos, a la mañana siguiente, lo sube al 25, al 50 y al 100 por ciento durante los días siguientes mientras la tasa de rebote se mantiene por debajo del 1 por ciento, y confirma la recuperación tras tres días limpios con el volumen completo. La revisión añade una salvaguarda: toda importación nueva debe superar la validación y mantenerse fuera de las campañas hasta que una persona designada la apruebe. El costo del incidente fue un día de pausa y algunas campañas retrasadas, en lugar de una larga reparación de la reputación.

Salvaguardas y umbrales de alerta que debe ajustar

La mayoría de los incidentes los descubren los clientes porque nadie vigilaba el número adecuado. Las salvaguardas adelantan el descubrimiento. Los valores siguientes son ejemplos elegidos para mostrar la forma de una alerta sensata. No son estándares universales, y los números adecuados dependen de su audiencia, sus proveedores y su historial. Mida su propia línea base durante varias semanas y luego fije los umbrales en relación con ella. Consulte las directrices vigentes para remitentes de los proveedores de correo que le interesen para conocer los límites publicados, y lea nuestra guía sobre las métricas que conviene medir para decidir qué seguir.

Señal	Ejemplo de alerta (ajústela a su línea base)	Acción automática sugerida
Tasa de rebotes duros por campaña	Advertir por encima de 2 veces su línea base, detener por encima de 4 veces, o cuando se supere su propio límite absoluto	Pausar la campaña y avisar al responsable
Tasa de quejas por proveedor	Advertir a la mitad del límite que publica un proveedor, avisar por guardia a tres cuartos del mismo	Pausar el segmento y revisar el origen de la suscripción
Proporción de diferimientos por proveedor	Advertir cuando los diferimientos superen una proporción que normalmente nunca ve, por ejemplo 10 por ciento durante 15 minutos	Reducir la velocidad de envío a ese proveedor
Antigüedad de la cola del correo transaccional	Advertir cuando el mensaje más antiguo espere más de unos pocos minutos	Avisar por guardia al investigador técnico
Volumen de envío	Advertir cuando el volumen por hora supere un múltiplo del habitual para esa hora	Comprobar si hay credenciales comprometidas o procesos descontrolados
Estado del DNS y de los certificados	Comprobación diaria de que los registros SPF, DKIM, DMARC y de seguimiento se resuelven; advertir semanas antes del vencimiento de un certificado	Abrir un ticket para corregirlo antes de que falle
Nuevas importaciones de listas	Bloquear su uso en campañas hasta que se validen y se aprueben	Exigir una aprobación nominal en el flujo de trabajo

Además de las alertas, añada salvaguardas estructurales: flujos separados, límites de envío por campaña, una retención para las fuentes nuevas y un responsable permanente para cada dominio e IP. También importa el comportamiento de velocidad y reintentos, que se explica en la guía sobre límites de velocidad, reintentos y backoff de nuestro centro de ayuda.

Roles de guardia

Un runbook funciona mejor cuando los roles se conocen antes de que suene el buscapersonas. En una empresa pequeña una persona puede ocupar varios puestos, pero cada puesto debe tener una persona designada y un suplente.

Rol	Responsabilidad	Lo que no hace
Responsable del incidente	Declara y cierra el incidente, toma decisiones, fija las horas de actualización	Realizar personalmente todas las investigaciones
Investigador técnico	Lee registros, encabezados y DNS, prueba correcciones, propone la contención	Cambiar la configuración de producción sin avisar al responsable
Responsable del envío o de la campaña	Sabe qué se envió, a quién y por qué; pausa y reanuda los flujos	Reanudar el tráfico sin el acuerdo del responsable
Encargado de comunicación	Envía las actualizaciones a stakeholders y a soporte, lleva la cronología	Especular sobre las causas

Revisión posterior al incidente

Realice la revisión en pocos días, mientras los recuerdos y los registros siguen frescos. Manténgala sin culpas: el objetivo es encontrar qué del sistema dejó pasar el problema, no quién pulsó el botón. Para la mayoría de los incidentes basta un registro de una página.

1. Resumen: qué ocurrió y cuál fue el impacto, en dos o tres frases.
2. Cronología: cuándo comenzó, cuándo se detectó, cuándo se contuvo, cuándo se recuperó. Todo en UTC.
3. Causa raíz y factores contribuyentes: la causa directa y las brechas que permitieron que ocurriera o retrasaron la detección.
4. Qué salió bien: los pasos que funcionaron y que conviene conservar.
5. Acciones: cada una con un responsable y una fecha, como una nueva alerta, un paso de validación, una comprobación de DNS o un flujo de aprobación modificado.
6. Seguimiento: una fecha para confirmar que las acciones están completadas y que las métricas son estables.

Lista de verificación del incidente

1. Incidente declarado, responsable designado, hora de inicio registrada en UTC.
2. Correo transaccional verificado con mensajes de prueba y mantenido en su propio flujo.
3. Flujos masivos y promocionales no críticos pausados o limitados.
4. Síntoma clasificado con la tabla de decisión: rebote, diferimiento, queja o caída de interacción; un proveedor o todos.
5. Evidencias guardadas: registros de eventos, respuestas sin procesar, encabezados, informes DMARC, datos de postmaster, verificaciones de listas de bloqueo y de DNS.
6. Historial de cambios recopilado de todo el equipo.
7. Causa corregida y verificada con un mensaje de prueba antes de reanudar nada.
8. Recuperación por etapas a partir de los contactos más comprometidos con volumen reducido, con criterios de aprobación acordados.
9. Actualizaciones a stakeholders y a soporte enviadas según el calendario.
10. Revisión realizada, acciones asignadas, salvaguardas y alertas actualizadas.

MigoSMTP ofrece envío, registros y eventos que ayudan en varios de estos pasos. Consulte su cuenta de MigoSMTP o la documentación de la API para conocer los detalles exactos de los informes, webhooks y controles disponibles para usted.

Lecturas adicionales y fuentes

• RFC 5321: Simple Mail Transfer Protocol (códigos de respuesta y comportamiento de reintento)
• RFC 3463: Enhanced Mail System Status Codes
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 6591: Authentication Failure Reporting Using the Abuse Reporting Format
• Google: Email sender guidelines