KumoMTA gerenciado

O KumoMTA mudou as regras: pela primeira vez, um motor de envio de código aberto iguala os comerciais em potência, sem licença a pagar. Mas «grátis» se refere à licença, não ao esforço. Um KumoMTA em produção pede configuração em Lua, automação da modelagem de tráfego, clustering quando você cresce, integrações com a sua pilha e uma vigilância diária que o próprio projeto não operará por você. É aí que entramos: operamos o seu KumoMTA como uma extensão da sua equipe, de modo que você fica com o controle e a economia de um motor aberto e nós ficamos com o trabalho de domá-lo. Esta página explica o que essa operação implica e o que você leva ao delegá-la.

Se o KumoMTA é grátis, por que pagar para gerenciá-lo?

O argumento de venda do KumoMTA — código aberto, sem licença — é real e poderoso, mas esconde uma letra miúda que convém ler. Software grátis não significa operação grátis. Um motor desse nível precisa de mãos que saibam configurá-lo, afiná-lo e resgatá-lo quando algo falha, e o projeto, pela sua natureza aberta, não inclui um suporte de fabricante com plantão e acordos de serviço: apoia-se em uma comunidade ativa e na sua própria capacidade de DevOps. Para uma equipe com essa cultura, é liberdade; para uma que não a tem, é um custo oculto que aparece justo no pior momento, quando há um incidente e ninguém para ligar. O serviço gerenciado converte esse custo oculto em um previsível: você fica com a economia de licença, e nós com a responsabilidade de que funcione.

O custo real de operar em casa

Tentadas pela licença zero, muitas equipes decidem operar o KumoMTA por conta própria e descobrem tarde o custo real. Operar bem um motor desse nível exige uma pessoa com conhecimento específico — Lua, modelagem de tráfego, clustering —, disponibilidade para incidentes fora de hora e tempo contínuo de manutenção. Isso, em folha, é um perfil caro e escasso, e se recai sobre um engenheiro que já tem outro trabalho, o e-mail acaba sendo o que se desatende quando chega uma urgência. A isso se soma o custo de oportunidade: as horas que a sua equipe dedica a domar o MTA são horas que não dedica ao seu produto. A operação gerenciada converte esse gasto difuso e muitas vezes subestimado em uma mensalidade previsível, e reparte a experiência de operar muitos parques entre todos os clientes. Não é que operá-lo em casa seja impossível; é que raramente sai tão barato quanto sugere a palavra «grátis».

O que de verdade implica operar o KumoMTA em produção?

Operar o KumoMTA bem é bem mais que instalá-lo. É escrever e manter a sua configuração em Lua, que é código e se trata como tal. É montar e vigiar a automação da modelagem de tráfego, o componente que ajusta o seu envio a cada provedor em tempo real. É implantar e sustentar o clustering quando o volume pede, com o seu estado compartilhado entre nós. É conectar o motor com o seu pipeline de dados — webhooks, filas, métricas — para que ele não seja uma caixa-preta. É planejar e executar o aquecimento de IPs, responder aos bounces e aos códigos dos provedores, e manter-se em dia com cada versão do projeto. Cada uma dessas peças é gerenciável; juntas, são um trabalho de tempo parcial que alguém tem que fazer bem e de forma constante. Esse alguém é o que oferecemos.

Como se opera o KumoMTA sem console web?

O KumoMTA não inclui uma interface web, e é uma decisão de design: opera-se como código, não a cliques. Para algumas equipes isso é justo o que valorizam; para outras, é o único ponto que sentem falta. Quando faz falta visibilidade, nós a montamos por cima sem renunciar à filosofia do produto. O KumoMTA expõe ferramentas de monitoramento em tempo real, como a sua consola para ver filas e eventos ao vivo, e se integra com painéis como Grafana sobre métricas de Prometheus. Sobre essa base construímos a observabilidade que a sua equipe precisa: estado por domínio e por IP, filas, taxas de entrega e bounce, alertas. O resultado é o melhor dos dois mundos: a potência da configuração como código e a clareza de um painel quando é preciso olhar o que se passa.

A automação da modelagem significa que ele se opera sozinho?

