Migração de PowerMTA para KumoMTA

Migrar o motor que move o seu correio assusta por uma boa razão: se for feito mal, a entregabilidade cai e se nota no resultado. Por isso uma migração de PowerMTA para KumoMTA não é uma troca de software, e sim uma operação de reputação. Feita com método, é invisível: o correio segue chegando igual no dia seguinte e no dia anterior, e o único que muda é o que você paga de licença e o que você pode fazer com a configuração. Esta página explica por que cada vez mais remetentes a consideram, o que muda de verdade e como a executamos sem que a sua caixa de entrada fique sabendo.

Por que os remetentes estão migrando

Duas coisas empurram a conversa. A primeira é o rumo do PowerMTA: desde que o produto foi integrado à plataforma omnichannel da Bird, as suas equipes dedicadas de suporte e desenvolvimento ficaram mais magras, e os remetentes que dependem dele olham com inquietação um roteiro que avança devagar enquanto a fatura de licença — da ordem de vários milhares de dólares por ano — se repete pontual. A segunda é que apareceu uma alternativa séria: o KumoMTA, de código aberto, moderno e gratuito, construído por veteranos da indústria que há décadas fazem MTAs de alto desempenho. Não é que o PowerMTA tenha deixado de funcionar; é que, pela primeira vez, ficar tem um custo de oportunidade claro.

A isso se soma um contexto que não perdoa a mediocridade técnica. Desde novembro de 2025 o Gmail rejeita o correio em massa não conforme no próprio SMTP, e a Microsoft aplica os seus requisitos desde maio de 2025. A camada que decide se você cumpre — autenticação, modelagem de tráfego, gestão de filas — é justo a que você toca ao migrar, então muitas empresas usam esse movimento para deixá-la melhor do que estava.

O que é o KumoMTA, e como se compara ao PowerMTA?

O KumoMTA é um MTA de código aberto, publicado sob licença Apache 2.0 e com o código no GitHub, escrito do zero em Rust e pensado para o envio de saída de alto volume. A sua arquitetura é assíncrona e orientada a eventos, o que lhe permite lidar com muita concorrência, e persiste as mensagens em disco para não perdê-las diante de uma queda. A sua configuração não vive em um arquivo de texto estático, e sim em código Lua que se executa dentro do próprio MTA: configuração como código, com tudo o que isso permite — condicionais, laços, conexão direta a bancos de dados e a ferramentas como Prometheus ou Grafana. É gerido por uma comunidade ativa que inclui alguns dos maiores remetentes do mundo, com lançamentos estáveis frequentes ao longo de 2025 e 2026. O que não traz, por decisão de design, é uma interface web: opera-se como código, não a cliques.

PowerMTA frente a KumoMTA

A comparação honesta não é «um bom e outro ruim», e sim duas ferramentas com filosofias distintas. O PowerMTA é o padrão comercial de uma era de servidores dedicados; o KumoMTA é a resposta moderna e aberta. Isto é o que muda entre ambos.

A diferença que mais se nota no dia a dia é a configuração. Os «one-liners» do PowerMTA são cômodos mas rígidos: o que você escreve é o que há. A configuração em Lua do KumoMTA condensa essa mesma lógica com condicionais e iteração, e permite que o MTA consulte dados ao vivo em vez de depender de arquivos que é preciso regenerar e recarregar. Para uma equipe com práticas de DevOps, isso é liberdade; para uma acostumada a editar um arquivo plano, é a curva de aprendizado que justifica trazer alguém que já a percorreu.

O custo de oportunidade de ficar

Ficar também tem um preço, ainda que ele não apareça em uma fatura com o seu nome. Cada ano que passa sobre um PowerMTA cuja equipe de desenvolvimento ficou mais magra é um ano em que o roteiro do produto avança devagar enquanto as regras dos grandes provedores aceleram, e essa distância se paga em flexibilidade perdida e em ajustes que você gostaria de fazer e a configuração declarativa não deixa. Some-se a licença comercial recorrente, de vários milhares de dólares por ano, que se repete pontual independentemente de quanto valor novo o produto lhe entrega. Nada disso obriga a migrar amanhã, e um PowerMTA estável segue cumprindo; mas pôr esse custo de oportunidade na balança, ao lado do custo real de migrar, é o que transforma a decisão de uma intuição em uma conta. Muitas vezes o resultado é esperar; outras, é descobrir que o «depois» já chegou.

É a hora de migrar do PowerMTA para o KumoMTA?

