Por que os e-mails transacionais do seu app caem no spam (e como resolver)

Por que a entrega de e-mail transacional é um jogo completamente diferente

Existe uma distinção crítica entre e-mails de marketing e e-mails transacionais que muitos desenvolvedores ignoram quando começam a pensar seriamente em entregabilidade. E-mails de marketing — newsletters, campanhas promocionais, comunicados — vão para assinantes que deram opt-in. Eles toleram atrasos ocasionais e até quedas esporádicas na pasta de spam. Se uma newsletter cai no spam para 2% da sua lista, é uma pena, mas o negócio continua rodando.

E-mails transacionais são completamente diferentes. Links de verificação, redefinições de senha, confirmações de compra, códigos de dois fatores, alertas de segurança da conta — eles chegam em momentos críticos da jornada do usuário. Uma redefinição de senha que vai para o spam significa um usuário trancado fora da própria conta, que provavelmente abrirá um ticket de suporte ou, pior, nunca mais voltará. Um e-mail de verificação no spam significa que um novo usuário não consegue concluir o cadastro e que seu funil de aquisição tem um vazamento silencioso e invisível.

Mesmo assim, e-mails transacionais são frequentemente configurados com menos cuidado que campanhas de marketing. Muitos desenvolvedores usam o código de envio que o framework oferece em vez de construir com cuidado o sistema de e-mail de verificação, apontam para um servidor SMTP compartilhado, fazem o deploy, testam uma vez com a própria caixa de entrada — que tem limites de spam generosos — e seguem em frente. Os problemas só aparecem quando usuários reais no Gmail, Outlook ou Yahoo relatam e-mails que não chegaram. Nesse ponto, a falha já vem acontecendo silenciosamente em produção há semanas.

SPF: a base da autenticação de e-mail

O Sender Policy Framework (SPF) é um registro DNS TXT no seu domínio de envio que informa ao mundo quais servidores de e-mail estão autorizados a enviar em seu nome. Quando o Gmail recebe um e-mail supostamente vindo de [email protected], ele faz uma consulta DNS ao registro SPF do seu domínio. Se o endereço IP do servidor que realmente enviou o e-mail estiver listado no seu registro SPF, o e-mail passa no SPF. Se não houver registro SPF algum — ou se o servidor remetente não estiver listado — o e-mail já é tratado com desconfiança antes de qualquer avaliação de conteúdo começar.

Configurar o SPF é simples quando você sabe o que fazer. Adicione um registro TXT ao DNS do seu domínio. O valor depende do seu provedor de envio. Com SendGrid: v=spf1 include:sendgrid.net ~all. Com AWS SES: v=spf1 include:amazonses.com ~all. Com Mailgun: v=spf1 include:mailgun.org ~all. A documentação do seu provedor traz o valor include exato. O sufixo ~all é um "soft fail" — e-mails de servidores não listados são sinalizados, mas não rejeitados de imediato. Quando tiver certeza de que seu registro SPF está completo e correto, você pode subir para -all (hard fail), que instrui os servidores receptores a rejeitar totalmente mensagens não autorizadas.

Uma pegadinha comum: o limite de 10 consultas DNS. Registros SPF que encadeiam várias diretivas include: podem estourar esse limite, fazendo o SPF falhar mesmo que todos os seus servidores estejam tecnicamente listados. Use o MXToolbox para checar seu registro SPF — ele aponta com clareza problemas de contagem de consultas. A forma como SPF, DKIM e DMARC se relacionam está bem explicada na documentação do SendGrid sobre autenticação de e-mail.

DKIM: prova criptográfica de que seu e-mail não foi alterado

O DomainKeys Identified Mail (DKIM) adiciona uma assinatura criptográfica a cada e-mail que você envia. A assinatura é gerada com uma chave privada mantida pelo seu provedor de envio, e os servidores receptores a verificam contra uma chave pública que você publica como registro DNS TXT. Se a assinatura confere, duas coisas ficam provadas: o e-mail realmente saiu da sua infraestrutura de envio e o conteúdo não foi modificado entre o envio e o recebimento.

Sem DKIM configurado, fica muito mais fácil para agentes maliciosos falsificarem seu domínio — enviar e-mails que parecem vir de [email protected] mas que na verdade foram enviados por outra pessoa. É exatamente assim que campanhas de phishing funcionam. Os filtros de spam também sabem disso, e é por isso que um e-mail sem assinatura DKIM válida vindo de um domínio que deveria ter uma é tratado com desconfiança redobrada. O Spamhaus e outros serviços de reputação levam o histórico de assinatura DKIM em conta nas notas de reputação de domínio.

A configuração do DKIM é feita pelo seu provedor de envio. Ele gera um par de chaves, guarda a chave privada na própria infraestrutura e entrega uma chave pública para você adicionar ao seu DNS como registro TXT. Depois que esse registro DNS estiver publicado e propagado, todo e-mail enviado em seu nome carregará automaticamente uma assinatura DKIM válida. A maioria dos grandes provedores — SendGrid, Mailgun, Amazon SES, Postmark — conduz você por esse processo durante a configuração inicial. Se você pulou essa etapa, volte e configure agora.

