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 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 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

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 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 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 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:

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 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 explica a publicação e as verificações de estado. Se um assistente criar o modelo, vale a mesma revisão de envio.