Nem sempre é, e dizemos isso antes de cobrar nada. Se o seu PowerMTA cumpre, a sua equipe o conhece a fundo e a sua prioridade é a estabilidade acima do custo, o certo pode ser ficar e otimizar o que você já tem até a migração encaixar no seu calendário. Se, em troca, o rumo do produto incomoda você, a fatura recorrente pesa, ou você quer uma configuração que se integre de verdade com o seu ambiente, a migração faz sentido. Parte do nosso trabalho é ajudar você a tomar essa decisão sem viés, porque não temos nenhuma licença para vender em nenhuma das duas direções. Quando a pergunta é mais ampla — PowerMTA, KumoMTA, Halon ou MailerQ —, a abordamos como um exercício de seleção de MTA, não como uma venda.

O que muda tecnicamente ao migrar para o KumoMTA?

A boa notícia para quem vem de PowerMTA é que os conceitos se transferem. O que no PowerMTA você chama de VirtualMTA tem o seu equivalente no «egress source» do KumoMTA: ali você gere o controle de entrega e o throttling por IP. As diretivas soltas do PowerMTA passam a viver em uma configuração Lua mais estruturada e flexível, e os ajustes que você um dia adicionou como remendos — rodar como root, lidar com arquivos órfãos — muitas vezes deixam de ser necessários. A mudança não é traduzir linha por linha, e sim reexpressar a sua intenção de envio em um modelo mais capaz. Essa tradução é onde se ganha ou se perde uma migração, e é exatamente a parte que convém que faça alguém que conhece os dois lados.

Desempenho e arquitetura: o que esperar

A arquitetura é onde o KumoMTA mostra a sua idade, no bom sentido. Está escrita em Rust sobre um runtime assíncrono, de modo que cada operação — da recepção até a entrega — se trata sem bloquear, o que lhe permite sustentar muita concorrência em hardware razoável. Persiste as mensagens em disco em vez de mantê-las em memória, o que protege a fila diante de uma queda em troca de que o desempenho de disco entre na equação. Frente à arquitetura do PowerMTA, pensada para servidores dedicados e que escala primeiro na vertical, o KumoMTA é concebido para ambientes de nuvem e para crescer de forma mais natural. Na prática, para a maioria dos remetentes o gargalo não é o MTA, e sim a reputação e os limites dos receptores, então trocar de motor raramente é o que sobe o seu volume. O que muda, sim, é o teto e a flexibilidade quando você chega a ele, e essa diferença se nota justo quando mais dói: em escala.

Como encaixa na sua pilha

Uma das razões pelas quais as equipes com práticas de DevOps escolhem o KumoMTA é que ele deixa de ser uma caixa-preta. A configuração como código se versiona junto ao resto da sua infraestrutura, e o MTA se conecta com o ecossistema que você já usa: webhooks para eventos, filas como Kafka ou AMQP, métricas para Prometheus e painéis em Grafana, segredos em Vault e acesso direto a bancos de dados para decisões em tempo real. Em vez de regenerar arquivos e recarregar o serviço a cada vez, a configuração se carrega tarde, consome menos memória e consulta os dados vivos sem rodeios. Há um detalhe de infraestrutura que no Brasil convém resolver cedo: o servidor de destino do KumoMTA precisa ter a porta 25 de saída disponível para o transporte entre servidores, então não pode viver em um link residencial, que pela Gerência de Porta 25 do CGI.br tem essa porta bloqueada; e em nuvens como a AWS a saída pela porta 25 vem bloqueada por padrão e exige uma solicitação para ser liberada. Para uma operação que quer tratar o envio como mais uma peça da sua plataforma — observável, automatizada, reproduzível —, esse encaixe é boa parte do atrativo, e muitas vezes pesa mais na decisão que a própria economia de licença.

# PowerMTA: um VirtualMTA com a sua IP e o ritmo por domínio (diretivas)
<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: a mesma intenção 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 provedor, partindo do piso comunitário
['gmail.com'] max_message_rate = '180/min'

A curva de Lua, sem dramatizar

O argumento que mais freia as equipes é a configuração em Lua, e convém pô-lo no seu lugar. Lua é uma linguagem de scripting simples de ler e escrever, a mesma que usam desde appliances de segurança até videogames, e a maioria das configurações de correio se expressa nela sem precisar ser programador. A curva existe, sobretudo para quem vinha de editar um arquivo plano de diretivas, mas é uma curva de dias, não de meses, e se percorre uma só vez. Além disso, você não tem que percorrê-la sozinho: nós escrevemos a configuração inicial, a deixamos comentada e, se a sua equipe quer autonomia, a formamos sobre a sua própria instalação. A flexibilidade que você ganha — condicionais, dados ao vivo, lógica reutilizável — compensa de sobra o tempo de aprendizado.

