E-mail transacional que chega e se entende: assunto, remetente e texto sem imagem

O aviso de troca de senha saiu com o assunto "Novidades na sua conta! Confira agora". A pessoa achou que era propaganda e marcou como spam. Três semanas depois, alguém de fato invadiu a conta dela, e o e-mail de alerta caiu direto na pasta de spam. A resposta curta: e-mail transacional diz o fato no assunto, vem sempre do mesmo remetente, funciona sem carregar imagem e sai de um domínio autenticado. Ele não é marketing e não pode parecer marketing.

E-mail transacional é aquele disparado por uma ação da pessoa ou do sistema: confirmação de cadastro, redefinição de senha, pedido recebido, pagamento recusado. Ela espera por ele. Se não chega, ou chega e não se entende, o produto falhou num momento em que ela precisava dele.

Por que o e-mail de sistema cai no spam

Os provedores decidem a caixa de destino olhando duas coisas: quem enviou e como as pessoas reagem. A primeira é técnica: o domínio do remetente autoriza aquele servidor a enviar? A mensagem tem assinatura válida? A segunda é comportamental: as pessoas abrem, respondem, ou marcam como spam?

O e-mail transacional costuma ter ótima reação, porque é esperado. O problema começa quando ele se mistura com o marketing. Mesmo remetente, mesmo domínio, mesmo tom. As reclamações da newsletter contaminam a reputação que o aviso de senha usa. E o assunto com cara de campanha faz a própria pessoa marcar a mensagem errada.

Desde 2024, Google e Yahoo endureceram as exigências para quem envia para as suas caixas: autenticação do domínio para todos os remetentes, e regras adicionais (como DMARC e descadastro em um clique) para quem envia em grande volume. Na prática, domínio sem SPF e DKIM configurados já começa em desvantagem.

Como escrever o e-mail transacional

Use o aviso de senha alterada como exemplo trabalhado.

1. Assunto com o fato. "Sua senha do DevBras foi alterada." Nada de emoji, urgência artificial ou curiosidade. A pessoa precisa entender o que aconteceu sem abrir.
2. Remetente estável. Sempre o mesmo nome e o mesmo endereço, por exemplo DevBras <conta@exemplo.com.br>. Trocar de remetente a cada mês faz a pessoa e o provedor desconfiarem.
3. A informação essencial na primeira linha. O que aconteceu, quando e o que fazer se não foi ela. A prévia da caixa de entrada mostra esse começo, como detalha o guia sobre a primeira linha do e-mail na prévia.
4. Texto que funciona sem imagem. Muitos clientes bloqueiam imagens por padrão. Se o recado está num banner, ele some. Logo pode existir, mas nada essencial depende dele.
5. Versão em texto puro. Envie a mensagem com as duas partes, HTML e texto. Quem usa leitor de e-mail em modo texto, ou um relógio, recebe a versão legível.
6. Link com nome do destino. "Revisar os acessos da sua conta", com o endereço do seu próprio domínio, não de um encurtador.
7. Nunca peça senha nem dado sensível no e-mail. E não mande a senha nova no corpo.

O exemplo em Node com Nodemailer

import nodemailer from 'nodemailer';

const transporte = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: 587,
  secure: false,
  requireTLS: true,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
});

function escaparHtml(texto) {
  return String(texto)
    .replace(/&/g, '&')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;');
}

export async function avisarSenhaAlterada(usuario, quando) {
  const data = quando.toLocaleString('pt-BR', { timeZone: 'America/Sao_Paulo' });
  const linkAcessos = 'https://www.exemplo.com.br/conta/acessos';

  const texto = [
    'Olá, ' + usuario.nome + '.',
    '',
    'A senha da sua conta no DevBras foi alterada em ' + data + '.',
    'Se foi você, não precisa fazer nada.',
    'Se não foi, revise os acessos da sua conta agora: ' + linkAcessos,
  ].join('\n');

  const html =
    '<p>Olá, ' + escaparHtml(usuario.nome) + '.</p>' +
    '<p>A senha da sua conta no DevBras foi alterada em ' + escaparHtml(data) + '.</p>' +
    '<p>Se foi você, não precisa fazer nada. Se não foi, ' +
    '<a href="' + linkAcessos + '">revise os acessos da sua conta</a> agora.</p>';

  try {
    await transporte.sendMail({
      from: '"DevBras" <conta@exemplo.com.br>',
      to: usuario.email,
      subject: 'Sua senha do DevBras foi alterada',
      text: texto,
      html,
    });
  } catch (err) {
    console.error('falha ao enviar aviso de senha', { usuarioId: usuario.id, erro: err.message });
    throw err;
  }
}

Detalhes que importam: a porta 587 com requireTLS recusa enviar se o servidor não oferecer STARTTLS, então a senha do SMTP nunca trafega aberta. As credenciais vêm do ambiente, não do código. O nome do usuário é escapado no HTML, porque é dado digitado pela pessoa. E o log registra o id, não o e-mail nem a senha, como recomenda o guia de log sem senha e sem dado sensível.

Em produção, não chame o envio dentro da requisição de troca de senha esperando o SMTP responder. Grave o pedido de envio numa fila ou tabela e deixe um worker enviar com nova tentativa em caso de falha temporária. A troca de senha não pode falhar porque o provedor de e-mail demorou.

Como autenticar o domínio que envia

O conteúdo bom não salva um domínio sem autenticação. O mínimo:

• SPF: registro TXT no DNS que lista quem pode enviar pelo seu domínio.
• DKIM: assinatura nas mensagens, com a chave pública publicada no DNS. Seu provedor de envio fornece os registros.
• DMARC: política que diz o que fazer quando SPF e DKIM falham, e para onde mandar relatórios. Comece com p=none para observar e endureça depois.

Separe o tráfego: e-mail transacional num subdomínio ou num fluxo próprio do provedor, newsletter em outro. Assim uma campanha mal recebida não arrasta o aviso de senha junto. Montar o próprio servidor de envio é outra conversa, tratada em por que servidor de e-mail próprio é difícil de entregar.

Erros comuns

• Assunto com cara de campanha. A pessoa marca como spam, e os próximos avisos de segurança chegam na pasta errada.
• Recado dentro de imagem. Com imagens bloqueadas, o e-mail chega vazio.
• Remetente "nao-responda" que ninguém lê. A pessoa responde com uma dúvida real e a mensagem some. Use um endereço que chega a alguém, ou um Reply-To do suporte.
• Mesmo domínio e reputação para marketing e sistema. Reclamação da newsletter derruba a entrega do pedido confirmado.
• Envio síncrono na requisição. SMTP lento trava a tela da pessoa, e uma falha temporária perde o e-mail para sempre.
• Link por encurtador ou domínio de terceiro. Parece golpe, e provedores desconfiam de links que escondem o destino.

Checklist

• Cada e-mail transacional tem assunto que descreve o fato.
• Remetente e endereço são os mesmos em todos os envios do sistema.
• Todas as mensagens têm parte em texto puro.
• Com imagens bloqueadas, o recado continua inteiro.
• SPF, DKIM e DMARC estão publicados e passam numa mensagem de teste.
• Transacional e marketing saem por fluxos ou subdomínios separados.
• O envio passa por fila com nova tentativa.

Para fechar: peça uma redefinição de senha na sua própria conta, com as imagens bloqueadas. Só pelo assunto e pela primeira linha, você entendeu o que aconteceu?