Antes de tudo: “entregou” não significa “chegou na caixa de entrada”

Muita gente confunde “aceito pelo servidor do destino” com “visível na inbox do usuário”. Um e-mail pode ser aceito e, mesmo assim, ser: movido para spam, arquivado, silenciado, atrasado, bloqueado por políticas internas ou filtrado por regras do destinatário.

Deliverability é um conjunto: autenticação, reputação, conteúdo, infraestrutura, listas e comportamento de envio. Quando um desses pontos fica frágil, os provedores (Gmail, Outlook, Yahoo e outros) reagem com filtros e limitações. A boa notícia: essas reações deixam rastros.

Padrão #1 — Autenticação incompleta (SPF, DKIM e DMARC)

Esse é o padrão mais frequente em testes iniciais. A empresa “configurou SPF”, mas esqueceu DKIM. Ou configurou os dois, mas DMARC está ausente (ou quebrado). Resultado: o provedor do destinatário não consegue confirmar que o e-mail é legítimo, e a entrega vira loteria.

Sinais típicos

• Alta taxa de spam mesmo com conteúdo “ok”.
• Rejeições com mensagens relacionadas a política de autenticação.
• Inconsistência: chega em alguns provedores e falha em outros.

Como testar

• Verifique se o domínio tem um registro SPF válido e sem múltiplos SPF conflitantes.
• Confirme que DKIM está assinando (a assinatura aparece nos headers e passa validação).
• Configure DMARC, mesmo que no início seja em modo monitoramento (p=none) para coletar relatórios.

Correção prática

Garanta alinhamento: o domínio usado no “From” deve alinhar com SPF/DKIM conforme sua política DMARC. Em fluxos transacionais (OTP, login, reset de senha), esse alinhamento costuma ser ainda mais crítico, porque os provedores tratam esses e-mails como alvo comum de fraude.

Padrão #2 — Domínio novo ou “frio” (sem reputação)

Um domínio recém-criado, ou um domínio que nunca enviou volume consistente, é “desconhecido”. Para o provedor do destinatário, desconhecido significa risco. Se você começa enviando muito de uma vez, ele interpreta como comportamento típico de spammer: sobe o filtro, limita velocidade ou bloqueia.

Sinais típicos

• Atrasos grandes: o e-mail “vai”, mas chega minutos (ou horas) depois.
• Taxa de spam alta no começo e melhora lenta ao longo de dias.
• Bloqueios temporários por volume.

Como testar

• Envie para caixas de diferentes provedores (Gmail/Outlook/Yahoo) e compare comportamento.
• Meça tempo de entrega e consistência em 24–72 horas.
• Observe respostas SMTP e logs do seu provedor/ESP.

Correção prática

Faça um “aquecimento” (warm-up) gradual. Mesmo em transacionais, se você tem picos de envio (ex.: campanhas de onboarding), escalone e monitore. A reputação é construída com consistência: baixa taxa de bounces, poucos complaints, bom engajamento.

Padrão #3 — IP compartilhado com vizinhança ruim

Se você usa um serviço de envio com IP compartilhado, sua reputação não depende só de você. Depende do comportamento de outros remetentes no mesmo pool. Se a “vizinhança” tem muito abuso, você pode sofrer bloqueios e spam mesmo fazendo tudo certo.

Sinais típicos

• Quedas repentinas de entregabilidade sem mudanças no seu lado.
• Problema aparece em ondas, especialmente em determinados provedores.
• Taxa de spam piora em horários específicos (quando o pool está mais “sujo”).

Como testar

• Compare envio por rotas diferentes (seu ESP permite trocar pool/rotas).
• Peça relatórios de reputação ao provedor de envio (ou migre para IP dedicado em casos críticos).
• Faça testes A/B por subdomínio ou por provedor.

Correção prática

Se o e-mail é missão crítica (OTP e segurança, por exemplo), IP dedicado ou pool premium costuma ser mais estável. Em campanhas, dá para conviver com IP compartilhado, mas com monitoramento e segmentação.

Padrão #4 — Conteúdo com gatilhos de spam (mesmo sem “spam óbvio”)

Muita gente imagina que spam é só “GANHE DINHEIRO AGORA!!!”. Na prática, gatilhos são sutis: proporção de imagem/texto ruim, links encurtados suspeitos, excesso de urgência, assunto enganoso, HTML quebrado, rastreadores agressivos, repetição de palavras, e até nomes de arquivos anexos.

Sinais típicos

