Email transacional vs marketing: por que separar os envios

Separar email transacional e de marketing significa enviar cada tipo por um stream próprio, com IPs (ou pools de IP) e subdomínios diferentes, para que a reputação de um não afete a do outro. O motivo é simples: campanhas de marketing naturalmente geram mais reclamações, bounces e desinteresse, e se compartilharem infraestrutura com o transacional, uma promoção mal segmentada pode atrasar ou mandar para o spam a redefinição de senha dos seus usuários. A separação também deixa claro quais mensagens precisam de descadastro e como medir cada uma.

O que é cada tipo

Transacional é a mensagem que o usuário espera porque fez algo ou porque precisa saber de algo:

• Confirmação de cadastro e verificação de email.
• Código de login, redefinição de senha, alerta de segurança.
• Confirmação de pedido, boleto, Pix gerado, nota fiscal, rastreio.
• Notificação de atividade na conta (novo comentário, mensagem recebida).

Marketing é a mensagem que a empresa decide enviar para promover algo:

• Newsletter, lançamento, promoção da Black Friday.
• Carrinho abandonado com cupom, recomendação de produtos.
• Pesquisa de satisfação genérica, convite para evento.

Existe uma zona cinzenta (resumos semanais, avisos de produto). A pergunta útil é: se o usuário se descadastrar, ele perde algo de que precisa para usar o serviço? Se sim, é transacional. Se não, trate como marketing.

Por que misturar é perigoso

Provedores de email constroem reputação em várias camadas: IP de envio, domínio do From, domínio de DKIM, domínio do Return-Path e até padrões de conteúdo. Quando tudo é compartilhado:

1. Reclamações do marketing contaminam o transacional. O Google recomenda manter a taxa de spam abaixo de 0,1% e nunca chegar a 0,3%. Uma campanha para base antiga pode ultrapassar isso em um dia.
2. Limitações atingem tudo. Se o Outlook começa a responder 421 4.7.x para o IP por causa do volume de uma campanha, o código de verificação do usuário que está tentando entrar fica na fila junto.
3. Diagnóstico fica impossível. Com métricas misturadas, você não sabe se a queda de entrega veio da newsletter ou de um bug que disparou emails duplicados.
4. Picos de volume confundem o warm-up. O transacional tem volume estável; o marketing tem picos. Juntos, o padrão fica irregular.

Como separar: as camadas

1. Streams lógicos

Comece na aplicação: cada mensagem deve sair marcada com o stream (transacional ou marketing, às vezes mais categorias). Isso define as regras que valem para ela:

2. IPs ou pools de IP separados

Cada stream sai por um pool de IPs próprio. Para volumes menores, o transacional pode usar um pool compartilhado de alta reputação e o marketing outro; em volumes maiores, IPs dedicados por stream. O ponto é que um problema no pool de marketing não toca o pool transacional.

3. Subdomínios separados

Use subdomínios diferentes para o From, o DKIM e o Return-Path de cada stream:

Transacional
  From:         nao-responda@conta.example.com.br
  DKIM d=       conta.example.com.br
  Return-Path:  b+...@bounces.conta.example.com.br

Marketing
  From:         ofertas@news.example.com.br
  DKIM d=       news.example.com.br
  Return-Path:  b+...@bounces.news.example.com.br

Os subdomínios continuam alinhados com o DMARC do domínio principal no modo relaxado, porque compartilham o domínio organizacional example.com.br. Você pode publicar DMARC específico em cada subdomínio, se quiser políticas diferentes:

_dmarc.example.com.br.        TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com.br"
_dmarc.news.example.com.br.   TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.br"

Vale saber que provedores também consideram a reputação do domínio organizacional. Subdomínios separam bem, mas não isolam totalmente: uma conduta muito ruim no marketing ainda respinga no domínio principal.

4. Métricas e alertas por stream

Bounce, reclamação, entrega e latência devem ser medidos por stream. Um alerta de "reclamação acima de 0,1% no marketing" deve pausar o marketing, não o transacional.

Exemplo prático: uma loja virtual

Imagine uma loja que envia, num dia comum, confirmações de pedido, códigos Pix, notas fiscais e avisos de rastreio, e que às sextas dispara uma newsletter para toda a base. Na semana da Black Friday, o volume de marketing se multiplica e inclui segmentos que não compram há muito tempo.

Com tudo no mesmo IP e no mesmo domínio, o cenário provável é este: a campanha para a base antiga gera bounces e reclamações, o Gmail começa a limitar o IP com respostas 421 4.7.28, e os emails com o código Pix ficam presos na fila exatamente quando o cliente está tentando pagar. O prejuízo deixa de ser "a newsletter teve menos aberturas" e vira venda perdida.

Com streams separados, a mesma campanha ruim afeta apenas o pool de marketing e o subdomínio news.example.com.br. O alerta de reclamação pausa o marketing, o time revisa a segmentação, e as confirmações de pedido seguem saindo pelo pool transacional sem atraso. A separação não evita o erro, mas limita o estrago a quem o causou.

Erros comuns

• Enfiar marketing no email transacional. Um banner promocional grande em toda confirmação de pedido transforma o transacional em marketing aos olhos do usuário e do filtro. Um rodapé discreto é diferente de uma vitrine.
• Usar o mesmo From para tudo. O usuário marca a newsletter como spam e, sem querer, treina o filtro dele contra o remetente do recibo também.
• Descadastro global. Quem sai da newsletter continua precisando receber a nota fiscal e o código de login.
• Classificar carrinho abandonado como transacional para fugir do descadastro.
• Subdomínio novo sem warm-up. Um subdomínio sem histórico também precisa de volume crescente no começo.
• Separar IP mas manter o Return-Path e o DKIM do domínio raiz para tudo. Metade da separação some.

Checklist de separação

• [ ] Cada mensagem marcada com stream na aplicação.
• [ ] Pools de IP separados por stream.
• [ ] Subdomínios distintos para From, DKIM e Return-Path.
• [ ] DMARC do domínio principal cobrindo os subdomínios (ou DMARC próprio por subdomínio).
• [ ] Descadastro de um clique em todo o marketing; supressão por categoria.
• [ ] Prioridade de fila maior para transacional.
• [ ] Métricas e alertas por stream, com pausa isolada.

Na Pidgely

Na Pidgely, stream é um conceito de primeira classe: cada envio declara o stream, cada stream tem seu pool de IP com warm-up automático e a reputação é acompanhada separadamente. Os headers de descadastro de um clique entram apenas no que é comercial, e a supressão por descadastro respeita o escopo do stream.