APIs de e-mail · 21 de setembro de 2026

Por que os mesmos 50.000 e-mails custam $5 ou $66

Uma análise aprofundada da variação de preços entre APIs de e-mail. Mostramos por que o mesmo volume de 50 mil e-mails custa até 13x mais de um provedor para outro e como escolher com base nas suas restrições de engenharia.

A diferença de preço explicada

A diferença de preço se resume ao modelo de negócio: infraestrutura versus plataforma. O Amazon SES vende computação e banda brutas (infraestrutura), enquanto provedores como o Postmark ou o Mailgun vendem uma experiência gerenciada (plataforma), com interface melhor, suporte especializado e pools de IP selecionados. Para 50.000 e-mails, o SES na modalidade avulsa custa cerca de $5, enquanto os planos do Postmark podem chegar a $66. Você está pagando pela redução da carga operacional e pela qualidade das ferramentas em torno da API.

A conta crua: 50.000 e-mails

Quando olho para a fila de incidentes ou para a fatura mensal de nuvem, a disparidade nos preços de e-mail é um dos itens que mais chamam a atenção. Para entender o porquê, precisamos olhar os preços de mercado vigentes em setembro de 2026.

A abordagem de infraestrutura: Amazon SES

O Amazon SES é a referência de custo. Segundo a página de preços, o envio na modalidade avulsa custa $0.10 por 1.000 e-mails.

Cálculo: (50.000 / 1.000) * $0.10 = $5.00.

No entanto, a AWS lançou novos planos em níveis em 21 de julho de 2026. No plano Essentials, o custo é de $0.16 por 1.000. O plano Pro custa $0.22 por 1.000 mais uma taxa mensal de $105 por região. O plano Enterprise custa $0.23 por 1.000 mais $500 por mês. Para uma equipe de produto pequena, o modelo avulso é o mais barato, mas coloca todo o peso da configuração sobre o engenheiro.

A abordagem de plataforma: Postmark e Mailgun

Provedores como o Postmark e o Mailgun focam na experiência do desenvolvedor. Segundo os preços do Postmark, o plano básico custa $15 por mês para 10.000 e-mails. O excedente custa de $1.80 a $1.20 por 1.000 e-mails.

Cálculo (Postmark): $15 (primeiros 10 mil) + (40.000 / 1.000 * $1.20) = $15 + $48 = $63. (Dependendo do plano específico, pode chegar a $66.)

Da mesma forma, os preços do Mailgun começam em $15 por mês para 10.000 e-mails, com excedente entre $1.80 e $1.10 por 1.000. Esses provedores oferecem templates hospedados e análises mais intuitivas, o que justifica o preço maior para equipes que não querem construir os próprios painéis de monitoramento.

O meio-termo moderno: Resend

O Resend mira o stack de produto moderno. A página de preços mostra um plano gratuito de 3.000 e-mails por mês (limitado a 100 por dia). O plano Pro custa $20 por mês para 50.000 e-mails, com excedente de $0.90 por 1.000.

Cálculo (Resend): $20 fixos pelos primeiros 50.000.

Aceitação, entrega e chegada à caixa de entrada: a distinção crucial

Um erro comum que vejo em documentação de engenharia é usar esses três termos como sinônimos. Eles não são a mesma coisa, e nenhuma API consegue garantir a última etapa.

Aceitação: é a resposta da API. Quando você faz um POST de um payload para um endpoint, o provedor retorna 202 Accepted ou 200 OK. Isso significa apenas que o provedor recebeu a requisição e que ela passou por uma validação básica. Não significa que o e-mail saiu de casa.
Entrega: é o handshake SMTP. O provedor tenta entregar a mensagem ao servidor receptor do destinatário. Um evento "delivered" significa que o servidor receptor disse "vou aceitar esta mensagem".
Chegada à caixa de entrada: é o destino final. O servidor receptor (Gmail, Outlook etc.) decide se o e-mail vai para a caixa de entrada, para a aba Promoções ou para a pasta de spam. Isso é determinado pelos filtros internos do destinatário, pela reputação do remetente e pelos seus registros de autenticação.

Para aumentar suas chances de entrega, você precisa configurar o DNS corretamente. Recomendo usar um verificador de DNS para garantir que seus registros estão se propagando. Siga à risca um guia sobre DKIM, SPF e DMARC para provar que você é quem diz ser.

Engenharia para confiabilidade

Enviar um e-mail é um efeito colateral externo. Em um sistema distribuído, efeitos colaterais são perigosos porque podem ser duplicados ou falhar silenciosamente.

O problema da idempotência

Se o seu servidor de aplicação atingir o timeout enquanto espera a resposta da API de e-mail, você não sabe se o e-mail foi enviado. Se simplesmente tentar de novo, o usuário recebe dois e-mails. É por isso que uma chave de idempotência é essencial.

Uma chave de idempotência é um identificador único (geralmente um UUID) enviado no cabeçalho. Se a API vir a mesma chave duas vezes, ela retorna a resposta em cache da primeira requisição bem-sucedida em vez de enviar um segundo e-mail.

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

Envio conduzido por agentes

Com a ascensão dos agentes de IA e dos servidores MCP, vemos cada vez mais comunicação "agente para agente" (A2A). Agentes nunca devem ter acesso irrestrito a uma API de envio. Se um LLM entrar em loop, ele pode consumir sua cota de 50.000 e-mails em minutos e destruir a reputação do remetente.

Implemente um fluxo de aprovação para agentes:

Etapa de rascunho: o agente gera o e-mail e o armazena em uma tabela pending_emails.
Humano no circuito: um usuário ou um agente supervisor revisa o conteúdo.
Execução: o sistema chama a API somente depois que a flag status = 'approved' é definida.

Checklist técnico para a migração

Se você está trocando um provedor caro por um mais barato (ou o contrário), não basta trocar a chave de API. Use este checklist:

Auditoria de DNS: verifique seus registros SPF. Garanta que você não está ultrapassando o limite de 10 consultas.
Mapeamento de webhooks: cada provedor usa nomes de evento diferentes. Mapeie delivered do provedor A para sent no provedor B.
Sincronização de supressões: exporte suas listas de bounces e reclamações. Se você importar 50.000 usuários em um novo provedor e enviar para bounces conhecidos, sua conta será suspensa imediatamente.
Tratamento de limite de taxa: implemente backoff exponencial para erros 429 Too Many Requests.

Exemplo de lógica de tratamento de erros

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

Como escolher a ferramenta certa

Se você é um desenvolvedor solo construindo um protótipo, os planos gratuitos do Resend ou os preços avulsos do SES são suficientes. Se você faz parte de uma equipe de produto que gerencia um fluxo transacional complexo e crítico (como redefinições de senha ou alertas de cobrança), a segurança operacional de um provedor de plataforma muitas vezes vale a diferença de $60.

Quem constrói aplicações nativas de IA precisa de mais do que um simples canal. É preciso estar pronto para agentes, com um servidor MCP e um arquivo llms.txt estruturado que ajude seus agentes a entender como interagir com sua camada de comunicação. É aí que uma API especializada vira um multiplicador de força em vez de apenas um centro de custo.

No fim das contas, o custo da API é a menor parte da equação. O custo real é o tempo de engenharia gasto depurando um registro DNS mal configurado ou limpando uma crise de reputação causada pela falta de gestão de supressões. Seja qual for o caminho escolhido, o de $5 ou o de $66, priorize a telemetria e as ferramentas que mantêm seus e-mails fluindo.

Conheça mais infraestrutura de e-mail pensada para desenvolvedores em https://sendhq.cc.