Como executamos a migração sem precipício

A nossa metodologia existe por uma só coisa: que a entregabilidade nunca encontre um degrau. Segue sempre o mesmo arco.

1. Descoberta e auditoria. Mapeamos a sua estrutura atual — VirtualMTAs, parque de IPs, domínios, autenticação, regras de throttling — e a documentamos como ponto de partida verificável.
2. Replicação da configuração. Reexpressamos a sua lógica de envio em Lua, conservando o comportamento por IP e por provedor, e a versionamos para que cada mudança seja rastreável.
3. Preservação da reputação. Migramos as chaves DKIM, os registros SPF e o estado de aquecimento, de modo que os IPs cheguem ao KumoMTA com o seu histórico intacto.
4. Virada por pool de IPs. Movemos o tráfego pool a pool, não tudo de uma vez, validando cada passo antes de avançar.
5. Validação com seed lists. Comprovamos a chegada à caixa de entrada antes e depois de cada virada, nos grandes provedores, para confirmar que nada se moveu.
6. Plano de reversão. Cada passo tem volta atrás, então um imprevisto é uma pausa, nunca uma crise.

Como testamos antes de mover produção

Nenhum tráfego real se move até que o KumoMTA tenha provado que se comporta como deve, e isso se faz à parte da sua operação viva. Montamos a nova configuração em um ambiente de testes que espelha o seu, injetamos correio de prova e seed lists, e comparamos o comportamento — throttling por provedor, assinatura, processamento de bounces, formato dos cabeçalhos — com o que o seu PowerMTA faz hoje. Só quando os números batem e a entrega de prova chega à caixa de entrada nos grandes provedores começamos a virar pools reais. Esse passo de validação prévia é o que separa uma migração de uma aposta: em vez de cruzar os dedos no dia da virada, você chega a ele com a evidência de que o motor novo já fazia, em ensaio, o mesmo que o velho. E como o teste roda em paralelo, a sua operação atual segue intacta enquanto preparamos a substituta.

Erros que uma migração cuidadosa evita

Quase todas as migrações que dão errado repetem os mesmos tropeços, e conhecê-los é metade de evitá-los. O mais caro é virar todo o tráfego de uma vez: economiza uma semana de calendário e põe toda a sua reputação em um só movimento. Segue traduzir a configuração linha por linha sem entender a intenção por trás, o que arrasta ao KumoMTA os remendos e esquisitices que o PowerMTA acumulou com os anos. Depois está descuidar o alinhamento: migrar as chaves DKIM mas não conferir que seguem alinhadas com o domínio visível, e descobrir por uma rejeição. E o mais silencioso, reiniciar o aquecimento sem querer ao mover IPs sem preservar o seu estado, o que joga fora meses de reputação por um descuido de procedimento. Nenhum é inevitável; todos se evitam com método, com um ponto de partida documentado e com validação em cada passo. A diferença entre uma migração tranquila e uma atribulada raramente é a ferramenta: é o cuidado com que se executa.

O que se conserva no caminho

A pergunta que mais nos fazem é o que se perde, e a resposta curta é: nada que importe. Conserva-se a reputação dos seus IPs e domínios, porque vive neles e não no software. Conservam-se as chaves DKIM e os registros SPF, que migramos sem quebrar a assinatura. Conserva-se o estado de aquecimento de cada IP, para não reiniciar meses de trabalho. E transfere-se a sua lógica de throttling e de filas, reexpressa em um modelo mais flexível mas com o mesmo comportamento diante do provedor. O processamento de bounces e o registro detalhado, que são a base de qualquer diagnóstico, saem reforçados, porque o KumoMTA os expõe melhor.

Por que migrar um pool de IPs de cada vez?

Virar todo o tráfego de uma vez é a forma mais rápida de converter um problema pequeno em um geral. Se algo se configura mal, você descobre com todo o seu volume em cima e todos os seus IPs comprometidos ao mesmo tempo. A virada por pool acota o risco: você move um grupo de IPs, o valida com dados reais de entrega durante um tempo, e só então avança ao seguinte. Se aparece um detalhe — um alinhamento que falha, um throttle mal calibrado —, você o resolve sobre uma fração do tráfego e com margem para voltar atrás. É mais lento de ler em um calendário e muito mais seguro de viver em produção.

Você não é o primeiro a fazê-lo

