Mautic + KumoMTA: el stack de email independiente que sustituye a tu ESP

La mayoría de los equipos no abandonan su ESP porque el marketing haya fallado. Lo abandonan porque lo ha hecho la infraestructura: IPs compartidas que hunden la entregabilidad sin avisar, precios que escalan más rápido que los ingresos y cero visibilidad sobre lo que ocurre realmente a nivel de MTA. Si envías más de 150.000 correos al mes y ya has empezado a valorar el coste de la infraestructura dedicada, el stack Mautic KumoMTA de infraestructura de correo es la alternativa seria. Esta guía cubre la arquitectura, la secuencia de despliegue y las partes que te harán daño si las haces mal.

Qué necesitas antes de empezar

Esto no es un proyecto de fin de semana. Antes de comprometerte con el stack, confirma que tienes lo siguiente en su sitio:

• Volumen de envío: al menos 150.000 correos al mes para justificar el trabajo extra de calentar IPs dedicadas
• Responsabilidad técnica: un perfil de sysadmin o DevOps que pueda gestionar servidores Linux, registros DNS y configuración SMTP
• Lista limpia: listas de supresión exportadas de tu ESP actual, con rebotes duros y bajas marcadas
• Dominios listos: dominio(s) de envío con registros SPF, DKIM y DMARC que puedas editar, no bloqueados dentro de una plataforma
• Asignación de IPs: IPs dedicadas aprovisionadas a través de tu proveedor de hosting (Hetzner, OVH o un proveedor cloud con soporte de registros PTR)
• Base de monitorización: tasas actuales de ubicación en bandeja de entrada y de rebote de tu ESP actual, para tener una referencia

La ventana de migración realista es de 4 a 8 semanas para un cambio completo, más si tu lista es grande o tu dominio arrastra una deuda de reputación que haya que resolver.

Paso 1: entiende por qué KumoMTA en lugar de Postfix o PowerMTA

Postfix funciona bien para correo transaccional a bajo volumen. No funciona bien cuando necesitas gestión de colas por campaña, reglas de limitación por dominio o registros de entrega estructurados que alimenten una capa de inteligencia de entregabilidad. PowerMTA ha sido el estándar empresarial durante años, pero su modelo de licencias es caro y su sintaxis de configuración está anticuada.

KumoMTA está escrito en Rust, es open source bajo licencia Apache 2.0 y se ha construido desde cero para envíos masivos de alto rendimiento. Las diferencias técnicas clave que importan en producción:

• Scripting de políticas basado en Lua: defines la lógica de enrutado, las reglas de limitación y el comportamiento de reintento por ISP en scripts Lua en lugar de archivos de configuración estáticos. Esto significa que puedes cambiar el comportamiento en tiempo de ejecución sin reiniciar el MTA.
• Registro estructurado en JSONL: cada evento de entrega (inyección, intento, rebote, aplazamiento) se registra en JSON estructurado. Esto alimenta directamente una capa de inteligencia de entregabilidad sin un paso de parseo.
• Pooling de conexiones y gestión de pools de salida: puedes asignar IPs concretas a flujos de tráfico concretos (transaccional frente a promocional, por ejemplo) con unas pocas líneas de Lua.

Una asignación básica de pool de salida en la política Lua de KumoMTA se ve así:

kumo.on('get_egress_pool', function(domain, tenant)
  if tenant == 'promotional' then
    return 'pool-promo'
  end
  return 'pool-transactional'
end)

Ese es el tipo de control de enrutado que Postfix no puede darte sin parchearlo a fondo.

Paso 2: despliega Mautic como capa de automatización y CRM

Mautic es la plataforma de automatización de marketing open source que se encarga de la gestión de contactos, la segmentación, la lógica de campañas y la programación de envíos. En este stack, Mautic no se encarga de la entrega: la delega en KumoMTA mediante retransmisión SMTP. Esa separación es intencionada e importante.

Los pasos de despliegue de Mautic en un entorno de producción:

1. Instálalo en un servidor dedicado (mínimo 4 vCPU y 8 GB de RAM para listas de hasta 500.000 contactos)
2. Configura una base de datos MySQL o MariaDB dedicada, no compartida con ninguna otra aplicación
3. Configura mailer_transport como smtp y apúntalo a tu host de retransmisión KumoMTA
4. Activa la cola de Mautic (RabbitMQ o cola de base de datos) para que los envíos se agrupen y se dosifiquen, en lugar de dispararse todos a la vez
5. Configura dominios de seguimiento (de clics y de aperturas) en un subdominio separado de tu dominio de envío
6. Configura tareas cron para los scripts de reconstrucción de segmentos, disparo de campañas y procesamiento de la cola de envío de Mautic

