Como escolher um serviço de email API-first

API contra SMTP: dois caminhos para o mesmo destino

SMTP é o protocolo com o qual a internet troca email desde antes de existirem painéis de controle. Sua aplicação abre uma conexão, autentica, declara remetente e destinatários e transmite o corpo da mensagem. Qualquer linguagem com biblioteca de SMTP fala com todos os provedores desta página, mas o resultado costuma vir como código textual, o limite de taxa depende do servidor e não existe um identificador único da mensagem para correlacionar com o que o cliente relatou.

Uma API HTTP inverte essa conta: a requisição devolve um identificador de mensagem em JSON, aceita cabeçalhos de idempotência e grava cada chamada em um painel com o estado do envio, e o erro chega estruturado. Em times que já operam fila e observabilidade em HTTP, a API costuma ser o padrão e o SMTP vira recurso de transição para aplicações herdadas; os dois caminhos costumam coexistir no mesmo serviço.

SDKs e webhooks: a camada que o time não quer reimplementar

Um SDK oficial resolve autenticação com a chave, montagem da requisição, anexos e interpretação de erro, para que cada serviço não reimplemente a mesma ponte. Antes de adotar um, pergunte quais linguagens da stack têm biblioteca mantida pelo próprio provedor, se existem tipos para TypeScript e com que frequência as versões são publicadas. Sem SDK, consumir a REST com um cliente HTTP próprio funciona, com o custo de carregar sozinho a manutenção dos detalhes.

Webhooks completam o circuito: em vez de a aplicação perguntar o estado de cada mensagem, o provedor avisa quando ela foi entregue, rejeitada, reclamada, aberta ou clicada. Em produção, todo endpoint deve validar a assinatura enviada pelo provedor, responder com status 200 em poucos milissegundos e enfileirar o payload para processamento assíncrono. Como provedores reenviam eventos quando o endpoint falha, o manipulador precisa reconhecer um identificador já tratado; assim, atualizar o estado do cliente não depende de varreduras periódicas.

Templates em código versus templates na plataforma

Guardar o HTML do email no repositório traz revisão em pull request, histórico de mudança e o mesmo artefato em desenvolvimento e produção. O fluxo típico é compilar o template durante o build e enviar o resultado pela API, com as variáveis preenchidas a partir dos dados do evento. Isso combina com mensagens transacionais, onde a correção do link de redefinição de senha importa mais que a liberdade visual de quem não programa.

O editor gerenciado do provedor inverte a dependência: pessoas de conteúdo alteram texto e imagens sem passar por deploy. A contrapartida é que a revisão sai do seu fluxo de código. Uma divisão comum é manter no código as mensagens acionadas pelo produto e usar o editor para campanhas avulsas; em qualquer modelo, guarde uma cópia exportável dos templates e a documentação dos campos que cada um consome, porque essa cópia encurta uma migração futura.

Idempotência e retentativas: como falhar sem duplicar

Rede falha, e quando a resposta da API se perde entre o seu servidor e o provedor a única saída segura é tentar de novo. Sem proteção, a segunda tentativa vira um segundo email na caixa de entrada. A defesa é uma chave de idempotência estável por mensagem lógica: identificador do pedido mais o tipo da mensagem, por exemplo. O provedor reconhece a chave repetida e devolve o resultado original em vez de reenviar; confirme na documentação de cada serviço quais operações aceitam a chave e por quanto tempo ela vale.

Ao redor da chave, organize três comportamentos. Classifique o erro: falha de validação não deve ser repetida, enquanto erro temporário ou tempo esgotado deve. Use backoff exponencial com limite de tentativas e envie o que desistiu para uma fila morta que alguém possa inspecionar. Observe também os cabeçalhos de limite de taxa, que indicam quanto resta e quando a cota se renova; respeitar esse intervalo evita que a fila inteira receba recusas no pico do dia.

Fluxos de mensagem: separar transacional e marketing

Email transacional responde a uma ação necessária: confirmação de conta, código de acesso, recibo, alteração de assinatura. Email de marketing fala com uma audiência que consentiu em receber conteúdo, convite ou oferta. As duas categorias podem dividir a mesma conta, mas não devem compartilhar o mesmo caminho de reputação, porque um pico de campanha que acione reclamações não deveria atrasar a entrega de uma redefinição de senha.

Os provedores desta página resolvem isso com streams de mensagem ou com subdomínios distintos por categoria. Antes de configurar, descubra como cada plano trata a lista de supressão: em alguns serviços ela vale para a conta inteira, em outros separa por stream. Defina também quem pode disparar em cada caminho e qual fluxo de log alimenta o painel de suporte; essa decisão, tomada no início, evita refazer autenticação de domínio quando o volume crescer.