A peça que mais distingue o KumoMTA em produção é a sua automação da modelagem de tráfego. Os grandes provedores devolvem, nas suas respostas SMTP, pistas sobre como estão tratando você: conexões demais, mensagens demais por conexão, ritmo excessivo, reputação. O KumoMTA escuta esses sinais por meio de um componente dedicado e ajusta as regras de envio a cada provedor em tempo real, para manter-se dentro do que cada um tolera. Bem-conduzido, isso significa melhor entrega e menos bounces por excesso de empurrão; mal-conduzido ou sem configurar, é potência desperdiçada. Operá-lo de verdade implica implantar esse componente — que em ambientes grandes roda como um serviço à parte —, afiná-lo à sua realidade e vigiá-lo, não só ativá-lo e esquecer. No mercado brasileiro, isso inclui ajustar o comportamento também aos provedores locais como UOL, Terra e BOL, que têm a sua própria base de usuários ao lado de Gmail, Outlook e Yahoo. É uma das partes onde a operação especialista marca uma diferença mensurável na sua chegada à caixa.

# O daemon TSA está vivo e reagindo? (um daemon em silêncio é uma falha oculta)
$ systemctl is-active kumo-tsa-daemon && kcli tsa-status --summary
ativo · 3 regras disparando · último ajuste há 40s · cluster: 3/3 nós inscritos

# As filas drenam e a reputação aguenta por provedor?
$ kcli queue-summary --by-site --top 3
gmail.com    D 41920  Q 18   taxa-adiamento 0.4%   OK
outlook.com  D 28110  Q  0   taxa-adiamento 0.1%   OK
yahoo.com    D 15044  Q  6   taxa-adiamento 0.3%   OK

# Os alertas disparam antes de você notar: esse é o silêncio que você paga

Clustering e escala, operados

Quando o volume cresce, um único nó deixa de bastar, e o KumoMTA é pensado para escalar em cluster. Mas um cluster não se monta sozinho: os nós têm que compartilhar o estado dos limites de envio para não se atropelarem — algo que se resolve, por exemplo, com um armazenamento comum —, a automação do shaping deve se coordenar entre todos, e o conjunto precisa ser implantado de forma reproduzível, muitas vezes em contêineres ou em Kubernetes, com balanceamento e proxies à frente. Operar essa arquitetura é um trabalho de infraestrutura completo: dimensionar, implantar, vigiar e ajustar à medida que o tráfego muda. Nós o assumimos, de modo que o seu envio escala quando você precisa sem que a sua equipe tenha que virar especialista em orquestração de contêineres para consegui-lo.

Registro e analítica

Sem bons registros, operar às cegas é questão de tempo. O KumoMTA se destaca pelo seu sistema de registro via webhooks, que facilita recolher eventos de entrega, bounce e abertura e despejá-los onde você precisar para analisá-los. Mas esses dados só valem se alguém define o que registrar, quanto retê-lo e como convertê-lo em métricas acionáveis. Parte da operação é montar esse fluxo: capturar os eventos relevantes, alimentar os seus painéis e os seus relatórios, e conservar o histórico que permite ver tendências e diagnosticar um problema olhando para trás. Um bom registro é o que converte um incidente confuso em uma causa identificada, porque deixa rastro do que aconteceu e quando. Tratamos a analítica como parte do serviço, não como um acréscimo, porque sem visibilidade não há operação que valha: o que não se mede, não se governa.

Integrações e o pipeline de dados

Uma das grandes vantagens do KumoMTA é que ele deixa de ser uma caixa-preta: conecta-se com o ecossistema que você já usa. Entrega eventos por webhooks, publica em filas como Kafka ou AMQP, expõe métricas a Prometheus e painéis a Grafana, guarda segredos em gestores como Vault e pode consultar bancos de dados ao vivo para decidir. Isso permite tratar o envio como mais uma peça da sua plataforma — observável, automatizada, reproduzível —, mas só se alguém construir e manter essas conexões. Parte da operação gerenciada é montar esse pipeline de dados sob medida: que os seus eventos de entrega cheguem aonde você precisa, que as suas métricas alimentem os seus painéis e que a configuração consuma os seus dados sem intervenção manual. É a diferença entre ter um MTA e tê-lo integrado em como você trabalha.

Multicliente: campanhas e IPs desacopladas

O KumoMTA nasce consciente de campanhas e de clientes: enfileira umas e outros separadamente e permite regras por cliente, o que o torna ideal para plataformas multicliente. E desacopla os clientes dos IPs, o que melhora a experiência dos IPs compartilhados e permite um controle fino de quem envia o quê e como. Para um ESP ou uma plataforma SaaS que envia em nome de muitos, isso é ouro: isola reputações, reparte o risco e permite afinar o comportamento por inquilino. Mas esse poder se governa com configuração, e mal-governado vira um emaranhado. Operá-lo bem significa desenhar essa estrutura de clientes e campanhas com cabeça, mantê-la ordenada à medida que entram e saem, e traduzir as necessidades de cada um em regras que o motor aplica sem que ninguém tenha que lembrá-las.