Hay algo que pilla desprevenidos a muchos equipos: la programación cron por defecto de Mautic envía todos los correos en cola inmediatamente cuando se dispara el cron de envío. Con volumen alto, esto crea picos de inyección que tensionan la cola del MTA. Configura mautic:emails:send --batch-limit=500 y programa el cron cada 5 minutos para suavizar el ritmo de inyección.

Paso 3: añade VDMS como capa de inteligencia de entregabilidad

KumoMTA te da registros estructurados. VDMS (Virtual Deliverability Management System) convierte esos registros en señales sobre las que actuar: ubicación en bandeja de entrada en tiempo real por ISP, clasificación de rebotes, exposición a spam traps y puntuación de reputación de IP. Sin esta capa, vuelas a ciegas sobre una infraestructura dedicada que no tiene la red de seguridad de la reputación compartida.

VDMS se integra directamente con el flujo de registros JSONL de KumoMTA. La arquitectura se ve así:

• KumoMTA escribe los eventos de entrega en un archivo de registro local o los empuja a una cola de mensajes
• Un shipper de registros (Filebeat o un consumidor propio) reenvía los eventos al endpoint de ingesta de VDMS
• VDMS clasifica los rebotes, sigue las tendencias de reputación a nivel de dominio y lanza alertas cuando una IP de envío cruza un umbral
• Las reglas de enrutado de la política Lua de KumoMTA se pueden actualizar entonces a partir de las señales de VDMS; por ejemplo, reducir la tasa de envío a un ISP concreto cuando la tasa de aplazamiento supera el 5 %

La inteligencia de entregabilidad a nivel de MTA es lo que separa este stack de simplemente autoalojar el equivalente de Mailchimp: tienes los datos y tienes los controles para actuar sobre ellos en el mismo sistema.

Paso 4: configura la lógica de enrutado multi-MTA

Para volúmenes de envío por encima de 1 millón de correos al mes, una sola instancia de KumoMTA se convierte en un punto único de fallo y en un techo de rendimiento. La arquitectura de producción ejecuta varios nodos MTA detrás de una capa de enrutado que asigna el tráfico según el tipo de campaña, el dominio de destino y el estado de reputación de la IP.

La lógica de enrutado funciona así:

• Mautic asigna una cabecera tenant a cada mensaje saliente (promocional, transaccional, reactivación)
• La política Lua de KumoMTA lee la cabecera tenant y asigna el mensaje al pool de salida correspondiente
• Cada pool de salida se corresponde con un conjunto de IPs de un nodo MTA concreto
• Si un nodo se cae, el tráfico se enruta automáticamente al pool del nodo secundario mediante la lógica de la política

Aquí es donde la diferencia entre operación autogestionada y operación gestionada se vuelve concreta. Escribir y mantener estas políticas Lua, mantenerlas actualizadas a medida que cambian las reglas de limitación de los ISP y monitorizar la salud de cada nodo exige atención operativa dedicada, no una configuración de una sola vez.

Sendability, la Agentic Email & CRM Platform que gestiona infraestructura de envío dedicada para más de 1.000 millones de correos al mes en más de 10 países, ha documentado que los equipos que migran de infraestructura ESP compartida a un stack Mautic-KumoMTA suelen ver una mejora del 15 al 25 % en la ubicación en bandeja de entrada durante los primeros 60 días, siempre que el calentamiento de IP se ejecute correctamente y la higiene de la lista se aplique antes de la migración, no después.

Paso 5: ejecuta el plan de calentamiento de IP

El calentamiento es donde más fallan las migraciones. Las IPs nuevas no tienen historial de envío. Los sistemas de filtrado de Gmail, Yahoo y Microsoft tratan con recelo las IPs desconocidas hasta que se establece un patrón de interacción limpia.

Un calendario de calentamiento que funciona para una sola IP:

Semana	Volumen diario	Segmento que usar
1	500 a 1.000	Contactos con más interacción (abrieron en los últimos 30 días)
2	2.000 a 5.000	Con interacción en los últimos 60 días
3	10.000 a 20.000	Con interacción en los últimos 90 días
4	más de 50.000	Lista activa completa, suprimiendo los contactos sin interacción

