Email transacional para SaaS: como escolher um serviço

O que é uma mensagem transacional

Email transacional é a resposta do produto a algo que acabou de acontecer: alguém pediu uma redefinição de senha, um pagamento falhou, um colega convidou outra pessoa para a conta. A mensagem vai para uma pessoa, com dados daquele evento, e existe porque a ação precisa de confirmação. Em produto SaaS, os exemplos mais comuns são redefinição de senha, código de verificação, confirmação de cadastro, recibo de pagamento, convite para uma equipe, alerta de segurança, aviso de cobrança e atualização de status de pedido ou envio.

O que define a categoria não é o assunto, mas o contrato com quem recebe: uma redefinição de senha vencida em dez minutos não adianta mais, e um recibo que chega depois do pagamento gera dúvida e ticket de suporte. Por isso o que importa é o tempo entre o evento e a entrega, e não a taxa de abertura. Uma mensagem de produto que carrega cupom ou promoção sai do contrato original e passa a disputar o tratamento dado ao marketing.

Separar o transacional do marketing

Campanha e produto convivem bem quando ocupam caminhos distintos. A diferença prática aparece no que acontece quando algo dá errado: uma newsletter que acumula descadastros e reclamações derruba a reputação do remetente, e a mesma reputação sustenta a redefinição de senha de segunda-feira de manhã. Manter as duas categorias no mesmo fluxo de envio acopla o pior resultado de uma à outra.

Os provedores resolvem isso de duas formas. Streams de mensagem separam contas internas de envio, com limites, painéis e listas de supressão por caminho; subdomínios distintos, como produto.suaempresa.com e news.suaempresa.com, separam a reputação no nível do domínio. Antes de configurar, descubra como o plano trata a supressão — se um endereço bloqueado no caminho de marketing também some do transacional. No Brasil, a LGPD pede base legal para cada mensagem: avisos ligados à execução do contrato se apoiam em bases diferentes das comunicações promocionais, que dependem de consentimento e descadastro.

Filas, retentativas e idempotência

Entre o clique do usuário e a caixa de entrada existem dois saltos — da aplicação ao provedor e do provedor ao receptor —, e cada um falha de vez em quando. A estrutura básica é uma fila: o evento vira um trabalho pendente, é enviado, e o resultado volta por webhook; se a resposta não chega, alguém tenta de novo.

As retentativas precisam de regras para não transformar falha em spam. Erro de validação — endereço malformado, domínio inexistente — não deve ser repetido; erro temporário deve, com espera crescente e um limite máximo. Quando a tentativa se esgota, o trabalho vai para uma fila morta com alerta. Respeite também os cabeçalhos de limite de taxa. Idempotência fecha o circuito: gere uma chave estável por mensagem lógica — identificador do evento mais o tipo da mensagem — e envie a mesma chave em todas as tentativas, para que o provedor reconheça a repetição e devolva o resultado original em vez de um segundo email.

Templates e localização

Mensagem transacional é interface: o link precisa levar ao estado certo do produto e o texto precisa dizer o que acontece depois do clique. Muitos times guardam o HTML dessas mensagens no repositório, com revisão em pull request; outros preferem o editor do provedor, que dá autonomia a quem escreve texto sem passar por deploy. As duas abordagens convivem desde que a cópia exportável dos templates e a lista dos campos que cada um consome fiquem documentadas.

Localização é a segunda metade do trabalho: um produto com contas em mais de um país envia recibo, convite e aviso de cobrança no idioma preferido da pessoa, que deve vir do cadastro e não do cabeçalho do navegador. Separe o template do conteúdo por locale, defina um idioma de reserva e confira datas, moedas e fusos.

Monitoramento de bounces e reclamações

Webhooks completam o circuito do envio: sem eles, a aplicação só sabe que a chamada foi aceita; com eles, sabe quando a mensagem foi entregue, rejeitada ou reclamada. Assine pelo menos os eventos de entrega, bounce e reclamação de spam, valide a assinatura que o provedor envia e processe o payload em fila, porque eventos chegam de novo quando o endpoint falha.