DMARC: a camada de política que amarra tudo

O DMARC (Domain-based Message Authentication, Reporting and Conformance) se apoia em SPF e DKIM ao definir o que os servidores receptores devem fazer quando um e-mail falha nessas verificações. Ele também introduz o conceito de "alinhamento" — a exigência de que o domínio no cabeçalho From do e-mail corresponda de fato ao domínio que passou no SPF ou no DKIM. Isso impede que atacantes passem na verificação SPF com um domínio enquanto falsificam outro no endereço From visível.

A abordagem correta para o DMARC é começar de forma gradual. Comece com uma política apenas de monitoramento: v=DMARC1; p=none; rua=mailto:[email protected]. O p=none diz aos servidores receptores para não tomar nenhuma ação nas falhas, apenas enviar relatórios para você. Esses relatórios agregados mostram quais servidores estão enviando e-mail em seu nome e se eles passam no SPF e no DKIM. Analise-os por algumas semanas antes de mudar qualquer política.

Quando tiver certeza de que todo o tráfego legítimo está passando, mude para p=quarantine (e-mails que falham vão para a pasta de spam) e por fim para p=reject (e-mails que falham são rejeitados de imediato). Essa progressão protege a reputação do seu domínio contra falsificação e ainda te dá tempo de identificar fontes de envio legítimas que você tenha esquecido. Uma política DMARC em p=reject combinada com SPF e DKIM válidos torna praticamente impossível que atacantes se passem pelo seu domínio de forma eficaz.

Reputação de IP: por que o seu servidor de envio importa

Mesmo com SPF, DKIM e DMARC perfeitos, seus e-mails ainda podem cair no spam se o endereço IP de onde saem tiver má reputação. Os servidores receptores mantêm — ou consultam serviços de terceiros que mantêm — listas de bloqueio e notas de reputação para IPs remetentes. Um IP com histórico de envio de spam, ou que aparece em listas de bloqueio mantidas por serviços como o Spamhaus, terá seus e-mails de saída tratados com desconfiança independentemente da sua configuração de autenticação.

Se você usa um endereço IP compartilhado de uma hospedagem compartilhada ou de um serviço SMTP barato, sua reputação fica atrelada a todos os outros que usam o mesmo IP. Um único spammer no mesmo pool compartilhado pode derrubar a entregabilidade de todos os remetentes daquele IP. Esse é um dos argumentos mais fortes para usar um provedor dedicado de e-mail transacional — SendGrid, Amazon SES, Postmark, Mailgun — em vez de enviar direto do servidor da aplicação ou por um SMTP compartilhado.

Em um IP de envio novo, você também precisará "aquecê-lo" gradualmente. Um pico repentino de volume a partir de um IP recém-criado parece comportamento de spam para os servidores receptores. Comece com volumes baixos e aumente aos poucos ao longo de dias ou semanas. A maioria dos provedores dedicados cuida do aquecimento de IP automaticamente se você está em um pool compartilhado, ou fornece cronogramas de aquecimento se você usa IP dedicado.

Conteúdo e linha de assunto: o que dispara os filtros

Além da autenticação e da reputação de IP, o próprio conteúdo do e-mail é avaliado pelos filtros de spam. Certos padrões disparam a classificação como spam de forma bem previsível. Palavras-gatilho na linha de assunto — "GRÁTIS", "GARANTIDO", "AJA AGORA", excesso de exclamações, TUDO EM MAIÚSCULAS — são as óbvias que a maioria dos desenvolvedores evita. Menos óbvio: assuntos vagos demais ("Mensagem importante para você"), urgentes demais ("Sua conta será encerrada") ou promocionais demais para algo que deveria ser um e-mail transacional.

A proporção entre texto e imagem também conta. Um e-mail feito quase todo de imagens com pouquíssimo texto é um padrão clássico de spam — quem faz envio em massa usa imagens para esconder palavras-chave dos filtros baseados em texto. E-mails transacionais devem ser predominantemente textuais, com poucas imagens. HTML quebrado — tags não fechadas, atributos malformados — é outro sinal de alerta. Envie sempre uma alternativa em texto puro junto com a versão HTML. Filtros de spam olham e-mails somente em HTML com desconfiança elevada, e sistemas de e-mail corporativos muitas vezes removem o HTML por completo.

Testando a entrega dos seus e-mails — da forma certa

O método de teste mais rápido e prático para entrega de e-mail é este: envie um e-mail de teste para uma caixa de e-mail temporário recém-criada e verifique tanto a caixa de entrada quanto a pasta de spam. Isso dá um retorno imediato e inequívoco sobre se o e-mail está chegando à caixa de entrada ou sendo filtrado. Diferente de testar com a sua própria conta do Gmail — que talvez já tenha você na lista de permitidos como remetente frequente — um endereço temporário novo não tem histórico algum com o seu domínio, o que simula com muito mais fidelidade o primeiro contato de um usuário novo.

