Migración de PowerMTA a KumoMTA

Migrar el motor que mueve tu correo asusta por una buena razón: si se hace mal, la entregabilidad se cae y se nota en la cuenta de resultados. Por eso una migración de PowerMTA a KumoMTA no es un cambio de software, sino una operación de reputación. Hecha con método, es invisible: el correo sigue llegando igual el día después que el día antes, y lo único que cambia es lo que pagas por la licencia y lo que puedes hacer con la configuración. Esta página explica por qué cada vez más remitentes lo plantean, qué cambia de verdad y cómo lo ejecutamos sin que tu bandeja de entrada se entere.

Por qué los remitentes están migrando

Dos cosas empujan la conversación. La primera es el rumbo de PowerMTA: desde que el producto se integró en la plataforma omnicanal de Bird, sus equipos dedicados de soporte y desarrollo se han adelgazado, y los remitentes que dependen de él miran con inquietud un roadmap que avanza despacio mientras la factura de licencia —del orden de varios miles de dólares al año— se repite puntual. La segunda es que ha aparecido una alternativa seria: KumoMTA, de código abierto, moderna y gratuita, construida por veteranos de la industria que llevan décadas haciendo MTAs de alto rendimiento. No es que PowerMTA haya dejado de funcionar; es que, por primera vez, quedarse tiene un coste de oportunidad claro.

A esto se suma un contexto que no perdona la mediocridad técnica. Desde noviembre de 2025 Gmail rechaza el correo masivo no conforme en el propio SMTP, y Microsoft aplica sus requisitos desde mayo de 2025. La capa que decide si cumples —autenticación, modelado de tráfico, gestión de colas— es justo la que tocas al migrar, así que muchas empresas usan ese movimiento para dejarla mejor de lo que estaba. Lo explicamos en detalle en nuestra guía de por qué Gmail rechaza tus correos.

¿Qué es KumoMTA y en qué se diferencia de PowerMTA?

KumoMTA es un MTA de código abierto, publicado bajo licencia Apache 2.0 y con el código en GitHub, escrito desde cero en Rust y pensado para el envío saliente de alto volumen. Su arquitectura es asíncrona y orientada a eventos, lo que le permite manejar mucha concurrencia, y persiste los mensajes en disco para no perderlos ante una caída. Su configuración no vive en un fichero de texto estático, sino en código Lua que se ejecuta dentro del propio MTA: configuración como código, con todo lo que eso permite —condicionales, bucles, conexión directa a bases de datos y a herramientas como Prometheus o Grafana—. La gestiona una comunidad activa que incluye a algunos de los mayores remitentes del mundo. Lo que no trae, por decisión de diseño, es una interfaz web: se opera como código, no a clics.

PowerMTA frente a KumoMTA

La comparación honesta no es «uno bueno y otro malo», sino dos herramientas con filosofías distintas. PowerMTA es el estándar comercial de una era de servidores dedicados; KumoMTA es la respuesta moderna y abierta. Esto es lo que cambia entre ambos.

La diferencia que más se nota en el día a día es la configuración. Los «one-liners» de PowerMTA son cómodos pero rígidos: lo que escribes es lo que hay. La configuración en Lua de KumoMTA condensa esa misma lógica con condicionales e iteración, y permite que el MTA consulte datos en vivo en lugar de depender de ficheros que hay que regenerar y recargar. Para un equipo con prácticas de DevOps, eso es libertad; para uno acostumbrado a editar un fichero plano, es la curva de aprendizaje que justifica traer a alguien que ya la ha recorrido.

¿Es el momento de migrar de PowerMTA a KumoMTA?

No siempre lo es, y lo decimos antes de cobrar nada. Si tu PowerMTA cumple, tu equipo lo conoce a fondo y tu prioridad es la estabilidad por encima del coste, lo correcto puede ser quedarte y optimizar lo que ya tienes hasta que la migración encaje en tu calendario. Si, en cambio, te incomoda el rumbo del producto, la factura recurrente pesa, o quieres una configuración que se integre de verdad con tu entorno, la migración tiene sentido. Parte de nuestro trabajo es ayudarte a tomar esa decisión sin sesgo, porque no tenemos ninguna licencia que vender en ninguna de las dos direcciones. Cuando la pregunta es más amplia —PowerMTA, KumoMTA, Halon o MailerQ—, la abordamos como un ejercicio de selección, no como una venta.

¿Qué cambia técnicamente al migrar a KumoMTA?