Logs e retenção: quanto histórico você precisa

Quando um cliente afirma que não recebeu o email de cobrança, a primeira pergunta é o que o log do provedor registrou naquele dia. Planos diferentes oferecem janelas de retenção diferentes: alguns guardam o histórico de eventos por alguns dias, outros por semanas ou meses, e a diferença costuma vir justamente do nível de plano de cada conta. Levante com o suporte por quanto tempo você precisa consultar entregas, bounces e reclamações para atender tickets e auditorias.

Para prazos mais longos, encaminhe os eventos para o seu próprio armazenamento: um bucket de objetos, um tópico de mensagens ou o data warehouse da empresa. Com o histórico do seu lado, painéis de suporte e cálculos de taxa de reclamação deixam de depender da janela do provedor. Some a isso o custo de retenção estendida dos planos que a oferecem.

Entregabilidade: SPF, DKIM e DMARC

Três registros de DNS decidem se o seu email chega à caixa de entrada principal. SPF publica a lista de servidores autorizados a enviar em nome do domínio; cada provedor que você usar precisa entrar nessa lista, e a política do DNS limita quantas entradas cabem. DKIM assina cada mensagem com uma chave cuja parte pública fica no DNS, permitindo ao receptor verificar que o domínio autorizou aquele envio. DMARC alinha o domínio visível no cabeçalho From com o domínio assinado e diz ao receptor o que fazer quando os dois não batem.

Publique o DMARC primeiro com política de relatório e leia as mensagens de feedback por algumas semanas: elas revelam envios legítimos que ainda não passam no alinhamento, como notificações de sistemas antigos. Depois, endureça para quarentena e, quando os relatórios estiverem limpos, para rejeição. Use um subdomínio dedicado a cada categoria de fluxo e planeje a troca de provedor com dias de antecedência para atualizar SPF e DKIM sem interromper o envio.

Os serviços em uma tabela

A tabela reúne os planos e volumes publicados por cada provedor, com a base da cobrança por extenso. A escolha final depende da stack, dos streams de mensagem e da retenção de log de que a operação precisa.

Custo em 10.000, 50.000 e 100.000 e-mails

Em 10.000 e-mails por mês, os planos de entrada já cabem na conta. Postmark cobra US$ 15 pelo Basic, US$ 16,50 pelo Pro e US$ 18 pelo Platform, todos com esse volume como base; no ano, US$ 15 vezes 12 dão US$ 180 no Basic. Mailgun oferece o Basic por US$ 15 para 10.000 e-mails, com excedentes a partir de US$ 1,80 por 1.000. Na base de uso da Amazon SES, 10 vezes o preço de US$ 0,16 por 1.000 resultam em US$ 1,60 no mês. O Essentials do SendGrid começa na faixa de 50.000 e-mails, então para esse volume o plano de entrada não se aplica.

Em 50.000 e-mails, Resend cobra US$ 20 pelo Pro e Mailgun cobra US$ 35 pelo Foundation por mês após o primeiro mês; o Essentials do SendGrid vale US$ 19,95 nessa faixa. No Postmark, o mesmo volume custa US$ 55 no Basic, US$ 60,50 no Pro e US$ 66 no Platform por mês. Para a Amazon SES, 50 vezes US$ 0,16 dão US$ 8,00, lembrando que o tratamento de erro e a observabilidade ficam do seu lado nesse serviço.

Em 100.000 e-mails por mês, o Pro do Resend custa US$ 35 e o Essentials do SendGrid custa US$ 34,95. O Mailgun oferece o Scale a US$ 90 por mês após o primeiro mês para esse volume, com 30 dias de retenção de log. No Postmark, os volumes publicados saltam de 50.000 para 125.000 e-mails, e o Basic com 125.000 custa US$ 115 por mês. Para a SES, cem vezes US$ 0,16 resultam em US$ 16,00. Antes de fechar o orçamento, confira excedentes, impostos e eventuais adicionais de IP dedicado.

Resend

O Resend se apoia em um plano gratuito de 3.000 e-mails por mês, com limite de 100 e-mails por dia e até três domínios, suficiente para integrar a API em um ambiente de teste real. O Pro custa US$ 20 por mês para 50.000 e-mails; quando o volume chega a 100.000, o mesmo plano Pro é US$ 35 por mês. O Scale é US$ 160 por mês para 200.000 e-mails. Nos planos Pro e Scale, e-mails acima do volume incluído custam US$ 0,90 por 1.000.

Postmark