Segurança e hardening do motor

Um motor de envio mal protegido é um risco para você e para todos. Operar o KumoMTA com seriedade inclui o seu endurecimento: restringir quais redes podem injetar correio para não acabar sendo um relay aberto, exigir cifrado TLS, gerir os segredos em um armazenamento e não em arquivos soltos, manter o sistema operacional atualizado e limitar a superfície exposta. Um relay aberto ou um servidor comprometido coloca você em listas negras e, pior, converte a sua infraestrutura em ferramenta de um atacante. Por isso o hardening é parte do trabalho de base e convém revisá-lo de forma periódica, não só ao implantar. Quando operamos o seu KumoMTA, essa camada de segurança vai incluída e se mantém no tempo, porque um IP comprometido desfaz em uma noite meses de reputação construída com paciência.

Versões e manter-se em dia

O KumoMTA é um projeto vivo: publica melhorias com regularidade, desde novas capacidades de injeção e registro até ferramentas de monitoramento mais afinadas, com lançamentos estáveis frequentes ao longo de 2025 e 2026. Manter-se em dia com essas versões não é opcional se você quer as correções de segurança e as melhorias de desempenho, mas atualizar um motor em produção também não se faz de qualquer jeito. Parte de operá-lo é seguir o ritmo do projeto, ler o que muda em cada versão, testar as atualizações fora de produção e aplicá-las quando são seguras, sem sobressaltos para o seu envio. Um parque congelado em uma versão antiga acumula dívida técnica e risco; um que se atualiza às cegas se expõe a quebrar algo que funcionava. O equilíbrio — em dia, mas com cabeça — é trabalho de operação, e dos que não se notam até que são descuidados.

A configuração como código é uma disciplina

Que o KumoMTA se configure com código em vez de com cliques é uma vantagem, mas exige disciplina para que o seja. Uma configuração em Lua sem controle de versões, sem revisão e sem documentação se converte, com o tempo, em um amontoado que só entende quem o escreveu, e isso prende mais que qualquer licença. Nós tratamos a sua configuração pelo que ela é — código —: versionada, comentada, revisada antes de aplicar e reproduzível. Isso significa que cada mudança é rastreável, que se pode voltar atrás se algo der errado e que o conhecimento não vive na cabeça de uma única pessoa. A configuração como código é a melhor forma de operar um MTA moderno, desde que se opere com a mesma seriedade com que se trata o resto do software de produção. Essa seriedade é parte do que aportamos.

Aquecimento e reputação, semiautomatizados

O KumoMTA pode automatizar boa parte do aquecimento de IPs — subir o volume de forma gradual, pausar e retomar, aplicar regras por cliente —, mas a automação precisa de critério humano por trás. Definir o plano de aquecimento adequado ao seu caso, decidir quando acelerar ou frear conforme como cada provedor responde, e reagir a um desvio que a regra não previu são decisões que um humano experiente toma melhor que um roteiro fixo. Por isso falamos de semiautomação: deixamos que o motor faça o trabalho repetitivo e reservamos o juízo para as pessoas. O mesmo vale para a reputação em geral: vigiamo-la com ferramentas, mas interpretamos os sinais e agimos com critério. A máquina executa; nós decidimos. Essa combinação é a que mantém uma reputação sadia sem os sustos de um piloto totalmente automático.

Implantação: contêineres, nuvem e bare metal

O KumoMTA é pensado para ser implantado de forma flexível, e a escolha de como fazê-lo condiciona a operação. Pode rodar em bare metal, em máquinas virtuais, em contêineres ou em Kubernetes, com balanceadores e proxies à frente para repartir e proteger o tráfego. Cada opção tem o seu equilíbrio entre controle, reprodutibilidade e complexidade: os contêineres e a orquestração facilitam escalar e replicar, em troca de mais uma camada a manter; o bare metal dá controle direto, em troca de menos automação. No Brasil, qualquer que seja a opção, o ambiente precisa ter a saída pela porta 25 disponível — bloqueada nas redes residenciais pela Gerência de Porta 25 do CGI.br e, nas nuvens como a AWS, liberável mediante solicitação —, além do DNS reverso de cada IP em ordem. Parte de operá-lo bem é escolher a implantação que encaixa com a sua escala e a sua equipe, e montá-la de forma reproduzível para que crescer ou recuperar-se de uma falha não seja uma aventura. Implantamo-lo onde fizer sentido para você e o mantemos, de modo que a arquitetura seja uma decisão pensada e não o resultado acidental de como ficou no primeiro dia.