La buena noticia para quien viene de PowerMTA es que los conceptos se trasladan. Lo que en PowerMTA llamas VirtualMTA tiene su equivalente en el «egress source» de KumoMTA: ahí gestionas el control de entrega y el throttling por IP. Las directivas sueltas de PowerMTA pasan a vivir en una configuración Lua más estructurada y flexible, y los ajustes que en su día añadiste como parches —ejecutar como root, gestionar ficheros huérfanos— a menudo dejan de hacer falta. El cambio no es traducir línea por línea, sino reexpresar tu intención de envío en un modelo más capaz. Esa traducción es donde se gana o se pierde una migración, y es exactamente la parte que conviene que haga alguien que conoce los dos lados.

Rendimiento y arquitectura: qué esperar

La arquitectura es donde KumoMTA muestra su edad, en el buen sentido. Está escrita en Rust sobre un runtime asíncrono, de modo que cada operación —desde la recepción hasta la entrega— se maneja sin bloquear, lo que le permite sostener mucha concurrencia en hardware razonable. Persiste los mensajes en disco en lugar de mantenerlos en memoria, lo que protege la cola ante una caída a cambio de que el rendimiento de disco entre en la ecuación. Frente a la arquitectura de PowerMTA, pensada para servidores dedicados y que escala primero en vertical, KumoMTA está concebido para entornos de nube y para crecer de forma más natural. En la práctica, para la mayoría de los remitentes el cuello de botella no es el MTA, sino la reputación y los límites de los receptores, así que cambiar de motor rara vez es lo que sube tu volumen. Lo que sí cambia es el techo y la flexibilidad cuando llegas a él, y esa diferencia se nota justo cuando más duele: a escala.

Cómo encaja en tu stack

Una de las razones por las que los equipos con prácticas de DevOps eligen KumoMTA es que deja de ser una caja negra. La configuración como código se versiona junto al resto de tu infraestructura, y el MTA se conecta con el ecosistema que ya usas: webhooks para eventos, colas como Kafka o AMQP, métricas hacia Prometheus y paneles en Grafana, secretos en Vault y acceso directo a bases de datos para decisiones en tiempo real. En lugar de regenerar ficheros y recargar el servicio cada vez, la configuración se carga tarde, consume menos memoria y consulta los datos vivos sin rodeos. Para una operación que quiere tratar el envío como una pieza más de su plataforma —observable, automatizada, reproducible—, ese encaje es buena parte del atractivo, y a menudo pesa más en la decisión que el propio ahorro de licencia.

# PowerMTA: un VirtualMTA con su IP y su ritmo por dominio (directivas)
<virtual-mta pool-a-1>
  smtp-source-host 198.51.100.10 mta1.example.com
  <domain gmail.com> max-msg-rate 180/min </domain>
</virtual-mta>

# KumoMTA: la misma intención como egress source + shaping (Lua + helper TOML)
egress_sources = {
  ['pool-a-1'] = { source_address = '198.51.100.10', ehlo_domain = 'mta1.example.com' },
}
# shaping.toml — por proveedor, partiendo del suelo comunitario
['gmail.com'] max_message_rate = '180/min'

La curva de Lua, sin dramatizar

El argumento que más frena a los equipos es la configuración en Lua, y conviene ponerlo en su sitio. Lua es un lenguaje de scripting sencillo de leer y escribir, el mismo que usan desde appliances de seguridad hasta videojuegos, y la mayoría de las configuraciones de correo se expresan en él sin necesidad de ser programador. La curva existe, sobre todo para quien venía de editar un fichero plano de directivas, pero es una curva de días, no de meses, y se recorre una sola vez. Además, no tienes que recorrerla a solas: nosotros escribimos la configuración inicial, la dejamos comentada y, si tu equipo quiere autonomía, lo formamos sobre tu propia instalación. La flexibilidad que ganas —condicionales, datos en vivo, lógica reutilizable— compensa con creces el rato de aprendizaje.

Cómo ejecutamos la migración sin precipicio

Nuestra metodología existe para una sola cosa: que la entregabilidad nunca se encuentre con un escalón. Sigue siempre el mismo arco.

1. Descubrimiento y auditoría. Mapeamos tu estructura actual —VirtualMTAs, parque de IPs, dominios, autenticación, reglas de throttling— y la documentamos como punto de partida verificable.
2. Replicación de la configuración. Reexpresamos tu lógica de envío en Lua, conservando el comportamiento por IP y por proveedor, y la versionamos para que cada cambio sea trazable.
3. Preservación de la reputación. Migramos las claves DKIM, los registros SPF y el estado de calentamiento, de modo que las IPs lleguen a KumoMTA con su historial intacto.
4. Corte por pool de IPs. Movemos el tráfico pool a pool, no todo de golpe, validando cada paso antes de avanzar.
5. Validación con seed lists. Comprobamos la llegada a la bandeja de entrada antes y después de cada corte, en los grandes proveedores, para confirmar que nada se ha movido.
6. Plan de reversión. Cada paso tiene vuelta atrás, así que un imprevisto es una pausa, nunca una crisis.