O Postmark publica um plano gratuito de 100 e-mails por mês, sem excedentes, pensado em validar a integração. Os planos pagos partem de 10.000 e-mails por mês: Basic a US$ 15, Pro a US$ 16,50 e Platform a US$ 18. A diferença entre os três está no excedente, que custa US$ 1,80 por 1.000 no Basic, US$ 1,30 no Pro e US$ 1,20 no Platform, e em recursos de operação para times maiores. Com 50.000 e-mails, os preços mensais são US$ 55 no Basic, US$ 60,50 no Pro e US$ 66 no Platform; com 125.000, o Basic custa US$ 115. O serviço se concentra em email transacional e organiza os envios em streams de mensagem, o que facilita separar categorias dentro da mesma conta.

Mailgun

O Mailgun combina API e relay SMTP, com rotas de entrada, validação de endereços, IPs dedicados e regiões de hospedagem nos Estados Unidos e na União Europeia. O plano gratuito entrega 100 e-mails por dia em um domínio, com um dia de retenção de log. O Basic custa US$ 15 por mês para 10.000 e-mails, com excedentes a partir de US$ 1,80 por 1.000. O Foundation, para 50.000 e-mails, custa US$ 35 por mês após o primeiro mês, guarda cinco dias de log e cobra excedentes a partir de US$ 1,30 por 1.000. O Scale, para 100.000 e-mails, é US$ 90 por mês após o primeiro mês, amplia a retenção para 30 dias e inclui 5.000 validações de endereço.

SendGrid

O SendGrid atende email transacional e campanhas de marketing na mesma plataforma, com planos separados para cada uso. O teste gratuito permite 100 e-mails por dia durante 60 dias. O Essentials começa em US$ 19,95 por mês na faixa de 50.000 a 100.000 e-mails; no topo dessa faixa, com 100.000 e-mails, o valor é US$ 34,95 por mês. O Pro parte de US$ 89,95 por mês na faixa de 100.000 a 2.500.000 e-mails e inclui IP dedicado. Para a parte de marketing, existe um plano gratuito com até 2.000 contatos e 6.000 e-mails por mês.

Amazon SES

O Amazon SES trata email como um serviço de uso dentro da AWS: a cobrança é por volume enviado, sem plano mensal fixo na faixa essencial. O plano Essentials custa US$ 0,16 por 1.000 e-mails na faixa de 0 a 10 milhões de e-mails por mês, e contas novas começam nele, a menos que escolham outro plano. O Pro cobra US$ 0,22 por 1.000 e-mails mais US$ 105 por conta, por região, ao mês; o Enterprise cobra US$ 0,23 por 1.000 mais US$ 500 fixos. A integração usa a AWS SDK, com eventos entregues por tópicos do SNS, e IP dedicado padrão pode ser adicionado por US$ 24,95 por mês. Em troca do custo por e-mail baixo, filas, retentativa e tratamento de bounce ficam do seu lado.

Quando adicionar uma ferramenta de marketing

Uma ferramenta de marketing faz sentido quando pessoas fora do time de desenvolvimento precisam montar campanhas, editar conteúdo e acompanhar audiência sem depender de deploy. Os sintomas são claros: pedidos recorrentes para alterar texto de newsletter, segmentos que o produto não calcula e calendário de conteúdo gerenciado em planilhas. Antes de contratar, verifique como a ferramenta recebe eventos do seu produto, se ela respeita a lista de descadastros do provedor transacional e qual o custo por contatos armazenados além do custo por envios.

Na prática, as equipes mantêm o transacional no provedor de API e ligam a ferramenta de marketing por eventos ou integração nativa, para que início de teste, pagamento aprovado e cancelamento atualizem a audiência automaticamente. Mantenha também os papéis separados: quem cuida de campanha não precisa da chave de API que dispara redefinição de senha. Com essa divisão, trocar uma das ferramentas deixa de ser um projeto de meses.

Migração de provedor

Migre por fluxo, não por conta inteira. Comece listando cada mensagem que sua aplicação envia, o evento que a dispara, o template correspondente e o volume mensal. Exporte do provedor atual as listas de supressão, os bounces duros e as reclamações, e importe-as no novo serviço antes do primeiro envio: essa lista é o que impede que a reputação do domínio caia logo na estreia. Recrie os registros de SPF, DKIM e DMARC apontando para o novo provedor e mantenha os antigos ativos durante a transição.

Depois, mova um fluxo transacional pequeno, como a confirmação de cadastro, e acompanhe identificador de mensagem, links e eventos de webhook ponta a ponta. Feito isso, mova os fluxos restantes em lotes e mantenha os dois provedores ativos por alguns dias, para que mensagens já em fila terminem no caminho antigo. Ao encerrar, revogue as chaves antigas, atualize a documentação interna com o novo modelo de logs e registre a data da troca.

Perguntas frequentes