# E-mails transacionais: o que são e como enviá-los

URL canônica: https://brew.new/pt-br/blog/transactional-emails
Por Thomas Park
Publicado em 2026-08-22
Atualizado em 2026-09-28

Os e-mails transacionais trazem informações sobre uma transação ou um relacionamento: um recibo, uma redefinição de senha solicitada, uma atualização de entrega ou um aviso de segurança da conta. O objetivo deles é diferente do de uma campanha que pede para alguém comprar ou voltar.

A distinção depende da mensagem. Chamar um e-mail de “transacional” numa ferramenta de envio não define a situação jurídica dele.

## Aplique o critério do objetivo principal

O [guia da FTC sobre a lei CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) descreve categorias restritas de mensagens transacionais e de relacionamento. Para conteúdos que misturam o comercial e o transacional, ele considera o que um destinatário razoável entenderia pelo assunto e onde aparecem as informações transacionais.

Um assunto promocional pode tornar comercial uma mensagem mista. Um breve rodapé promocional não faz isso automaticamente: a FTC dá o exemplo de um extrato de conta que continua sendo principalmente transacional. O que conta é a [regra](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3) e a mensagem em si.

Mantenha as informações essenciais em destaque. Se uma promoção desvia a atenção de um recibo ou de um aviso de segurança, um e-mail de marketing separado costuma ser a escolha editorial mais clara. Estas são orientações dos EUA; verifique os requisitos aplicáveis aos seus destinatários e ao seu negócio. Fontes consultadas em 28 de setembro de 2026.

## Alguns casos comuns

| Mensagem | Objetivo habitual | O que revisar |
| --- | --- | --- |
| Recibo do pedido ou aviso de reembolso | Transacional | Informações corretas do pedido e um destinatário adequado |
| Redefinição de senha solicitada | Segurança da conta | Uma solicitação genuína, um link válido e nenhuma oferta que distraia |
| Atualização de entrega | Transacional | Informações sobre o pedido existente |
| Lembrete de carrinho abandonado | Marketing | Permissão, estado atual do carrinho e comportamento do descadastro |
| Oferta de upgrade no fim do período de teste | Marketing | A oferta real e se o destinatário ainda é elegível |

Um aviso sobre o status da conta e uma oferta de upgrade podem tratar do mesmo período de teste e ter objetivos diferentes. Revise o que o e-mail pede que o leitor faça.

## As regras dos provedores continuam valendo

As [diretrizes do Gmail](https://support.google.com/mail/answer/81126) distinguem as mensagens de marketing e por inscrição, que precisam ter descadastro com um clique, das mensagens transacionais. A autenticação e a reputação continuam importando para os dois tipos.

O [Yahoo](https://senders.yahooinc.com/best-practices/) recomenda separar o marketing em massa do tráfego transacional por IP e, quando fizer sentido, por domínio. Siga a configuração do seu provedor, em vez de presumir que um subdomínio novo, sozinho, cria uma reputação independente.

No marketing, a [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) define o mecanismo do cabeçalho de descadastro com um clique. Um link no rodapé e um descadastro pelo cabeçalho têm papéis diferentes. Teste o comportamento na mensagem recebida.

## Envie um evento de transação pelo Brew

Para esse fluxo de trabalho, o Brew usa uma automação publicada e o gatilho dela. Configure um domínio de envio verificado com a finalidade de envio adequada, declare o payload do gatilho e crie uma etapa de envio de e-mail que use esse domínio. A configuração do domínio controla o comportamento de envio do Brew; ela não torna juridicamente transacional um conteúdo promocional.

Depois de testar e publicar a automação, o seu back-end dispara o gatilho. Este exemplo presume que o gatilho declara `order_id` e `ship_date`:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1234-shipped" \
  -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'
```

Use o identificador real do gatilho e uma chave de idempotência estável para o evento. O e-mail pode ler um campo declarado do payload com uma sintaxe como `{{ trigger.order_id }}`. Consulte a [documentação das tags de mesclagem](https://docs.brew.new/create-emails/merge-tags) e teste os valores ausentes.

Confira a execução e o e-mail recebido. Teste o comportamento das novas tentativas e confirme que os descadastros de marketing são tratados de acordo com a finalidade de envio. Outras proteções, como as supressões de entrega, continuam valendo; uma configuração transacional não é uma promessa de entrega para todos os endereços.

O [guia de automação](/pt-br/blog/email-marketing-automation-guide) explica a publicação e as verificações de estado. Se um assistente criar o modelo, vale a mesma [revisão de envio](/pt-br/blog/agent-email-deliverability).