Migrar de PowerMTA para KumoMTA deixou de ser território inexplorado. Operadores sérios de correio, incluídos provedores que movem volumes enormes em ambientes multicliente onde a reputação de cada conta importa, fizeram a troca e a contaram: testaram o KumoMTA a fundo antes de mover produção, valorizaram a configuração em Lua para ajustar o comportamento por fluxo e por pool de IPs, e ficaram pela transparência de um código aberto sem surpresas de licença. Que alguns dos maiores remetentes do mundo contribuam para a sua comunidade é, em si, um sinal: o risco de adotar uma tecnologia imatura não é o que você corre aqui. O que resta é executar bem o seu caso concreto, que é justo onde uma mão experiente marca a diferença entre semanas de calma e um incidente evitável.

Quanto custa de verdade uma migração para o KumoMTA?

Uma migração típica leva de duas a seis semanas, marcadas pelo seu número de VirtualMTAs, o tamanho do seu parque de IPs e o volume de dados. Do lado do software, o KumoMTA não acrescenta custo de licença: a economia frente à fatura comercial recorrente é real e se nota ano após ano. Do lado do projeto, o que você paga é o trabalho de fazê-lo bem uma vez — a tradução da configuração, a preservação da reputação, a validação — em vez de pagá-lo em entregabilidade perdida se for feito às pressas. A comparação sensata não é «grátis frente a caro», e sim «uma migração cuidadosa frente ao custo de uma campanha que não chega».

A janela de migração e o seu calendário de envio

Quando migrar importa quase tanto quanto como migrar. A virada por pool leva semanas, e fazê-la no meio do seu pico de envio é procurar problema: um período de campanhas intensas — uma Black Friday, uma data sazonal forte no varejo brasileiro, o fechamento de um trimestre — é exatamente quando você menos quer que a sua reputação esteja em movimento. Por isso planejamos a janela em torno do seu calendário real, deixando a virada para um período de tráfego mais calmo e previsível, com folga antes do próximo pico para que tudo já esteja estável e validado quando o volume subir. Se o seu negócio não tem um vale claro, dividimos a migração em janelas menores que evitem os picos conhecidos. Migrar contra o relógio de uma campanha é o tipo de pressa que a virada por pool foi desenhada para evitar, e respeitar o seu calendário é parte de fazer a coisa sem sobressaltos.

O que o projeto inclui

Para que você saiba o que recebe e não só o que paga, uma migração conosco entrega quatro coisas concretas. Uma configuração de KumoMTA equivalente à sua, escrita em Lua, documentada e versionada, que é sua desde o primeiro dia. Um registro da migração com o estado de cada pool e cada validação, de modo que a qualquer momento você sabe o que se moveu e o que falta. Os testes de entregabilidade com seed lists antes e depois de cada virada, para demonstrar — não afirmar — que a entrega se manteve. E, se você quiser, a formação para que a sua equipe opere a nova configuração com desenvoltura. O objetivo é que você termine a migração com mais controle sobre o seu envio do que tinha ao começar, não com uma dependência nova disfarçada de serviço.

Você vem de Momentum ou de outro motor?

O PowerMTA não é a única origem da qual migramos. Se você arrasta Momentum (Ecelerity) ou outro MTA herdado que já não recebe o suporte que precisa, a abordagem é a mesma: mapear a sua lógica de envio, reexpressá-la no KumoMTA e mover o tráfego por passos validados sem tocar na sua reputação. De fato, o arquiteto que desenhou o motor Momentum está por trás do KumoMTA, então muitos conceitos viajam com naturalidade e boa parte da sua experiência operacional segue válida. Se você não tem claro qual motor lhe convém — KumoMTA, uma otimização do que já tem ou algo distinto —, o abordamos como uma decisão técnica com o seu interesse à frente, não como uma venda fechada de antemão.

O que não muda ao migrar

Convém dizer também o que fica igual, porque tranquiliza tanto quanto o que melhora. Os seus domínios de envio não mudam. Os seus IPs seguem sendo seus, com o seu histórico e o seu aquecimento intactos. A sua autenticação — SPF, DKIM e DMARC — se mantém válida e alinhada. As suas integrações com a aplicação que injeta o correio seguem funcionando, porque o KumoMTA recebe a mensagem pelos mesmos protocolos. E o seu volume e os seus limites com os provedores não se reiniciam: a reputação que tanto custou construir viaja com você. Migrar bem não é começar do zero; é mudar de casa sem perder uma caixa, e acordar em um lugar com mais espaço.

Migração e conformidade, de mãos dadas