Errores que evita una migración cuidadosa

Casi todas las migraciones que salen mal repiten los mismos tropiezos, y conocerlos es la mitad de evitarlos. El más caro es cortar todo el tráfico de una vez: ahorra una semana de calendario y pone toda tu reputación en un solo movimiento. Le sigue traducir la configuración línea por línea sin entender la intención detrás, que arrastra a KumoMTA los parches y rarezas que PowerMTA acumuló con los años. Después está descuidar la alineación: migrar las claves DKIM pero no comprobar que siguen alineadas con el dominio visible, y enterarte por un rechazo. Y el más silencioso, reiniciar el calentamiento sin querer al mover IPs sin preservar su estado, lo que tira meses de reputación por un descuido de procedimiento. Ninguno es inevitable; todos se evitan con método, con un punto de partida documentado y con validación en cada paso. La diferencia entre una migración tranquila y una accidentada rara vez es la herramienta: es el cuidado con el que se ejecuta.

Qué se conserva en el camino

La pregunta que más nos hacen es qué se pierde, y la respuesta corta es: nada que importe. Se conserva la reputación de tus IPs y dominios, porque vive en ellos y no en el software. Se conservan las claves DKIM y los registros SPF, que migramos sin romper la firma. Se conserva el estado de calentamiento de cada IP, para no reiniciar meses de trabajo. Y se traslada tu lógica de throttling y de colas, reexpresada en un modelo más flexible pero con el mismo comportamiento de cara al proveedor. El procesamiento de rebotes y el registro detallado, que son la base de cualquier diagnóstico, salen reforzados, porque KumoMTA los expone mejor.

¿Por qué migrar un pool de IPs a la vez?

Cortar todo el tráfico de una vez es la forma más rápida de convertir un problema pequeño en uno general. Si algo se configura mal, lo descubres con todo tu volumen encima y todas tus IPs comprometidas a la vez. El corte por pool acota el riesgo: mueves un grupo de IPs, lo validas con datos reales de entrega durante un tiempo, y solo entonces avanzas al siguiente. Si aparece un detalle —una alineación que falla, un throttle mal calibrado—, lo resuelves sobre una fracción del tráfico y con margen para volver atrás. Es más lento de leer en un calendario y mucho más seguro de vivir en producción.

No eres el primero en hacerlo

Migrar de PowerMTA a KumoMTA dejó de ser territorio inexplorado. Operadores serios de correo, incluidos proveedores que mueven volúmenes enormes en entornos multicliente donde la reputación de cada cuenta importa, han hecho el cambio y lo han contado: probaron KumoMTA a fondo antes de mover producción, valoraron la configuración en Lua para ajustar el comportamiento por flujo y por pool de IPs, y se quedaron por la transparencia de un código abierto sin sorpresas de licencia. Que algunos de los mayores remitentes del mundo contribuyan a su comunidad es, en sí, una señal: el riesgo de adoptar una tecnología inmadura no es el que corres aquí. Lo que queda es ejecutar bien tu caso concreto, que es justo donde una mano experta marca la diferencia entre semanas de calma y una incidencia evitable.

¿Cuánto cuesta y cuánto tarda de verdad una migración?

Una migración típica lleva de dos a seis semanas, marcadas por tu número de VirtualMTAs, el tamaño de tu parque de IPs y el volumen de datos. Del lado del software, KumoMTA no añade coste de licencia: el ahorro frente a la factura comercial recurrente es real y se nota año tras año. Del lado del proyecto, lo que pagas es el trabajo de hacerlo bien una vez —la traducción de la configuración, la preservación de la reputación, la validación— en lugar de pagarlo en entregabilidad perdida si se hace deprisa. La comparación sensata no es «gratis frente a caro», sino «una migración cuidadosa frente al coste de una campaña que no llega».

Qué incluye el proyecto

Para que sepas qué recibes y no solo qué pagas, una migración con nosotros entrega cuatro cosas concretas. Una configuración de KumoMTA equivalente a la tuya, escrita en Lua, documentada y versionada, que es tuya desde el primer día. Un registro de la migración con el estado de cada pool y cada validación, de modo que en cualquier momento sabes qué se movió y qué falta. Las pruebas de entregabilidad con seed lists antes y después de cada corte, para demostrar —no afirmar— que la entrega se mantuvo. Y, si lo quieres, la formación para que tu equipo opere la nueva configuración con soltura. El objetivo es que termines la migración con más control sobre tu envío del que tenías al empezar, no con una dependencia nueva disfrazada de servicio.

¿Vienes de Momentum u otro motor?