Resposta a incidentes

Cedo ou tarde algo se quebra: um IP é listado, um provedor começa a diferir, um nó cai, uma atualização se comporta diferente do previsto. O que distingue uma operação séria é o que acontece então. A nossa resposta a incidentes parte do monitoramento que detecta o problema — idealmente antes dos seus clientes —, segue com um diagnóstico que lê logs e sinais em contexto, e termina com uma correção e uma validação de que o envio se recuperou. E tudo isso com cobertura em fusos horários da Europa, América do Norte e América Latina, porque os incidentes não respeitam o horário de escritório. A diferença entre um incidente gerenciado e um sofrido é ter alguém preparado e disponível, com o contexto do seu parque já na cabeça, em vez de começar a entender o seu sistema justo quando ele está pegando fogo.

Vocês podem assumir um KumoMTA que outro montou?

Não é preciso começar do zero para que operemos o seu KumoMTA. Se você vem de PowerMTA, fazemos a migração por passos, preservando a reputação, a autenticação e o aquecimento, como detalhamos na página de migração de PowerMTA para KumoMTA. Se você já tem um KumoMTA montado — pela sua equipe ou por terceiros —, começamos por entendê-lo: auditamos a configuração, documentamos o que ela faz, ordenamos o que estiver emaranhado e só então assumimos a sua operação, sem sustos. A incorporação é deliberadamente cuidadosa, porque herdar um parque mal-entendido é a forma mais rápida de quebrar algo que funcionava. O objetivo dessa primeira fase é simples: que saibamos exatamente o que estamos operando antes de tocar em nada.

O que a operação gerenciada do KumoMTA inclui?

A operação gerenciada se nota em um ritmo, não em um documento. Inclui a configuração e a sua manutenção em Lua, versionada e documentada. A automação da modelagem de tráfego, implantada e afinada. O clustering e o escalonamento quando o volume pede. O monitoramento contínuo de filas, entrega, bounces e reputação, com alertas. A resposta a incidentes quando ocorrem, não no próximo relatório. A manutenção em dia com cada versão do projeto. E um relatório periódico com o que aconteceu, o que fizemos e o que recomendamos, em uma cadência acordada. Tudo isso em fusos horários da Europa, América do Norte e América Latina, porque um problema de envio não espera o seu horário de escritório. O que você recebe, no fundo, é um motor que funciona e uma equipe que responde por ele.

Conformidade e soberania de dados

Operar o seu próprio KumoMTA, em vez de delegar a uma nuvem de envio de terceiros, tem uma vantagem que para alguns é decisiva: o controle sobre onde vivem os seus dados. Como o motor roda na sua infraestrutura — on-prem ou em uma nuvem privada —, você decide em que país se processam e armazenam os seus correios, algo que importa sob a LGPD no Brasil, fiscalizada pela ANPD, e sob o RGPD em Portugal e na Europa, além das leis de Angola e Moçambique. Essa soberania é um dos motivos pelos quais organizações lusófonas ou que lidam com dados sensíveis escolhem um motor próprio frente a um serviço gerenciado por um terceiro, e quem precisa de residência local pode mantê-lo em nuvem ou datacenter em território brasileiro. A operação gerenciada não muda essa propriedade: a infraestrutura e os dados seguem sendo seus, e a parte de consentimento e supressão se opera respeitando os prazos do CAPEM — o código de autorregulação brasileiro avalizado pelo CGI.br — para o opt-out e a higiene de listas. Você tem o controle dos dados de uma solução própria com a tranquilidade de uma operação especialista por cima.

Gerenciado, cogerenciado ou consultoria

Nem todas as empresas querem o mesmo grau de envolvimento, então oferecemos três modelos. Você escolhe conforme a equipe que já tem e o controle que quer conservar.

O objetivo: um parque que funciona em silêncio

O melhor sinal de um KumoMTA bem-operado é que ele não dá o que falar. Não há incêndios para apagar às três da manhã, nem campanhas que voltam sem explicação, nem reputação que desaba enquanto ninguém olha. O correio sai, chega e ninguém tem que pensar nisso. Esse silêncio não é acaso: é o resultado da vigilância constante, dos ajustes a tempo e da disciplina de configuração que evitam que os problemas cresçam. Como dizia um usuário satisfeito do motor, o objetivo é que ele seja a parte do seu sistema em que você gasta menos tempo, porque simplesmente faz o que deve. Levar o seu KumoMTA a esse estado — e mantê-lo ali — é, em uma frase, tudo o que este serviço promete.

