Verifique a autenticação, as respostas dos provedores, a qualidade do público e o descadastro para entender por que um e-mail é rejeitado ou cai no spam.
Entrega e chegada à caixa de entrada são coisas diferentes. Um servidor de recebimento pode aceitar uma mensagem e colocá-la no spam. Um painel de campanha que mostra “entregue” não prova que o leitor a viu.
Quando surgir um problema, reúna as evidências antes de mudar o texto ou trocar de provedor. O que está falhando pode ser a autenticação, a reputação, o público ou a própria mensagem.
Para mensagens rejeitadas ou adiadas, examine a resposta SMTP real e o código de status estendido. Falhas temporárias e rejeições permanentes exigem tratamentos diferentes. As perguntas frequentes para remetentes do Google descrevem as duas; elas não dizem que todo descumprimento agora gera erros permanentes.
Se as mensagens são aceitas, mas aparecem no spam, examine os resultados de autenticação nos cabeçalhos da mensagem recebida, os dados de reputação dos provedores, quando houver, e as mudanças recentes no público ou no volume. Algumas caixas de teste ajudam a diagnosticar um problema, mas não medem a chegada à caixa de entrada na lista inteira.
Um código de status estendido tem três números separados por pontos, definidos na RFC 3463. O primeiro número é a classe. Um código que começa com 4 é uma falha temporária, e o servidor de envio deve tentar de novo mais tarde. Um código que começa com 5 é uma falha permanente, então reenviar a mesma mensagem sem mudanças não vai adiantar.
O segundo número delimita o assunto. Os códigos da faixa X.1.X tratam de endereçamento, e 5.1.1 geralmente significa que a caixa postal não existe. Suprima esse endereço. Os códigos da faixa X.7.X tratam de segurança ou de política, e é aí que costumam aparecer os problemas de autenticação e de reputação.
O Google lista as respostas que o Gmail retorna na sua referência de erros SMTP. Leia o texto completo da resposta, além do código, porque um mesmo código pode abranger vários motivos diferentes.
O Google Postmaster Tools mostra como o Gmail enxerga o seu domínio de envio, incluindo a taxa de spam denunciado pelos usuários a que os requisitos do Google se referem. Você verifica o domínio com um registro DNS. O Gmail só mostra dados quando um domínio envia um volume diário suficiente para os usuários dele, então um remetente pequeno pode ver painéis vazios.
O Smart Network Data Services da Microsoft, conhecido como SNDS, traz relatórios sobre as mensagens enviadas de endereços IP específicos para as caixas postais de consumidores do Outlook.com, incluindo taxas de reclamação e ocorrências em spam traps. Você cadastra os endereços IP que controla, então ele é mais útil com IPs de envio dedicados. Em IPs compartilhados, pergunte ao seu provedor de envio o que ele monitora.
Nenhuma das duas ferramentas diz onde uma campanha específica foi parar. Elas mostram tendências diárias, que é o que você precisa quando um problema foi se acumulando ao longo de vários envios.
O SPF autoriza a infraestrutura de envio para um domínio de envelope. O DKIM assina a mensagem com a identidade de um domínio. O DMARC verifica o alinhamento com o domínio visível no From e publica uma política e um mecanismo de relatórios. Nenhum deles garante a chegada à caixa de entrada.
Use os registros fornecidos pelo seu provedor de envio e verifique o resultado em uma mensagem realmente recebida. Não adicione registros SPF conflitantes nem presuma que um registro DNS prova que todos os caminhos de envio o usam corretamente. A sua infraestrutura também precisa de DNS reverso adequado e de transporte seguro.
No Brew, siga o fluxo de verificação de domínio e publique os registros solicitados. Revise o endereço do remetente que a campanha ou a automação usa de fato, principalmente quando um agente opera várias marcas.
Uma política DMARC é um registro TXT no host _dmarc do domínio do endereço do remetente. Comece com p=none. Essa política pede aos receptores que não tomem nenhuma ação específica com as mensagens reprovadas, e eles continuam enviando relatórios agregados para o endereço rua.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Os relatórios listam todas as fontes que enviam mensagens em nome do seu domínio e se cada uma passou no SPF ou no DKIM com alinhamento. É provável que você encontre ferramentas de que nem se lembrava, como um sistema de cobrança ou um help desk. Corrija ou remova cada fonte reprovada.
Quando todas as mensagens legítimas passarem, mude para p=quarantine. Essa política pede aos receptores que tratem as mensagens reprovadas como suspeitas, o que geralmente significa mandá-las para o spam.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"A política mais rígida, p=reject, pede aos receptores que recusem as mensagens reprovadas. Só passe para ela depois que a quarentena tiver funcionado por um tempo sem que nenhuma mensagem legítima falhe. Continue lendo os relatórios em todas as fases. Uma ferramenta nova que comece a enviar em nome do seu domínio vai aparecer primeiro ali.
Um subdomínio de envio dedicado, como mail.example.com, é a exceção. Quando nada mais envia por ele e o seu provedor já verificou o SPF e o DKIM, ele pode começar em p=reject. O Brew recomenda p=reject para um subdomínio dedicado que ele mesmo configurou e p=none para um domínio principal pelo qual outros serviços podem enviar.
As diretrizes do Google separam os requisitos para todos os remetentes de regras mais rígidas para quem chega a cerca de 5.000 mensagens por dia para contas pessoais do Gmail. O Google pede taxas de spam abaixo de 0,1% e alerta contra chegar a 0,3%. Os requisitos para envios em massa incluem SPF e DKIM, DMARC, alinhamento e descadastro com um clique nas mensagens para inscritos em que ele se aplica.
A lista do Google para todo remetente, em qualquer volume, inclui estes itens:
Os remetentes em massa também precisam fazer o seguinte:
p=none.Ao aplicar o limite, o Google soma as mensagens do mesmo domínio principal, e um domínio que o ultrapassou uma vez mantém o rótulo de remetente em massa. As perguntas frequentes para remetentes dele explicam como funciona a contagem.
As orientações do Yahoo também tratam de autenticação, reclamações e descadastro. O Yahoo não publica o mesmo limite numérico para remetentes em massa; consulte as perguntas frequentes dele em vez de aplicar o número do Gmail a todos os provedores.
A Microsoft anunciou em 2025 que domínios que enviam mais de 5.000 e-mails por dia para as caixas postais de consumidores dela, os endereços outlook.com, hotmail.com e live.com, precisam passar no SPF e no DKIM e publicar DMARC. A política DMARC pode ser p=none, e o domínio do From precisa estar alinhado com o SPF ou com o DKIM.
Orientações dos provedores revisadas em 28 de setembro de 2026. Consulte as páginas indicadas nos links ao diagnosticar um novo incidente.
O descadastro com um clique da RFC 8058 é um mecanismo de cabeçalhos e de POST via HTTPS. Um link visível no rodapé também é útil e exigido pelas regras aplicáveis, mas uma página de preferências, sozinha, não implementa o protocolo.
Uma mensagem compatível com o descadastro com um clique leva dois cabeçalhos:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickQuando o leitor clica em cancelar inscrição na caixa de entrada, o provedor de e-mail envia um POST para a URL HTTPS com o corpo List-Unsubscribe=One-Click. O endereço mailto: é uma alternativa para programas de e-mail que não suportam o clique único. A RFC 8058 também exige uma assinatura DKIM válida que cubra os dois cabeçalhos. Faça a URL ser específica do destinatário e difícil de adivinhar. Scanners de segurança costumam acessar os links das mensagens recebidas, então um GET simples nessa URL não deve descadastrar ninguém.
O Brew adiciona os cabeçalhos List-Unsubscribe e List-Unsubscribe-Post aos envios de marketing, apontando para uma URL HTTPS assinada e exclusiva de cada destinatário, que aceita o POST do clique único.
Confirme que um descadastro de marketing impede os envios de marketing seguintes por todos os caminhos que você usa. Preserve as supressões ao importar contatos ou trocar de plataforma. Mantenha as mensagens transacionais essenciais separadas, na finalidade e na configuração de envio.
Revise de onde vieram os endereços e o que as pessoas esperavam receber quando se cadastraram. Remova endereços inválidos pelo processo de supressão do provedor, investigue picos de reclamações e evite reenviar para as pessoas só porque o rastreamento diz que elas não abriram.
Não existe idade de lista, proporção entre imagem e texto ou palavra proibida universal que garanta a entrega. Um aumento repentino de volume para uma lista que você mal conhece é um problema mais sério do que usar a palavra “grátis”.
Se um agente envia a campanha, as mesmas checagens valem. Use fatos verificados, um público relevante e um endereço de resposta monitorado. Corrija a causa identificada, faça um envio de teste controlado e revise as respostas dos provedores antes de ampliar de novo.