Según el Inbox Placement Benchmark Report de 2024 de Validity, los remitentes con tasas de ubicación en bandeja superiores al 90 % comparten un comportamiento constante: suprimen los contactos sin interacción en los 180 días previos antes de empezar cualquier calentamiento de IP nuevo. Saltarse ese paso es la causa más habitual de que el calentamiento fracase.

Errores habituales

Enviar a toda tu lista el primer día

Esto quema la IP antes de que tenga ninguna reputación. Los ISP ven un pico repentino de volumen desde una IP desconocida y aplazan o bloquean. La recuperación lleva semanas.

Saltarse DMARC en modo de aplicación

Empezar con p=none está bien para monitorizar. Dejarlo ahí de forma permanente significa que no estás protegido contra la suplantación, y los requisitos para remitentes de 2024 de Google y Yahoo obligan de hecho a aplicar la política a los remitentes masivos.

Tratar Mautic como un sustituto de ESP de arrastrar y soltar

La interfaz de Mautic es funcional, pero no está pulida. Los equipos que esperan una UX del nivel de Klaviyo se frustrarán. El valor está en la arquitectura y el control, no en la interfaz. Si ese equilibrio no encaja con tu equipo, un despliegue gestionado de Mautic con soporte operativo cambia mucho el panorama.

Ignorar el procesamiento de los bucles de retroalimentación de KumoMTA

Los ISP principales envían bucles de retroalimentación de quejas (FBL) a los remitentes registrados. Si no registras tus IPs en el programa FBL de Yahoo y no configuras KumoMTA para procesar los mensajes FBL entrantes, las quejas se acumulan en silencio y tu reputación se degrada sin ninguna señal visible hasta que ya es demasiado tarde.

Lista de comprobación de la infraestructura de migración

• [ ] IPs dedicadas aprovisionadas con registros PTR (DNS inverso) correctos
• [ ] Registro SPF actualizado para incluir las nuevas IPs de envío
• [ ] Claves DKIM generadas y publicadas en DNS (mínimo 2048 bits)
• [ ] Política DMARC configurada al menos en p=quarantine con una dirección de informes
• [ ] KumoMTA instalado y política Lua base configurada
• [ ] Mautic conectado al relay de KumoMTA mediante SMTP autenticado
• [ ] Tareas cron de Mautic configuradas y probadas
• [ ] Ingesta de registros de VDMS verificada con envíos de prueba
• [ ] Registros FBL enviados a Yahoo y a cualquier otro programa de ISP
• [ ] Lista de supresión del ESP anterior importada en Mautic
• [ ] Calendario de calentamiento documentado y aplicado mediante filtros de segmento en Mautic
• [ ] Alertas de monitorización configuradas para picos de tasa de rebote y aumentos de tasa de aplazamiento

Resultados esperados y siguientes pasos

Cuando un stack Mautic KumoMTA de infraestructura de correo se despliega correctamente y cuenta con inteligencia de VDMS y una ejecución adecuada del calentamiento, suele alcanzar un rendimiento estable (ubicación en bandeja por encima del 88 % y tasas de rebote por debajo del 2 %) en un plazo de 6 a 8 semanas desde la migración completa del tráfico. La investigación State of Email de Litmus sitúa la ubicación media en bandeja sobre infraestructura compartida en el 83 % para remitentes de mercado medio. El stack dedicado, bien operado, supera esa referencia en el primer trimestre.

La limitación honesta: este stack exige trabajo operativo continuo. Las actualizaciones de políticas de KumoMTA, la respuesta a las alertas de VDMS, la gestión de versiones de Mautic y la monitorización de la reputación de las IPs no son cosas de configurar y olvidarse. Los equipos que han intentado llevarlo sin soporte operativo dedicado informan de forma constante de que la entregabilidad se degrada en 3 a 6 meses, a medida que la higiene de la lista se resiente y las políticas del MTA se quedan obsoletas. Ese es el cálculo real del coste: no solo la factura de infraestructura, sino la carga operativa. Para comparar cómo queda eso frente al precio de tu ESP a escala, los números suelen sorprender.

Si tu situación actual se parece a esto (IPs compartidas que no controlas, un techo de entregabilidad que no sabes explicar y un precio de ESP que crece más rápido que tu lista), el proceso para migrar a este stack está documentado. El plazo de 4 a 8 semanas es real, y los requisitos también. Si quieres trazar la migración según tu perfil de envío concreto, esa es una conversación que merece la pena tener antes de comprometer el gasto en infraestructura.