PowerMTA no es el único origen del que migramos. Si arrastras Momentum (Ecelerity) u otro MTA heredado que ya no recibe el soporte que necesitas, el planteamiento es el mismo: mapear tu lógica de envío, reexpresarla en KumoMTA y mover el tráfico por pasos validados sin tocar tu reputación. De hecho, el arquitecto que diseñó el motor Momentum está detrás de KumoMTA, así que muchos conceptos viajan con naturalidad y buena parte de tu experiencia operativa sigue siendo válida. Si no tienes claro qué motor te conviene —KumoMTA, una optimización de lo que ya tienes o algo distinto—, lo abordamos como una decisión técnica con tu interés por delante, no como una venta cerrada de antemano.

Qué no cambia al migrar

Conviene decir también qué se queda igual, porque tranquiliza tanto como lo que mejora. Tus dominios de envío no cambian. Tus IPs siguen siendo tuyas, con su historial y su calentamiento intactos. Tu autenticación —SPF, DKIM y DMARC— se mantiene válida y alineada. Tus integraciones con la aplicación que inyecta el correo siguen funcionando, porque KumoMTA recibe el mensaje por los mismos protocolos. Y tu volumen y tus límites con los proveedores no se reinician: la reputación que tanto costó construir viaja contigo. Migrar bien no es empezar de cero; es mudarse de casa sin perder ni una caja, y despertarte en un sitio con más espacio.

Migración y cumplimiento, de la mano

Hay una razón de peso para no separar la migración del cumplimiento. Los requisitos que Gmail, Yahoo y Microsoft endurecieron en los últimos dos años —autenticación obligatoria con SPF, DKIM y DMARC, tasas de queja por debajo de umbrales estrictos, una cabecera de baja en un clic para el correo masivo— se aplican exactamente en la misma capa que tocas al cambiar de MTA. Migrar con prisa y dejar esa capa como estaba es desperdiciar la mejor oportunidad de ponerla a punto, porque ya tienes las manos dentro. Migrar con criterio significa salir de KumoMTA conforme desde el primer envío: con la autenticación alineada de verdad y no solo presente, con la gestión de rebotes y quejas conectada a las señales de los receptores, y con el modelado de tráfico afinado proveedor a proveedor en lugar de copiado a ojo. Por eso nuestra migración no se limita a trasladar la configuración: revisa de paso que cumples lo que hoy exigen los grandes buzones, ajusta lo que haga falta y lo valida con datos reales de entrega. El resultado es que el proyecto que contratas por un motivo —cambiar de motor— te resuelve también el otro, que es llegar a la bandeja en un entorno cada vez menos tolerante. Salir de la migración con un correo más conforme que antes no es un extra: es parte del trabajo bien hecho.

El panel que KumoMTA no trae

Para algunos equipos, la ausencia de interfaz web es justo lo que valoran; para otros, es el único punto que echan en falta al dejar atrás cualquier herramienta con consola. Cuando hace falta, montamos un panel de observabilidad y gestión encima de KumoMTA —colas, métricas de entrega, estado por dominio y por IP— sin renunciar a la configuración como código que hace potente al producto. Es la pieza que el proyecto no incluye por diseño y que nosotros añadimos cuando aporta, no por defecto.

Por qué una consultoría independiente

En la entregabilidad hay muchos actores con algo que venderte: fabricantes con su licencia, plataformas con su suscripción, hosters con su servidor. Nosotros no revendemos KumoMTA —es gratis— ni licencias de PowerMTA, así que cuando te recomendamos migrar, quedarte u optimizar, no hay un producto detrás empujando la respuesta. Esa independencia cambia la conversación: podemos decirte que no migres si no te conviene, podemos elegir la arquitectura que mejor encaje en tu caso en lugar de la que más nos renta, y podemos darte la configuración para que la operes sin nosotros si así lo prefieres. Trabajamos en la capa de infraestructura del correo a diario, con equipos en varios husos horarios, y nuestro único incentivo es que tu correo llegue. Cuando el que aconseja no vende el producto que recomienda, sus consejos valen más.

¿Quién opera KumoMTA después de la migración?

Una migración no termina en el corte. Si tu equipo quiere las llaves, te dejamos la configuración documentada y versionada y os formamos para mantenerla. Si prefieres que sigamos al volante, operamos tu KumoMTA como una extensión de tu equipo: monitorización, ajuste y respuesta a incidencias, en husos horarios de Europa, Norteamérica y Latinoamérica. En ambos casos la infraestructura es tuya y la independencia es nuestra: no hay un fabricante detrás cuyos intereses tengamos que servir antes que los tuyos.

Si estás sopesando el movimiento, el punto de partida no es una propuesta, sino una foto. La auditoría gratuita de 25 puntos mide dónde está hoy tu PowerMTA —configuración, reputación y llegada a bandeja de entrada— y te dice, sin compromiso, si migrar te conviene y qué haría falta. Es la mejor forma de decidir con datos en lugar de con intuición.