• Entrega ok, mas cai no spam com frequência.
• Em certos provedores (especialmente Gmail) o filtro é mais rígido.
• Alterar um detalhe (assunto/CTA/link) muda completamente o resultado.

Como testar

• Faça testes controlados: mesma lista, variando apenas 1 elemento (assunto, link, layout, domínio do link).
• Teste versões “limpas”: texto simples (plain text) vs HTML completo.
• Valide seu HTML (tags fechadas, charset, links corretos, sem scripts).

Correção prática

Priorize clareza e consistência. Em e-mails transacionais, seja econômico em marketing. Em campanhas, cuide da higiene de links: domínios estáveis, HTTPS, sem encurtadores genéricos. E evite “promessas fortes”: provedores estão cada vez mais sensíveis a linguagem que parece fraude.

Padrão #5 — Lista suja (bounces, traps e endereços inválidos)

Listas compradas, listas antigas e capturas mal validadas são receita para desastre. Endereços inválidos geram hard bounce; traps e reclamadores derrubam reputação. Mesmo que você esteja “só testando”, se você envia para uma lista ruim, o provedor entende: “remetente problemático”.

Sinais típicos

• Taxa de bounce acima do normal logo no início.
• Quedas progressivas de inbox placement ao longo dos envios.
• Domínio/IP perde reputação rápido após campanhas.

Como testar

• Separe lista de teste (seed list) saudável e controlada.
• Meça hard bounce, soft bounce, complaints e unsubscribes por envio.
• Valide e-mails na captura (double opt-in quando fizer sentido).

Correção prática

Higienize: remova hard bounces imediatamente, faça suppression de endereços problemáticos, e trate reengajamento com cautela. Em marketing, qualidade de lista vale mais que volume.

Padrão #6 — Throttling e atrasos (limitação de velocidade)

Às vezes o e-mail não falha; ele só fica na fila. O provedor do destinatário aceita parcialmente, pede para você reduzir velocidade, ou segura temporariamente. Isso é comum quando há aumento de volume, reputação baixa, ou padrões que parecem automatizados demais.

Sinais típicos

• Mensagens chegam com atraso inconsistente.
• Logs mostram respostas temporárias (4xx) e re-tentativas.
• Alguns domínios recebem rápido; outros demoram muito.

Como testar

• Observe métricas de fila: tempo médio até entrega, tentativas, códigos 4xx.
• Teste em horários diferentes (picos vs horários calmos).
• Envie em lotes menores e compare a latência.

Correção prática

Ajuste cadência: limite de envios por minuto, backoff inteligente, segmentação por provedor. Para fluxos críticos (OTP), priorize filas separadas e rotas otimizadas.

Padrão #7 — Problemas de alinhamento no “From”, “Return-Path” e domínio de rastreamento

Um erro clássico: o “From” é um domínio, o Return-Path é outro, e os links de rastreamento usam um terceiro. Isso pode quebrar o alinhamento do DMARC e reduzir confiança. Também pode ativar filtros anti-phishing quando o nome do remetente e domínio não “batem” com o que o usuário espera.

Sinais típicos

• DMARC falhando mesmo com SPF/DKIM “aparentemente ok”.
• Alto spam em provedores específicos.
• Alertas de “mensagem suspeita” ou “pode ser phishing”.

Como testar

• Abra os headers e confirme quais domínios estão presentes em From/Return-Path/DKIM.
• Teste com rastreamento desligado para ver se melhora.
• Use subdomínios dedicados para tracking e autenticação consistente.

Correção prática

Simplifique: alinhe domínios e use subdomínios com DNS bem configurado. Quanto mais previsível para o provedor (e para o usuário), melhor.

Padrão #8 — Infraestrutura: rDNS, HELO, TLS e erros de configuração “invisíveis”

Em setups próprios (ou integrações avançadas), detalhes de infraestrutura fazem diferença: reverse DNS ausente, hostname inconsistente, HELO/EHLO mal configurado, TLS fraco ou mal negociado. Muitos filtros modernos são “pontuadores”: cada detalhe ruim soma e empurra para spam ou atraso.

Sinais típicos

• Rejeições técnicas em alguns domínios.
• Problemas aparecem apenas quando você troca de servidor/região.
• Entrega piora após mudanças de DNS/infra.

Como testar

• Revise configuração de hostname, rDNS e consistência do HELO/EHLO.
• Verifique negociações TLS e compatibilidade.
• Compare entrega entre regiões e IPs.