Rejeição dura e rejeição temporária pedem reações diferentes: endereço inexistente ou caixa recusada vira supressão imediata, enquanto recusa temporária volta para a fila com espera crescente. Reclamação de spam é o sinal mais grave para a reputação do remetente — encerre todo envio para aquele endereço e verifique em qual formulário ele consentiu. Alguns provedores aplicam a supressão na conta inteira, outros por stream de mensagem; esse detalhe decide se uma reclamação de campanha derruba também as mensagens de produto. Guarde o histórico que o suporte vai precisar: quando alguém afirma não ter recebido o aviso de cobrança, a primeira pergunta é o que o evento registrou.

Entregabilidade: SPF, DKIM e DMARC

Três registros de DNS decidem se o email chega à caixa principal. SPF declara quais servidores podem enviar pelo seu domínio; cada provedor que você usar precisa entrar nessa lista, e o formato do registro limita o número de entradas. DKIM assina cada mensagem com uma chave cuja parte pública fica no DNS, permitindo ao receptor confirmar 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 coincidem.

Comece o DMARC com política de relatório e leia o feedback por algumas semanas: as mensagens revelam envios legítimos que ainda não passam no alinhamento, como notificações de um sistema antigo que ninguém lembra de existir. Depois endureça para quarentena e, com os relatórios limpos, para rejeição. Use um subdomínio por categoria de fluxo. Ao trocar de provedor, atualize SPF e DKIM antes de mover o volume.

Quem é dono do quê: produto e engenharia

Email transacional raramente pertence a uma única função. A engenharia monta a chamada, escolhe o provedor, configura a fila, os webhooks e a autenticação do domínio; o time de produto escreve o texto, define o dado que cada mensagem precisa carregar e decide o que acontece depois do clique.

Um arranjo comum é nomear uma pessoa responsável por cada fluxo e manter um inventário simples: evento que dispara a mensagem, template correspondente, idiomas disponíveis, volume mensal e responsável pela revisão. Mudanças em mensagens de cobrança e segurança passam por revisão dupla. Com o inventário em mãos, trocar de provedor vira um projeto com escopo. Também separe permissões: quem cuida de campanha não precisa da chave de API que dispara redefinição de senha.

Os serviços em uma tabela

Custo em 10.000, 50.000 e 100.000 e-mails

Em 10.000 e-mails por mês, os planos de entrada cobrem o volume sem excedente. Postmark cobra US$ 15 no Basic, US$ 16,50 no Pro e US$ 18 no Platform — 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 Amazon SES, 10 vezes 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; o Free do Resend também fica abaixo.

Em 50.000 e-mails, o Resend cobra US$ 20 pelo Pro e o Mailgun 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. Para a SES, 50 vezes US$ 0,16 dão US$ 8,00 — e, nesse serviço, fila, retentativa e tratamento de rejeição continuam do lado da sua equipe.

Em 100.000 e-mails por mês, o Pro do Resend custa US$ 35 e o Essentials do SendGrid US$ 34,95. No Postmark, o próximo nível disponível é 125.000 e-mails: Basic custa US$ 115, Pro US$ 126,50 e Platform US$ 138 por mês. Para a SES, cem vezes US$ 0,16 resultam em US$ 16,00. Antes de fechar o orçamento, some excedentes, impostos e eventuais adicionais de IP dedicado.

Resend

O Resend atende quem quer enviar por API com pouco atrito de integração. O plano gratuito cobre 3.000 e-mails por mês, com teto de 100 por dia e até três domínios — suficiente para validar a integração em um ambiente real de produto. O Pro custa US$ 20 por mês com 50.000 e-mails incluídos, e chega a US$ 35 por mês quando o volume sobe para 100.000; o Scale é US$ 160 por mês para 200.000 e-mails. Nos planos pagos, o que passar do volume incluído é cobrado a US$ 0,90 por 1.000 e-mails. IP dedicado é adicional de US$ 30 por mês no Scale, para contas acima de 3.000 e-mails por dia, e SSO é adicional de US$ 150 por mês.

Postmark