Para quem é

O KumoMTA gerenciado encaixa com quem precisa do controle e da potência de um motor próprio sem querer montar a equipe para operá-lo. O ESP ou a plataforma multicliente que envia em nome de muitos e precisa isolar reputações e afinar por inquilino. O produto SaaS de alto volume cujos correios — operacionais e de marketing — são críticos. A empresa que deixa uma nuvem cara ou um PowerMTA com licença e quer a economia do aberto sem a carga de operá-lo. Ou quem já tem KumoMTA mas descobriu que mantê-lo bem é mais trabalho do que previa. O que todos compartilham é a mesma equação: querem o que o KumoMTA oferece — controle, potência, sem licença — e preferem delegar o como a quem o faz todos os dias, em vez de pagá-lo em tempo e sustos próprios.

KumoMTA gerenciado frente a um PowerMTA gerenciado

Uma pergunta habitual é se gerenciar KumoMTA ou um PowerMTA. A resposta, como na seleção de motor, depende do seu caso. O KumoMTA gerenciado dá a você a economia de licença e uma configuração flexível como código, ideal se você valoriza a integração profunda e não se incomoda que o suporte de base seja de comunidade, porque o de serviço nós pomos. Um PowerMTA gerenciado faz sentido se você já tem licença e quer seguir com o suporte de fabricante por trás, ou se a sua equipe conhece a fundo a sua configuração declarativa e prefere não trocar. Em ambos os casos aportamos a operação; o que muda é o motor por baixo. E se você tem dúvida de qual lhe convém, essa decisão a abordamos antes, em um exercício de seleção sem viés, porque não ganhamos mais com um do que com o outro.

Quando você não precisa que a gente gerencie

Por coerência, nem todo mundo precisa delegar a operação, e dizemos isso. Se você tem uma equipe com cultura de DevOps, experiência em MTAs e capacidade de plantão, é perfeitamente possível operar o KumoMTA por conta própria apoiando-se na comunidade e na documentação do projeto. Nesse caso, talvez só lhe interesse uma consultoria pontual para arrancar bem ou para revisar a sua configuração, sem uma operação contínua em cima. Se você cai nesse grupo, dizemos isso e poupamos uma mensalidade que você não precisa: preferimos um cliente que volta quando de fato fazemos falta a um que paga por algo que a sua própria equipe já sustenta.

Continuidade: o seu parque, sempre retomável

Uma operação gerenciada honesta não prende você, e com o KumoMTA isso é ainda mais claro porque não há licença de por meio. Tudo o que operamos vive sobre a sua infraestrutura e os seus IPs, e a configuração em Lua é sua desde o primeiro dia: versionada, comentada e reproduzível, não um segredo guardado na nossa cabeça. Se um dia você decidir levar a operação para dentro de casa ou para outro fornecedor, entregamos o parque ordenado e documentado, com o estado atual explicado, e, se quiser, formamos a sua equipe sobre a sua própria instalação. Essa portabilidade é consequência direta de não revender software nem plataforma: como não há nada nosso embutido no seu envio, nada retém você além do valor do trabalho em si. Preferimos um cliente que fica pelo serviço, não pelo custo de sair.

Por que com uma consultoria independente

Operar o KumoMTA conosco tem uma vantagem que um fabricante não pode oferecer: não temos um produto para defender. Não revendemos licenças — o KumoMTA é grátis — nem prendemos você a uma plataforma própria, então a nossa única tarefa é que o seu motor funcione e o seu correio chegue. Isso nos deixa recomendar o que de verdade lhe convém, incluído dizer quando o KumoMTA não é a resposta e outra opção encaixa melhor. Trabalhamos na camada de infraestrutura do correio todos os dias, operamos o KumoMTA em produção e conhecemos as suas virtudes e as suas asperezas em primeira mão, não por um folheto. E quando um problema de envio acaba sendo mais amplo que o motor, o abordamos a partir de uma auditoria, porque o motor é o meio, não o fim.

O ponto de partida é entender a sua situação: a auditoria de 25 pontos mede o seu envio atual e nos diz se o KumoMTA gerenciado encaixa com você e com que escopo. É a forma de começar com dados em vez de com um contrato às cegas.