Correção prática

Se você não quer “caçar fantasma”, use uma checklist fixa de infraestrutura em cada mudança. Em muitos times, a deliverability quebra quando alguém mexe em DNS/roteamento sem ligar isso ao e-mail.

Padrão #9 — Misturar e-mail transacional com marketing no mesmo domínio

OTP, reset de senha e recibos precisam chegar. Campanhas têm outra dinâmica (engajamento variável, risco maior de complaints). Se você usa o mesmo domínio e a mesma reputação para tudo, um problema no marketing pode derrubar seus transacionais. Isso vira uma falha “sistêmica”: não é um e-mail específico, é a confiança do remetente indo embora.

Sinais típicos

• Depois de uma campanha pesada, OTP começa a atrasar ou cair no spam.
• Suporte recebe queixa de “não chega código”, mas só em certos provedores.
• Métricas pioram em ondas, seguindo calendário de campanhas.

Como testar

• Separe envios: transacional em subdomínio dedicado, marketing em outro.
• Monitore inbox placement de transacional isoladamente.
• Teste o mesmo template com rotas diferentes.

Correção prática

A separação por subdomínio é uma das práticas mais “baratas” e eficientes para estabilidade. Não garante perfeição, mas reduz o efeito dominó.

Padrão #10 — Falha por experiência do usuário: links, formatação e acessibilidade

Nem toda falha de deliverability é só spam filter. Às vezes o e-mail chega, mas o usuário não “vê” como esperado: layout quebrado, texto ilegível em modo escuro, links pequenos, CTA escondido, imagens bloqueadas, ou assunto pouco claro que faz a pessoa ignorar.

Sinais típicos

• Relatos de “não recebi”, mas logs mostram entrega e abertura quase zero.
• Baixa taxa de clique em CTA essencial (confirmação, verificação).
• Engajamento muito diferente entre mobile e desktop.

Como testar

• Teste visual em mobile e desktop, com imagens bloqueadas e modo escuro.
• Garanta fallback em texto (plain text) e CTA visível sem imagem.
• Use assuntos claros e consistentes para o usuário identificar a mensagem.

Correção prática

Em e-mail transacional, simplicidade é uma vantagem: texto claro, CTA grande, menos dependência de imagens. Em campanhas, design pode ser mais elaborado, mas sem sacrificar legibilidade e acessibilidade.

Um fluxo de teste que funciona (sem confusão)

Para evitar testes aleatórios, use um roteiro. A ideia é isolar variáveis e identificar onde está o gargalo: autenticação, reputação, conteúdo, lista, cadência ou infraestrutura.

Passo 1 — Monte uma “seed list” pequena e confiável

Tenha caixas reais em provedores principais (Gmail, Outlook, Yahoo e pelo menos um provedor corporativo). Evite usar uma lista grande logo de cara. O objetivo inicial é previsibilidade e leitura de sinais.

Passo 2 — Teste com template minimalista

Envie primeiro um e-mail simples (texto + um link limpo), com autenticação correta. Se isso não chega na inbox, o problema provavelmente não é design — é autenticação, reputação ou infra.

Passo 3 — Faça testes controlados de conteúdo

Altere uma coisa por vez: assunto, corpo, links, domínio do link, HTML vs texto. Se uma mudança pequena derruba a inbox, você encontrou um gatilho importante.

Passo 4 — Meça latência e respostas SMTP

Não olhe só “delivered”. Olhe tempo até entrega, 4xx temporários, re-tentativas e padrões por provedor. Às vezes o problema é throttling e você precisa ajustar cadência.

Passo 5 — Separe transacional e marketing

Se você tem e-mails críticos, isole-os em subdomínio, rota e, se necessário, IP diferente. Essa separação evita que uma campanha mais agressiva contamine todo o seu ecossistema.

Checklist final: sinais e ações rápidas

• Cai no spam desde o início: revise SPF/DKIM/DMARC + alinhe domínios + simplifique conteúdo.
• Atrasos grandes e 4xx: cadência/limites por provedor + reputação em aquecimento.
• Rejeições diretas: infraestrutura, políticas e autenticação; leia o motivo exato no log SMTP.
• Oscilação sem mudança no seu lado: IP compartilhado/pool, reputação da vizinhança.
• Transacional falha após campanha: separar domínios/rotas e proteger reputação do crítico.
• Usuário diz que não viu: UX do e-mail, assunto claro, CTA visível, compatibilidade mobile.