O Postmark concentra-se em email transacional e organiza os envios em streams de mensagem, o que permite separar categorias — login, cobrança, notificações de produto — dentro da mesma conta, cada uma com seu próprio painel e limites. O plano gratuito entrega 100 e-mails por mês sem excedente, pensado em validar a integração antes da cobrança. 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.

O que muda entre os três é o preço do excedente e recursos de operação: e-mails acima do volume incluído custam US$ 1,80 por 1.000 no Basic, US$ 1,30 no Pro e US$ 1,20 no Platform, e a retenção de dados do Basic é de 45 dias. IP dedicado gerenciado começa em US$ 50 por mês, para contas a partir de 300.000 e-mails por mês em Pro ou superiores; monitoramento de DMARC é adicional a partir de US$ 14 por mês por domínio.

Mailgun

O Mailgun combina API e relay SMTP no mesmo serviço, com rotas de entrada, validação de endereços e escolha de região de envio entre Estados Unidos e União Europeia — um ponto que pesa quando a operação precisa manter dados em uma região específica.

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 por mês, 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.

SendGrid

O SendGrid atende email transacional e campanhas de marketing na mesma plataforma, com planos separados para cada uso. Na parte de email API, o acesso gratuito permite 100 e-mails por dia durante 60 dias, sem cartão de crédito. 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 por mês, o valor é US$ 34,95.

Para quem também envia campanhas, existe um plano gratuito de marketing com até 2.000 contatos e 6.000 e-mails por mês. A separação entre os usos deve refletir-se também nos domínios de envio, para que a reputação de campanha não acompanhe a de mensagens de login e cobrança.

Amazon SES

O Amazon SES trata email como um serviço de uso dentro da AWS: não há plano mensal fixo na faixa essencial, e a cobrança acompanha o volume enviado. O Essentials custa US$ 0,16 por 1.000 e-mails para envios de 0 a 10 milhões por mês, e contas novas começam nele. 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. IP dedicado padrão pode ser adicionado por US$ 24,95 por mês.

A integração usa a AWS SDK, com eventos entregues por tópicos do SNS. Em contrapartida do custo por e-mail baixo, boa parte da operação — fila de envio, retentativa, tratamento de bounce e métricas de entrega — fica com a sua equipe.

Quando uma plataforma só para os dois fluxos é aceitável

Há momentos em que manter transacional e marketing na mesma plataforma é uma escolha razoável, desde que a ferramenta permita separar os caminhos. O arranjo faz sentido quando o volume de campanha é pequeno, o time é enxuto e o provedor oferece streams, subdomínios ou remetentes distintos por categoria — assim, uma reclamação de newsletter não atinge a fila de redefinição de senha.

Uma dessas plataformas é a Sequenzy, que cobra por e-mails enviados com contatos ilimitados: o plano gratuito vai até 2.500 e-mails por mês e o de entrada custa US$ 19 por mês para 15.000 e-mails. A escolha deve considerar o momento em que as duas categorias amadurecem: quando campanhas passam a ter calendário próprio e mensagens de login e cobrança passam a ser críticas para o suporte, a separação deixa de ser convenção e vira requisito operacional. A migração, quando chegar, é por fluxo e com os dois provedores ativos em paralelo por alguns dias.

Como escolher: cinco passos

Comece inventariando as mensagens que o produto envia hoje: evento que dispara, idioma, volume mensal aproximado e o que acontece se a mensagem não chegar. Esse inventário é a base de qualquer comparação e revela quantos fluxos realmente existem — muitas contas têm um punhado de mensagens esquecidas em scripts antigos.

Em seguida, defina os requisitos de operação: separação entre categorias, regiões de dados, retenção de log para atendimento, idiomas de template e quem ficará responsável pelo domínio. Só depois compare preços com o seu volume real, e não com o volume de exemplo da tabela. Faça uma integração gradual em ambiente separado: envie a mensagem mais simples — confirmação de cadastro — e acompanhe identificador, links e eventos ponta a ponta antes de mover o fluxo principal. Por fim, registre a data da contratação e o plano exato: preços e limites mudam, e a decisão boa é a que deixa rastro escrito.

Perguntas frequentes