Há uma razão de peso para não separar a migração da conformidade. Os requisitos que Gmail, Yahoo e Microsoft endureceram nos últimos dois anos — autenticação obrigatória com SPF, DKIM e DMARC, taxas de reclamação abaixo de limites estritos, um cabeçalho de descadastro em um clique para o correio em massa — se aplicam exatamente na mesma camada que você toca ao trocar de MTA. No Brasil, soma-se o CAPEM, o Código de Autorregulamentação para a Prática de E-mail Marketing avalizado pelo CGI.br, que exige opt-in ou soft opt-in, envio a partir de domínio próprio e um opt-out respeitado em no máximo dois dias úteis pelo link de descadastro e cinco por outros meios, com uma segunda alternativa de baixa que não seja um link clicável. Migrar às pressas e deixar essa camada como estava é desperdiçar a melhor oportunidade de pô-la em ponto, porque você já está com as mãos lá dentro. Migrar com critério significa sair do KumoMTA conforme desde o primeiro envio: com a autenticação alinhada de verdade e não só presente, com a gestão de bounces e reclamações conectada aos sinais dos receptores, e com a modelagem de tráfego afinada provedor a provedor — incluídos os provedores locais como UOL, Terra e BOL — em vez de copiada a olho. Por isso a nossa migração não se limita a transferir a configuração: revisa de passagem que você cumpre o que hoje exigem os grandes provedores e o CAPEM, ajusta o que for preciso e o valida com dados reais de entrega. O resultado é que o projeto que você contrata por um motivo — trocar de motor — resolve também o outro, que é chegar à caixa em um ambiente cada vez menos tolerante.

Onde os seus dados ficam ao migrar

Uma migração costuma ser também o momento em que se decide onde a infraestrutura vai viver, e isso tem implicação de conformidade no mundo lusófono. Se a troca de motor traz junto uma troca de hospedagem ou de país, convém pôr a residência dos dados na conta: a LGPD no Brasil, fiscalizada pela ANPD, e o RGPD em Portugal e na Europa marcam princípios de minimização e de tratamento que é melhor respeitar de fábrica do que remendar depois. Ter o seu próprio KumoMTA em infraestrutura que você controla permite decidir em que país se processam e armazenam os seus correios, algo que importa para setores regulados e para quem tem clientes que exigem residência local. Levamos isso em conta ao desenhar o destino da migração, para que você não troque um problema de motor por um de conformidade.

O painel que o KumoMTA não traz

Para algumas equipes, a ausência de interface web é justo o que valorizam; para outras, é o único ponto que sentem falta ao deixar para trás qualquer ferramenta com consola. Quando faz falta, montamos um painel de observabilidade e gestão por cima do KumoMTA — filas, métricas de entrega, estado por domínio e por IP — sem renunciar à configuração como código que torna o produto potente. É a peça que o projeto não inclui por design e que nós adicionamos quando aporta, não por padrão.

Por que uma consultoria independente

Na entregabilidade há muitos atores com algo para lhe vender: fabricantes com a sua licença, plataformas com a sua assinatura, provedores de hospedagem com o seu servidor. Nós não revendemos o KumoMTA — é grátis — nem licenças de PowerMTA, então quando recomendamos migrar, ficar ou otimizar, não há um produto por trás empurrando a resposta. Essa independência muda a conversa: podemos dizer a você que não migre se não lhe convém, podemos escolher a arquitetura que melhor encaixa no seu caso em vez da que mais nos rende, e podemos dar a configuração para que você a opere sem nós se assim preferir. Trabalhamos na camada de infraestrutura do correio todos os dias, com equipes em vários fusos horários, e o nosso único incentivo é que o seu correio chegue. Quando quem aconselha não vende o produto que recomenda, os seus conselhos valem mais.

Quem opera o KumoMTA depois da migração?

Uma migração não termina na virada. Se a sua equipe quer as chaves, deixamos a configuração documentada e versionada e a formamos para mantê-la. Se você prefere que sigamos ao volante, operamos o seu KumoMTA como uma extensão da sua equipe: monitoramento, ajuste e resposta a incidentes, em fusos horários da Europa, América do Norte e América Latina. Em ambos os casos a infraestrutura é sua e a independência é nossa: não há um fabricante por trás cujos interesses tenhamos que servir antes dos seus.

Se você está sopesando o movimento, o ponto de partida não é uma proposta, e sim uma foto. A auditoria gratuita de 25 pontos mede onde está hoje o seu PowerMTA — configuração, reputação e chegada à caixa de entrada — e diz a você, sem compromisso, se migrar lhe convém e o que faria falta. É a melhor forma de decidir com dados em vez de com intuição.