Servidores KumoMTA
KumoMTA gerenciado, de inquilino único, sem tarifa por mensagem.
Hospedamos o KumoMTA —o MTA de código aberto de alto desempenho— em bare metal AMD EPYC de inquilino único: núcleo em Rust, política em Lua, sem custo de licença nem tarifa por mensagem, com aquecimento de IP guiado, DKIM, feedback loops e uma política de produção que afinamos com você. Operamos na Europa e em Ashburn, sob a LGPD, e somos honestos sobre quando o KumoMTA é a escolha errada para você.
Em resumo
- Sem custo de licença. O KumoMTA é Apache 2.0; você paga hardware, rede e operação, não o MTA —e sem uma licença em dólar.
- Rust + Lua. Núcleo rápido e seguro em memória; política que é código real que você controla, não caixinhas.
- Inquilino único. O seu host EPYC, os seus IPs, os seus pools, sem vizinhos arrastando a sua reputação.
- Eventos em tempo real. Entrega, bounce e feedback por webhooks, Kafka ou AMQP para os seus sistemas.
- Honestos com o encaixe. Se o Postfix basta ou um ESP gerenciado convém mais, dizemos.
O que é o KumoMTA?
O KumoMTA é o primeiro agente de transferência de correio (MTA) de código aberto projetado do zero para o envio de saída de alto volume, no nível dos MTAs comerciais como o PowerMTA ou o Momentum. Foi criado por um grupo de veteranos da infraestrutura de e-mail —o mesmo meio de onde saiu o PowerMTA— e é publicado sob a licença Apache 2.0. O núcleo é escrito em Rust, por desempenho e segurança de memória, e a política se escreve em Lua, então o traffic shaping e as regras são código que você controla, não opções de um console.
A diferença prática para um servidor de e-mail comum é a fila e o controle. Um MTA de recepção roteia para poucos destinos internos; um de envio em massa reparte para dezenas de milhares de destinos externos ao mesmo tempo, cada um com o seu próprio throttling, a sua reputação e a sua taxa de aceitação. O KumoMTA é feito para isso: respeita o throttling por destinatário —se o Gmail responde com um 421 "mais devagar", ele reduz o ritmo e tenta de novo— porque sem isso um IP novo pode acabar bloqueado em horas. Não é para todo mundo, e já dizemos para quem não é.
Convém situá-lo entre os irmãos. Um MTA de propósito geral como o Postfix recebe e roteia e-mail dentro de uma organização e cobre de sobra a imensa maioria dos casos; um MTA de envio em massa como o KumoMTA ou o PowerMTA é feito para repartir em grande escala com controle fino da reputação. Confundir as duas categorias sai caro nos dois sentidos: forçar um Postfix além do seu teto, ou pagar uma plataforma de envio em massa para uma lista pequena. O KumoMTA só se ganha o lugar quando o volume e o controle que você precisa justificam operar uma peça de infraestrutura séria.
Ser de código aberto muda ainda a relação com quem o constrói. Sob a Apache 2.0 não há tarifa anual que financie um fornecedor que amanhã poderia competir com você, nem medo de que o preço suba ou de que ele feche; o projeto é sustentado por uma comunidade que inclui alguns dos maiores remetentes do mundo. Para uma empresa cujo negócio depende do e-mail, não estar presa à licença de um terceiro é uma forma de segurança operacional, não só uma economia —e no Brasil, uma a menos exposta ao câmbio.
O KumoMTA é a escolha certa para você?
Às vezes é e às vezes claramente não. Preferimos dizer isso agora a vender um servidor do qual você acabe se arrependendo, então esta é a versão honesta da decisão.
Quando o KumoMTA se ganha o lugar
- Você envia de centenas de milhares a muitos milhões de mensagens por mês e o preço por mensagem começou a doer.
- Você envia em nome dos seus próprios clientes e precisa de isolamento de pools, dos seus próprios IPs e de política que você escreve.
- Você tem alguém —interno ou nós— que sabe operar um MTA e ler os painéis.
- Você quer os eventos de entrega, bounce e feedback nos seus próprios sistemas por webhooks, Kafka ou AMQP.
Quando outra coisa é a melhor jogada
- O seu volume é modesto e um serviço de e-mail gerenciado custa menos depois de contar as horas de operação.
- Você envia para uma lista pequena e pouco frequente onde um relay Postfix simples é de fato suficiente.
- Você quer um contrato de suporte com um fornecedor e um telefone mais do que acesso ao código-fonte: o PowerMTA pode encaixar melhor.
- Você não tem ninguém para olhar a fila às três da manhã e não quer que nós também olhemos.
Hospedamos e operamos tanto o KumoMTA quanto o PowerMTA, e não nos incomoda recomendar um provedor gerenciado que não vendemos. A recomendação busca encaixar com a sua situação, não com o nosso catálogo.
Essa franqueza tem um custo para nós e por isso a dizemos a sério. Recusar quem estaria melhor com um Postfix simples ou com um ESP gerenciado nos custa uma venda, mas nos poupa um cliente frustrado com um servidor que não precisava. Preferimos dimensionar você bem —às vezes para baixo— e que você volte quando o seu volume de fato pedir um MTA próprio, a colocar hoje uma máquina que fica ociosa e deixa uma má lembrança.
Compare o stack de e-mail completo →Passo a passo
Como colocamos em marcha
De uma ligação de dimensionamento ao seu primeiro envio em produção, com cada passo com dono. Este é o caminho que seguimos com cada host novo.
- 01
Ligação de dimensionamento
Partimos do seu volume diário, do seu pico, do tamanho médio da mensagem e dos provedores de caixa para quem você envia, e dimensionamos um host de inquilino único sob medida.
- 02
Provisionar e instalar
Construímos o host EPYC, instalamos o KumoMTA, dispomos os spools RocksDB sobre NVMe e ajustamos os limites de conexão e de taxa ao seu perfil de envio.
- 03
Autenticar
Entram os registros SPF, DKIM e DMARC, confirmam-se o DNS reverso e o TLS, e o DMARC passa de monitoramento a aplicação assim que os relatórios estão limpos.
- 04
Aquecer os IPs
O volume sobe em uma rampa ajustada aos seus números enquanto vigiamos os feedback loops; os pools transacional e de marketing aquecem em paralelo.
- 05
Entregar os controles
Os arquivos de política, a API HTTP e os painéis do Grafana são seus; seguimos disponíveis para o ajuste.
A política
A configuração é código, não caixinhas
A política em Lua define o listener e os spools, e depois modela o tráfego por pool e por destino. É o que você controla, e o que afinamos com você.
-- /opt/kumomta/etc/policy/init.lua — listener, spools, dois pools de saída
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' }, -- só a sub-rede da sua aplicação
}
kumo.define_spool { name = 'data', path = '/var/spool/kumomta/data', kind = 'RocksDB' }
kumo.define_spool { name = 'meta', path = '/var/spool/kumomta/meta', kind = 'RocksDB' }
-- envia os eventos de entrega e bounce para o seu stack
kumo.configure_log_hook { name = 'webhook' }
kumo.start_http_listener { listen = '127.0.0.1:8000' }
end)-- rotula um fluxo e depois modela o tráfego 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)Arquitetura
O caminho da mensagem e o retorno dos eventos
A sua aplicação entrega ao host; o host escolhe o pool, assina e marca o ritmo a cada provedor; os eventos voltam em tempo real aos seus sistemas.
Como os eventos são estruturados e empurrados em tempo real, a sua lista de supressão, os seus painéis de reputação e a sua lógica de retentativa leem da mesma fonte que o host. O Prometheus e o Grafana se conectam igual, então os números pelos quais um provedor julga você são os mesmos que você vigia.
Hardware
Em que hardware ele roda?
Inclinamos a máquina para a E/S rápida e a rede limpa antes do número bruto de núcleos: é o que de fato decide o desempenho de um MTA.
Um host bem dimensionado envia milhões de mensagens por hora, mas o teto real é posto pelos provedores que recebem e pela sua reputação, não pelo software. Por isso dimensionamos a máquina para que o MTA nunca seja o gargalo e depois modelamos o tráfego ao que cada provedor aceita. Você começa em um único host afinado e adiciona nós sob Kubernetes só quando o volume de fato exige.
O gargalo, na prática, quase nunca é a CPU. Um MTA de envio passa o dia escrevendo e lendo filas, abrindo dezenas de milhares de conexões e esperando os provedores, então o armazenamento NVMe rápido para o spool RocksDB e uma rede limpa com controle do DNS reverso rendem mais por real do que adicionar núcleos. Dimensionamos a memória à profundidade de fila que você espera e deixamos margem para os picos, porque uma fila que não cabe na RAM é o que de fato freia um envio grande.
KumoMTA ou PowerMTA?
O PowerMTA é há anos o padrão da indústria para os ESPs, com gestão de entregabilidade pronta para usar e documentação madura, e para muitas equipes segue sendo a opção certa. Mas é software licenciado: gira na casa de vários milhares de dólares por ano —da ordem de oito mil com a sua analítica incluída— e depende de um arquivo de licença verificado periodicamente; se a validação falha, o MTA para de aceitar mensagens. O KumoMTA não tem arquivo de licença, nem "phone-home", nem tarifa anual: é seu para ficar —e, para um orçamento em real, sem o câmbio embutido na conta.
O contraste real está no modelo. O PowerMTA nasceu para ambientes on-premise e a sua configuração é densa mas conhecida; o KumoMTA nasceu pensando na nuvem —"kumo" é "nuvem" em japonês—, escala na horizontal sob contêineres e expõe uma API HTTP. Não é mágica grátis: o KumoMTA é mais técnico e pede conforto com Lua e práticas de DevOps, enquanto o PowerMTA é mais fácil de arrancar com os seus arquivos padrão. O sinal de que o setor se move é concreto: plataformas como o Postmark migraram toda a sua infraestrutura de PowerMTA para KumoMTA pelo controle em tempo real do tráfego. Hospedamos e operamos os dois, então a recomendação encaixa com você, não com o que mais nos convém vender.
Há um detalhe de risco que convém nomear sem drama. Como o PowerMTA verifica a sua licença contra um servidor externo, uma validação falha —uma licença vencida, um problema de conectividade— pode deixar o MTA sem aceitar mensagens novas justo quando você menos espera. Com um MTA de código aberto essa dependência não existe: o software é seu, sem arquivo de licença que vença nem fornecedor que possa desligar a sua plataforma à distância. Para uma peça tão crítica quanto o envio, essa diferença de governança pesa tanto quanto o preço.
Entregabilidade: a rede e a política, juntas
Um MTA rápido sobre IPs sujos entrega mal, então tratamos a entregabilidade como um todo. A assinatura DKIM ocorre no próprio MTA; SPF, DKIM e DMARC se alinham e o DMARC passa a aplicação assim que os relatórios ficam limpos; o DNS reverso e o TLS se confirmam; e o espaço de IP que atribuímos sai de faixas limpas e com reputação comprovada. Desde fevereiro de 2024, o Gmail e o Yahoo deixaram de tolerar o envio em massa sem autenticação, a Microsoft entrou em 2025 e a aplicação endureceu até a rejeição em SMTP: cumprir essas regras não é opcional, e a política do KumoMTA as faz cumprir por desenho.
O outro pilar é o traffic shaping. A política reparte o envio em pools —transacional e de marketing separados— e marca o ritmo a cada provedor conforme o que ele aceita, respeitando os seus sinais de throttling em vez de empurrar às cegas. Os eventos de entrega, bounce e feedback loop voltam em tempo real à sua lista de supressão e aos seus painéis, de modo que a reputação se gere com dados reais e não com palpite. Essa disciplina é a mesma que aplicamos à rede, porque a entregabilidade se ganha todo dia.
Também importa de onde o e-mail sai, não só como é assinado. Hospedamos o host na Europa e em Ashburn, com espaço de IP limpo e DNS reverso sob o nosso controle, de modo que a conformidade e a reputação andam juntas desde o primeiro envio. Aqui vale a honestidade regional: os destinos do e-mail são os grandes provedores de caixa globais —Gmail, Outlook, Yahoo— então a distância das nossas regiões ao Brasil pesa pouco na entrega, ao contrário do que acontece com um site voltado ao usuário brasileiro. A LGPD permite a transferência internacional com base legal e salvaguardas; se você exige os dados em solo brasileiro, dizemos quando um provedor no Brasil encaixa melhor.
E a entregabilidade é, no fim, um trabalho contínuo mais do que uma configuração inicial. Vigiamos as listas negras, os feedback loops e as taxas de aceitação por provedor, e ajustamos os pools e os limites quando algum aperta o throttling ou muda as regras. Quando o Gmail ou a Microsoft endurecem a política —como vem acontecendo— a resposta não é refazer o servidor, mas afinar a política em Lua e a rampa de envio, que é justo onde o KumoMTA dá o controle que um painel fechado não oferece.
Migração sem parar de enviar
Migrar o e-mail assusta porque parar de enviar custa dinheiro, então não paramos. Rodamos a plataforma velha e a nova em paralelo: transferimos os seus domínios, as suas chaves de assinatura e as suas listas de supressão, aquecemos os IPs novos com uma rampa enquanto os velhos seguem cursando produção, e fazemos a virada do tráfego só quando a nova reputação aguenta. Se você vem do PowerMTA ou do Momentum, a maior parte da sua configuração tem um equivalente claro na política do KumoMTA, e nós cuidamos de traduzi-la.
O mesmo vale no sentido contrário: se mais adiante você decidir sair, não dificultamos. O KumoMTA roda software padrão sobre o seu host, sem formatos proprietários nem APIs que prendam você, então levar a sua configuração e os seus dados para outro provedor é questão de horas, não um refém técnico. Construímos a relação sobre valer a pena ficar, não sobre o quanto custa ir embora.
Perguntas
Respondidas com clareza
O que se pergunta antes de montar um servidor KumoMTA.
O KumoMTA é mesmo grátis de rodar?
O software é, sob a licença Apache 2.0, sem tarifa por mensagem nem por servidor. Você nos paga pelo hardware, pela rede e pela operação ao redor, não pelo MTA em si. As equipes que largam o preço por mensagem costumam olhar para cá primeiro justamente por isso —e, no Brasil, sem uma licença em dólar para acompanhar o câmbio.
Em que linguagem o KumoMTA é escrito e como se configura?
O núcleo é escrito em Rust, por desempenho e segurança de memória, e a política se escreve em Lua. Isso significa que o traffic shaping, a seleção de pool, a assinatura e o tratamento de eventos são código real que você controla, não caixinhas em um console que você não enxerga por dentro.
Quantas mensagens por hora um host KumoMTA envia?
Um host de inquilino único bem dimensionado envia milhões de mensagens por hora, mas o teto real é dado pelos provedores que recebem e pela sua reputação, não pelo software. Dimensionamos a máquina para que o MTA nunca seja o gargalo e depois modelamos o tráfego ao que cada provedor aceita.
Vocês conseguem me migrar do PowerMTA ou do Momentum?
Sim, e rodamos a plataforma velha e a nova em paralelo para que nada deixe de enviar. Transferimos os seus domínios, as suas chaves de assinatura e as suas listas de supressão, aquecemos os IPs novos enquanto os velhos seguem cursando produção, e fazemos a virada só quando a nova reputação aguenta.
O KumoMTA cuida da assinatura DKIM e dos feedback loops?
Sim. A assinatura ocorre no MTA, e o KumoMTA emite eventos estruturados de entrega, bounce e feedback loop por webhooks, AMQP ou Kafka, de modo que a sua lógica de supressão e reputação age sobre sinais reais em vez de palpite.
Eu preciso dos meus próprios engenheiros para operar um servidor KumoMTA?
Você precisa de alguém que saiba ler uma política em Lua e vigiar um painel, ou nos deixa operá-lo por você. Se você não tem nem a gente nem o volume que justifiquem, um serviço de e-mail gerenciado costuma ser a melhor jogada, e dizemos isso antes de você assinar qualquer coisa.
O KumoMTA roda em ARM, em Docker ou em Kubernetes?
Sim. Roda em x86 e ARM, publica imagens de contêiner e escala horizontalmente sob Kubernetes quando você precisa de mais de um nó. A maioria dos remetentes começa em um único host afinado e adiciona nós só quando o volume de fato exige.
Em que hardware vocês rodam o KumoMTA?
AMD EPYC Turin ou Genoa de inquilino único, com DDR5 e NVMe Gen5 para o spool. Os núcleos importam menos do que um armazenamento rápido e uma rede limpa com controle do DNS reverso, então inclinamos a máquina para a E/S e a reputação antes do número bruto de núcleos.
Conte para a gente o que você envia.
O seu volume, o seu pico e as caixas que você alcança, e dimensionamos um host KumoMTA sob medida —ou dizemos quando o Postfix ou um ESP gerenciado convém mais. Sem venda sob pressão.