Você deve verificar se o e-mail de verificação realmente chega sempre que mudar algo capaz de afetar a entrega: trocar de provedor de e-mail, alterar significativamente seu template HTML, mudar o domínio de envio, adicionar um novo subdomínio de envio ou fazer deploy em um novo ambiente (staging, produção). Leva dois minutos e dá uma evidência definitiva. A alternativa — esperar que os usuários reportem problemas — significa que suas falhas de entregabilidade já vêm acontecendo silenciosamente por um período indeterminado.

Além da checagem de caixa de entrada e spam, use o verificador de saúde de e-mail do MXToolbox para avaliar a situação geral do seu domínio: SPF, DKIM, DMARC, status em listas negras e configuração dos registros MX, tudo em um só lugar. Torne isso parte do seu checklist de pré-lançamento para cada nova aplicação ou domínio de envio. Consulte também as diretrizes da OWASP sobre boas práticas de e-mail relacionadas a segurança.

Taxa de rejeição e reclamações de spam: as métricas que importam

Duas métricas têm efeito desproporcional na entregabilidade de longo prazo: a taxa de rejeição (bounce) e a taxa de reclamações de spam. Uma taxa de rejeição acima de 2% informa aos servidores receptores e ao seu provedor que você está enviando para muitos endereços inválidos ou inexistentes — um padrão associado a listas compradas e operações de spam. Mesmo fazendo todo o resto certo, uma taxa de rejeição alta vai causar problemas de entrega. Remova hard bounces da sua lista de envio imediatamente e em definitivo.

Uma taxa de reclamações acima de 0,1% (uma reclamação a cada mil e-mails enviados) é o limite em que a maioria dos provedores começa a restringir sua conta. O Postmaster Tools do Gmail reporta a taxa de reclamações diretamente, se você o tiver configurado. Monitore essas métricas pelo painel do seu provedor de envio. Se as reclamações estão subindo, investigue o motivo — você está enviando para usuários que não deram consentimento explícito? Seus e-mails são frequentes demais? Existe um descompasso entre o que os usuários esperavam e o que estão recebendo?

Checklist completo de entregabilidade

• Registro SPF: registro DNS TXT no domínio de envio listando todos os servidores autorizados. Teste com o MXToolbox.
• DKIM: assinatura criptográfica configurada pelo provedor de envio, chave pública publicada no DNS.
• DMARC: comece com o monitoramento p=none, avance para p=quarantine e depois p=reject após revisar os relatórios agregados.
• Provedor de envio dedicado: use SendGrid, SES, Postmark ou Mailgun — não o servidor da sua aplicação nem SMTP compartilhado.
• Assuntos limpos: específicos, relevantes, sem palavras-gatilho, sem pontuação ou maiúsculas em excesso.
• HTML + texto puro: inclua sempre os dois. Nunca envie e-mails somente em HTML.
• Sem encurtadores de URL: use URLs completas e diretas no corpo do e-mail e nos links de verificação.
• Link de descadastro: inclua até em e-mail transacional quando fizer sentido — alguns provedores exigem.
• Endereço físico: exigido pela CAN-SPAM e por regulamentações semelhantes em muitas jurisdições.
• Tratamento de hard bounce: remova imediatamente; nunca tente reenviar para um hard bounce.
• Monitoramento de reclamações: configure o Gmail Postmaster Tools; acompanhe a taxa de reclamações no painel.
• Teste de caixa de entrada: envie e-mails de teste para caixas temporárias novas antes de cada deploy e após qualquer mudança de template ou configuração.
• Check-up no MXToolbox: inclua no checklist de pré-lançamento para cada novo domínio e ambiente.

Quando usar um serviço dedicado de e-mail transacional

Se a sua aplicação envia qualquer e-mail que o usuário precise receber para conseguir usá-la — links de verificação, redefinições de senha e os recibos que encerram uma jornada completa de cadastro e pagamento — você deveria usar um provedor dedicado de e-mail transacional desde o primeiro dia. O custo é baixo (muitas vezes gratuito até dezenas de milhares de e-mails por mês), a confiabilidade é dramaticamente melhor que um SMTP caseiro, e a infraestrutura de entregabilidade — pools de IP compartilhados com reputação gerenciada, assinatura DKIM automática, tratamento de bounces e reclamações — é mantida por equipes cujo trabalho inteiro é manter e-mail nas caixas de entrada.

O erro caseiro mais comum é rodar um servidor de e-mail no mesmo IP da aplicação web, ou usar o serviço SMTP embutido de uma hospedagem barata. Esses IPs entram rotineiramente em listas de bloqueio de serviços como o Spamhaus, porque o ambiente de hospedagem é compartilhado com agentes mal-intencionados. Migrar para um provedor transacional dedicado costuma ser uma tarde de trabalho e tem impacto positivo imediato na entregabilidade. É uma das melhorias de infraestrutura de maior alavancagem que um time pequeno pode fazer. Times preocupados com privacidade também devem revisar as orientações da Electronic Frontier Foundation sobre tratar dados de usuários com responsabilidade quando há e-mail envolvido. Além disso, conferir endereços contra bases de vazamentos conhecidos pelo Have I Been Pwned pode complementar sua prevenção a fraudes na criação de novas contas.