MTA próprio vs API de email: custo, controle e vendor lock-in

Manter um MTA próprio dá controle total sobre IPs, filas e reputação e pode sair mais barato por mensagem em volume alto, mas exige uma equipe que opere entregabilidade continuamente: warm-up, bounces, feedback loops, listas de bloqueio, DNS e monitoramento. Uma API de email terceiriza essa operação e acelera o início, ao custo de preço por mensagem, menos controle e risco de vendor lock-in. Para a maioria das empresas, a melhor escolha é uma API que mantenha autenticação, dados e eventos no seu domínio e em formatos abertos, para que trocar de fornecedor seja possível.

O que um MTA faz de verdade

Um MTA (Mail Transfer Agent) aceita mensagens, enfileira, resolve o MX do destino, conecta via SMTP e tenta entregar. Exemplos conhecidos: Postfix, Exim, Haraka, KumoMTA e opções comerciais como o PowerMTA. Instalar um é simples. Operar um para envio em escala é outra coisa, porque o MTA é só o centro de um sistema maior:

• Autenticação: assinatura DKIM por domínio, SPF, DMARC, rotação de chaves.
• Infraestrutura de IP: PTR, HELO coerente, TLS, pools por tipo de tráfego.
• Warm-up: aumento gradual de volume por IP e por provedor de destino.
• Controle de ritmo por provedor, reagindo a respostas 421/4.7.x.
• Tratamento de bounces: síncronos e DSNs assíncronas (RFC 3464), VERP, classificação.
• Feedback loops: cadastro nos programas, parser de ARF (RFC 5965).
• Supressão: hard bounces, reclamações e descadastros por stream.
• Descadastro de um clique (RFC 8058) com endpoint seguro.
• Eventos para a aplicação: webhooks, retentativas, idempotência.
• Monitoramento: listas de bloqueio, Postmaster Tools, métricas por domínio de destino.

A conta de "MTA próprio" precisa incluir todos esses itens, não só o servidor.

Custos: onde está o dinheiro

MTA próprio

• Infraestrutura: servidores, armazenamento de filas e logs, IPs. Em volume alto, o custo por mensagem pode ser bem menor que o de uma API.
• Rede: muitos provedores de nuvem bloqueiam ou restringem a porta 25 de saída por padrão; é preciso pedir liberação ou usar provedores que permitam. IPs de nuvem às vezes chegam com histórico ruim.
• Pessoas: esse é o custo dominante. Alguém precisa acompanhar entregabilidade todos os dias, responder a bloqueios, negociar remoção de listas e manter o sistema atualizado.
• Risco: um incidente (lista ruim, conta comprometida) pode bloquear IPs e domínio por dias, com impacto direto em login, cobrança e vendas.

API de email

• Preço por volume, previsível e geralmente mais alto por mensagem em escala.
• Menos pessoas dedicadas à infraestrutura de envio.
• Custo de troca, que depende de quanto o fornecedor prende você.

A pergunta útil não é "qual é mais barato por mensagem", e sim "qual é o custo total com o nível de entregabilidade que preciso".

Controle: o que você ganha e o que perde

Vendor lock-in: como ele acontece

O lock-in em email raramente é contratual. Ele se acumula em detalhes técnicos:

1. Autenticação no domínio do fornecedor. Se o DKIM assina com d=fornecedor.example e o Return-Path é do fornecedor, a reputação construída pertence a ele. Ao trocar, você começa do zero.
2. Lista de supressão presa. Anos de bounces, reclamações e descadastros ficam no fornecedor. Migrar sem eles significa reenviar para quem reclamou, o que derruba a reputação logo na estreia.
3. Templates e lógica proprietários. Linguagens de template específicas e regras de envio configuradas no painel.
4. Eventos em formato próprio. Cada fornecedor tem nomes de eventos, payloads e esquemas de assinatura diferentes; o código de webhook vira acoplamento.
5. Uso de recursos exclusivos espalhados pelo código, sem uma camada de abstração.

Como escolher uma API sem ficar preso

Checklist para avaliar qualquer fornecedor:

• [ ] DKIM com o seu domínio (d=example.com.br) e chave por domínio.
• [ ] Return-Path em subdomínio seu (bounces.example.com.br), com SPF alinhado.
• [ ] Exportação da lista de supressão com motivo e data, a qualquer momento.
• [ ] Webhooks em padrão aberto, como Standard Webhooks, verificáveis com bibliotecas comuns.
• [ ] Envio por SMTP além da API, como saída de emergência e caminho de migração.
• [ ] Templates renderizados na sua aplicação ou em formato portátil.
• [ ] Transparência sobre a infraestrutura: se o fornecedor revende outro serviço de envio, você herda o lock-in dele também.

E, do seu lado, isole o envio atrás de uma interface:

interface EnvioDeEmail {
  enviar(msg: {
    de: string;
    para: string[];
    assunto: string;
    html: string;
    texto: string;
    stream: "transacional" | "marketing";
    chaveIdempotencia: string;
  }): Promise<{ id: string }>;
}

Com isso, trocar de fornecedor é implementar um adaptador, não reescrever o sistema.

Quando faz sentido o MTA próprio

• Volume muito alto e constante, em que a diferença por mensagem paga uma equipe.
• Exigências regulatórias ou contratuais de manter o envio em infraestrutura própria.
• Necessidade de controle fino que nenhum fornecedor oferece.
• Equipe com experiência real em entregabilidade, não só em administrar Linux.

Quando faz sentido a API

• Produto em crescimento, com volume variável.
• Time de engenharia focado no produto, sem especialista em entregabilidade.
• Necessidade de começar a enviar em dias, não em meses.
• Desejo de ter supressão, webhooks e conformidade com Gmail e Yahoo prontos.

Erros comuns

• Comparar só o preço do servidor com o preço por mensagem da API.
• Subir um Postfix em uma VM de nuvem sem PTR, sem warm-up e sem tratamento de bounces.
• Aceitar autenticação no domínio do fornecedor por ser "mais rápido de configurar".
• Não exportar a lista de supressão antes de migrar.
• Espalhar chamadas ao SDK do fornecedor por todo o código.

Onde a Pidgely se encaixa

A Pidgely foi construída para ficar no meio desse caminho: oferece uma API para desenvolvedores, mas roda MTA próprio, sem revender outro fornecedor de envio, com DKIM e return-path no seu domínio, supressão automática e webhooks no padrão Standard Webhooks. Assim, a reputação e os dados continuam sendo seus, e sair é tão possível quanto entrar.