Servidores KumoMTA
KumoMTA gestionado, de inquilino único, sin cuotas por mensaje.
Alojamos KumoMTA —el MTA de código abierto de alto rendimiento— en bare metal AMD EPYC de inquilino único: núcleo en Rust, política en Lua, sin coste de licencia ni cuota por mensaje, con calentamiento de IP guiado, DKIM, feedback loops y una política de producción que afinamos contigo. Operamos en regiones de la UE conformes al RGPD, y somos honestos sobre cuándo KumoMTA es la elección equivocada para ti.
En breve
- Sin coste de licencia. KumoMTA es Apache 2.0; pagas hardware, red y operación, no el MTA.
- Rust + Lua. Núcleo rápido y seguro en memoria; política que es código real que controlas, no casillas.
- Inquilino único. Tu host EPYC, tus IP, tus pools, sin vecinos que arrastren tu reputación.
- Eventos en tiempo real. Entrega, rebote y feedback por webhooks, Kafka o AMQP a tus sistemas.
- Honestos con el encaje. Si Postfix te basta o un ESP gestionado te conviene más, lo decimos.
¿Qué es KumoMTA?
KumoMTA es el primer agente de transferencia de correo (MTA) de código abierto diseñado desde cero para el envío saliente de alto volumen, al nivel de los MTA comerciales como PowerMTA o Momentum. Lo creó un grupo de veteranos de la infraestructura de correo —el mismo entorno del que salió PowerMTA— y se publica bajo licencia Apache 2.0. El núcleo está escrito en Rust, por rendimiento y seguridad de memoria, y la política se escribe en Lua, así que el modelado del tráfico y las reglas son código que controlas, no opciones de una consola.
La diferencia práctica frente a un servidor de correo normal es la cola y el control. Un MTA de recepción enruta a unos pocos destinos internos; uno de envío masivo reparte a decenas de miles de destinos externos a la vez, cada uno con su propio throttling, su reputación y su tasa de aceptación. KumoMTA está hecho para eso: respeta el throttling por destinatario —si Gmail responde con un 421 «más despacio», baja el ritmo y reintenta— porque sin eso una IP nueva puede acabar bloqueada en horas. No es para todo el mundo, y enseguida decimos para quién no lo es.
Conviene situarlo entre sus hermanos. Un MTA de propósito general como Postfix recibe y enruta correo dentro de una organización y cubre de sobra la inmensa mayoría de los casos; un MTA de envío masivo como KumoMTA o PowerMTA está hecho para repartir a gran escala con control fino de la reputación. Confundir ambas categorías sale caro en las dos direcciones: forzar un Postfix más allá de su techo, o pagar una plataforma de envío masivo para una lista pequeña. KumoMTA solo se gana su sitio cuando el volumen y el control que necesitas justifican operar una pieza de infraestructura seria.
Que sea de código abierto cambia además la relación con quien lo construye. Bajo Apache 2.0 no hay cuota anual que financie a un proveedor que mañana podría competir contigo, ni miedo a que suba el precio o cierre; el proyecto lo sostiene una comunidad que incluye a algunos de los mayores remitentes del mundo. Para una empresa cuyo negocio depende del correo, no estar atada a la licencia de un tercero es una forma de seguridad operativa, no solo un ahorro.
¿Es KumoMTA la elección correcta para ti?
A veces lo es y a veces claramente no. Preferimos decírtelo ahora a venderte un servidor del que acabes arrepintiéndote, así que esta es la versión honesta de la decisión.
Cuándo KumoMTA se gana su sitio
- Envías de cientos de miles a muchos millones de mensajes al mes y el precio por mensaje ha empezado a doler.
- Envías en nombre de tus propios clientes y necesitas aislamiento de pools, tus propias IP y política que tú escribes.
- Tienes a alguien —interno o nosotros— que sabe operar un MTA y leer los paneles.
- Quieres los eventos de entrega, rebote y feedback en tus propios sistemas por webhooks, Kafka o AMQP.
Cuándo otra cosa es mejor llamada
- Tu volumen es modesto y un servicio de correo gestionado cuesta menos una vez cuentas las horas de operación.
- Envías a una lista pequeña y poco frecuente donde un relay Postfix sencillo es de verdad suficiente.
- Quieres un contrato de soporte con un proveedor y un número de teléfono más que acceso al código fuente: PowerMTA puede encajar mejor.
- No tienes a nadie que mire la cola a las tres de la madrugada y no quieres que nosotros tampoco.
Alojamos y operamos tanto KumoMTA como PowerMTA, y no nos incomoda recomendar un proveedor gestionado que no vendemos. La recomendación busca encajar con tu situación, no con nuestro catálogo.
no con nuestro catálogo.Esa franqueza tiene un coste para nosotros y por eso la decimos en serio. Rechazar a quien estaría mejor con un Postfix sencillo o con un ESP gestionado nos cuesta una venta, pero nos ahorra un cliente frustrado con un servidor que no necesitaba. Preferimos dimensionarte bien —a veces hacia abajo— y que vuelvas cuando tu volumen de verdad pida un MTA propio, a colocarte hoy una máquina que se quede ociosa y te deje un mal recuerdo.
Compara el stack de correo completo →Puesta en marcha
Cómo lo ponemos en marcha
De la llamada de dimensionado a tu primer envío en producción, con cada paso operado por quien entiende de entregabilidad.
- 01
Llamada de dimensionado
Partimos de tu volumen diario, tu pico, el tamaño medio del mensaje y los proveedores de buzón a los que envías, y dimensionamos un host de inquilino único a esa medida.
- 02
Aprovisionar e instalar
Construimos el host EPYC, instalamos KumoMTA, disponemos los spools RocksDB sobre NVMe y ajustamos los límites de conexión y de tasa a tu perfil de envío.
- 03
Autenticar
Entran los registros SPF, DKIM y DMARC, se confirman el DNS inverso y el TLS, y DMARC pasa de monitorización a aplicación una vez que los informes están limpios.
- 04
Calentar las IP
El volumen sube en una rampa ajustada a tus números mientras vigilamos los feedback loops; los pools transaccional y de marketing se calientan en paralelo.
- 05
Entregar los mandos
Los ficheros de política, la API HTTP y los paneles de Grafana son tuyos; seguimos disponibles para el ajuste.
La política es código
Política en Lua, no casillas en una consola
Estos son fragmentos reales del tipo de política que afinamos contigo: el listener y los spools, y el modelado del tráfico por pool y por destino.
-- /opt/kumomta/etc/policy/init.lua — listener, spools, dos pools de salida
local kumo = require 'kumo'
kumo.on('init', function()
kumo.start_esmtp_listener {
listen = '0.0.0.0:25',
relay_hosts = { '10.0.0.0/24' }, -- solo la subred de tu aplicación
}
kumo.define_spool { name = 'data', path = '/var/spool/kumomta/data', kind = 'RocksDB' }
kumo.define_spool { name = 'meta', path = '/var/spool/kumomta/meta', kind = 'RocksDB' }
-- envía los eventos de entrega y rebote a tu stack
kumo.configure_log_hook { name = 'webhook' }
kumo.start_http_listener { listen = '127.0.0.1:8000' }
end)-- etiqueta un flujo y luego modela el tráfico por destino, por pool
kumo.on('smtp_server_message_received', function(msg)
local pool = msg:get_meta('tenant') == 'mkt'
and 'marketing' or 'transactional'
msg:set_meta('egress_pool', pool)
end)
kumo.on('get_egress_path_config', function(domain, _, _)
return kumo.make_egress_path {
connection_limit = 12,
max_message_rate = '200/s',
max_deliveries_per_connection = 500,
enable_tls = 'Opportunistic',
}
end)Arquitectura
El camino del mensaje y la realimentación de eventos
Tu aplicación entrega al host; el host elige pool, firma y marca el ritmo a cada proveedor; los eventos vuelven en tiempo real a tus sistemas.
Como los eventos son estructurados y se empujan en tiempo real, tu lista de supresión, tus paneles de reputación y tu lógica de reintento leen de la misma fuente que el host. Prometheus y Grafana se conectan igual, así que los números con los que un proveedor te juzga son los mismos que tú vigilas.
Hardware
¿Sobre qué hardware corre?
Inclinamos la máquina hacia la E/S rápida y la red limpia antes que hacia el número bruto de núcleos: es lo que de verdad decide el rendimiento de un MTA.
Un host bien dimensionado envía millones de mensajes por hora, pero el techo real lo ponen los proveedores que reciben y tu reputación, no el software. Por eso dimensionamos la máquina para que el MTA nunca sea el cuello de botella y luego modelamos el tráfico a lo que cada proveedor acepta. Empiezas en un solo host afinado y añades nodos bajo Kubernetes solo cuando el volumen de verdad lo exige.
El cuello de botella, en la práctica, casi nunca es la CPU. Un MTA de envío pasa el día escribiendo y leyendo colas, abriendo decenas de miles de conexiones y esperando a los proveedores, así que el almacenamiento NVMe rápido para el spool RocksDB y una red limpia con control del DNS inverso rinden más por euro que añadir núcleos. Dimensionamos la memoria a la profundidad de cola que esperas y dejamos margen para los picos, porque una cola que no cabe en RAM es lo que de verdad frena un envío grande.
¿KumoMTA o PowerMTA?
PowerMTA lleva años siendo el estándar de la industria para los ESP, con una gestión de entregabilidad lista para usar y documentación madura, y para muchos equipos sigue siendo la opción correcta. Pero es software con licencia: ronda los varios miles de dólares al año —del orden de ocho mil con su analítica incluida— y depende de un fichero de licencia que se comprueba periódicamente; si la validación falla, el MTA deja de aceptar mensajes. KumoMTA no tiene fichero de licencia, ni «phone-home», ni cuota anual: es tuyo para quedártelo.
El contraste real está en el modelo. PowerMTA nació para entornos on-premise y su configuración es densa pero conocida; KumoMTA nació pensando en la nube —«kumo» es «nube» en japonés—, escala en horizontal bajo contenedores y expone una API HTTP. No es magia gratis: KumoMTA es más técnico y pide comodidad con Lua y prácticas de DevOps, mientras que PowerMTA es más fácil de arrancar con sus ficheros estándar. La señal de que el sector se mueve es concreta: plataformas como Postmark han migrado toda su infraestructura de PowerMTA a KumoMTA por el control en tiempo real del tráfico. Alojamos y operamos ambos, así que la recomendación encaja contigo, no con lo que más nos conviene vender.
Hay un matiz de riesgo que conviene nombrar sin dramatismo. Como PowerMTA comprueba su licencia contra un servidor externo, una validación fallida —una licencia caducada, un problema de conectividad— puede dejar el MTA sin aceptar mensajes nuevos justo cuando menos te lo esperas. Con un MTA de código abierto esa dependencia no existe: el software es tuyo, sin fichero de licencia que caduque ni vendedor que pueda apagar tu plataforma a distancia. Para una pieza tan crítica como el envío, esa diferencia de gobernanza pesa tanto como el precio.
Entregabilidad: la red y la política, juntas
Un MTA rápido sobre IP sucias entrega mal, así que tratamos la entregabilidad como un todo. La firma DKIM ocurre en el propio MTA; SPF, DKIM y DMARC se alinean y DMARC pasa a aplicación una vez limpios los informes; el DNS inverso y el TLS se confirman; y el espacio de IP que asignamos sale de rangos limpios y con reputación comprobada. Desde febrero de 2024, Gmail y Yahoo dejaron de tolerar el envío masivo sin autenticación, Microsoft se sumó en 2025 y la aplicación se ha endurecido hasta el rechazo en SMTP: cumplir esas reglas no es opcional, y la política de KumoMTA las hace cumplir por diseño.
El otro pilar es el modelado del tráfico. La política reparte el envío en pools —transaccional y de marketing por separado— y marca el ritmo a cada proveedor según lo que acepta, respetando sus señales de throttling en vez de empujar a ciegas. Los eventos de entrega, rebote y feedback loop vuelven en tiempo real a tu lista de supresión y a tus paneles, de modo que la reputación se gestiona con datos reales y no con conjeturas. Esa disciplina es la misma que aplicamos a la red, porque la entregabilidad se gana a diario.
También importa de dónde sale el correo, no solo cómo se firma. Alojamos el host en regiones de la UE conformes al RGPD, con espacio de IP limpio y DNS inverso bajo nuestro control, de modo que el cumplimiento y la reputación van de la mano desde el primer envío. Para quien sirve a un público europeo o latinoamericano, esa residencia del dato y esa cercanía de red no son un extra: son parte de por qué el correo llega y de por qué la operación resiste una auditoría.
Y la entregabilidad es, al final, un trabajo continuo más que una configuración inicial. Vigilamos las listas negras, los feedback loops y las tasas de aceptación por proveedor, y ajustamos los pools y los límites cuando alguno aprieta el throttling o cambia las reglas. Cuando Gmail o Microsoft endurecen su política —como ha venido pasando— la respuesta no es rehacer el servidor, sino afinar la política en Lua y la rampa de envío, que es justo donde KumoMTA da el control que un panel cerrado no ofrece.
Migración sin parar de enviar
Migrar el correo asusta porque parar de enviar cuesta dinero, así que no paramos. Corremos la plataforma vieja y la nueva en paralelo: traspasamos tus dominios, tus claves de firma y tus listas de supresión, calentamos las IP nuevas con una rampa mientras las viejas siguen cursando producción, y conmutamos el tráfico solo cuando la reputación nueva aguanta. Si vienes de PowerMTA o de Momentum, la mayor parte de tu configuración tiene un equivalente claro en la política de KumoMTA, y nos encargamos de traducirla.
Lo mismo aplica al sentido contrario: si más adelante decides irte, no te lo ponemos difícil. KumoMTA corre software estándar sobre tu host, sin formatos propietarios ni APIs que te aten, así que llevarte tu configuración y tus datos a otro proveedor es cuestión de horas, no un rehén técnico. Construimos la relación sobre que merezca la pena quedarse, no sobre lo caro que sea marcharse.
Preguntas
Respondidas con claridad
Lo que se pregunta antes de montar un servidor KumoMTA.
¿KumoMTA es de verdad gratis de ejecutar?
El software lo es, bajo la licencia Apache 2.0, sin cuota por mensaje ni por servidor. Nos pagas por el hardware, la red y la operación que lo rodea, no por el MTA en sí. Los equipos que dejan el precio por mensaje suelen mirarlo primero justo por esto.
¿En qué lenguaje está escrito KumoMTA y cómo se configura?
El núcleo está escrito en Rust por rendimiento y seguridad de memoria, y la política se escribe en Lua. Eso significa que el modelado del tráfico, la selección de pool, la firma y el manejo de eventos son código real que controlas, no casillas en una consola que no puedes ver por dentro.
¿Cuántos mensajes por hora envía un host KumoMTA?
Un host de inquilino único bien dimensionado envía millones de mensajes por hora, pero el techo real lo marcan los proveedores que reciben y tu reputación, no el software. Dimensionamos la máquina para que el MTA nunca sea el cuello de botella y luego modelamos el tráfico a lo que cada proveedor acepta.
¿Podéis migrarme desde PowerMTA o Momentum?
Sí, y corremos la plataforma vieja y la nueva en paralelo para que nada deje de enviar. Traspasamos tus dominios, tus claves de firma y tus listas de supresión, calentamos las IP nuevas mientras las viejas siguen cursando producción, y conmutamos solo cuando la nueva reputación aguanta.
¿KumoMTA gestiona la firma DKIM y los feedback loops?
Sí. La firma ocurre en el MTA, y KumoMTA emite eventos estructurados de entrega, rebote y feedback loop por webhooks, AMQP o Kafka, de modo que tu lógica de supresión y reputación actúa sobre señales reales en vez de conjeturas.
¿Necesito mis propios ingenieros para operar un servidor KumoMTA?
Necesitas a alguien que sepa leer una política en Lua y vigilar un panel, o nos dejas operarlo por ti. Si no tienes ni la gente ni el volumen que lo justifiquen, un servicio de correo gestionado suele ser mejor llamada, y lo decimos antes de que firmes nada.
¿KumoMTA corre en ARM, en Docker o en Kubernetes?
Sí. Corre en x86 y ARM, publica imágenes de contenedor y escala horizontalmente bajo Kubernetes cuando necesitas más de un nodo. La mayoría de los remitentes empiezan en un solo host afinado y añaden nodos solo cuando el volumen de verdad lo exige.
¿Sobre qué hardware corréis KumoMTA?
AMD EPYC Turin o Genoa de inquilino único, con DDR5 y NVMe Gen5 para el spool. Los núcleos importan menos que un almacenamiento rápido y una red limpia con control del DNS inverso, así que inclinamos la máquina hacia la E/S y la reputación antes que hacia el número bruto de núcleos.
Cuéntanos qué envías.
Tu volumen, tu pico y los buzones a los que llegas, y dimensionamos un host KumoMTA a tu medida —o te decimos cuándo Postfix o un ESP gestionado te conviene más. Sin venta a presión.