A descoberta quase nunca é sua. Alguém liga perguntando por que você não respondeu, e a resposta está na caixa de spam da pessoa. Ou pior: nem lá, porque a mensagem foi recusada e o aviso de erro passou despercebido.

O que torna esse problema especialmente incômodo é que ele não gera alarme. Um site fora do ar todo mundo nota. Uma proposta que não chegou apenas não vira negócio, e ninguém fica sabendo.

Na maioria absoluta dos casos, a causa não é o conteúdo da mensagem. É a ausência ou o erro de configuração de três registros no DNS do seu domínio. Este guia explica o que cada um faz, por que eles se tornaram obrigatórios na prática e em que ordem investigar quando o problema já está acontecendo.

O problema não é a palavra ‘promoção’ no assunto

Vale começar desfazendo o mito mais difundido.

Filtros de spam modernos não decidem principalmente pelo texto. Eles avaliam, antes de qualquer coisa, se é possível provar que a mensagem veio mesmo de quem diz ter vindo — e qual é o histórico de comportamento daquele domínio e daquele servidor de envio.

Isso reordena as prioridades. Reescrever o assunto de um e-mail não resolve nada se o domínio não consegue se autenticar. Por outro lado, um domínio bem configurado e com bom histórico entrega mensagens com “promoção” no assunto sem dificuldade.

A razão dessa mudança é simples: o protocolo original de e-mail não previa verificação de identidade. Qualquer servidor pode afirmar estar enviando em nome de qualquer domínio. Toda a estrutura de autenticação existe para corrigir essa lacuna sem quebrar a compatibilidade.

As regras mudaram — e isso explica muita coisa

Se as suas mensagens passaram a ter problema sem que nada mudasse do seu lado, é provável que o que mudou tenha sido o outro lado.

A partir de fevereiro de 2024, Gmail e Yahoo passaram a exigir autenticação de remetentes, com requisitos mais rígidos para quem envia em volume — a partir de 5.000 mensagens por dia para contas pessoais desses provedores. A Microsoft adotou exigências equivalentes para contas de consumidor do Outlook.com a partir de maio de 2025, com aplicação plena em seguida.

Para remetentes de alto volume, o conjunto exigido inclui SPF, DKIM e um registro DMARC publicado, além de mecanismo funcional de descadastro e taxa de reclamação de spam mantida abaixo do limite divulgado. Para quem envia pouco, as exigências formais são menores — mas os mesmos sinais continuam sendo usados na decisão entre caixa de entrada e spam.

Ou seja: mesmo uma empresa que envia dez mensagens por dia é avaliada pelos mesmos critérios. A diferença é que ela não é rejeitada de imediato — apenas classificada com mais desconfiança.

*Esses limites e datas são reconfirmáveis nas diretrizes oficiais de remetente do Google e da Microsoft, que mudam com alguma frequência.*

SPF: quem pode enviar pelo seu domínio

O SPF é um registro publicado no DNS que lista quais servidores estão autorizados a enviar mensagens em nome do seu domínio.

Quando um servidor recebe uma mensagem que diz vir de suaempresa.com.br, ele consulta o SPF do domínio e verifica se o servidor de origem está na lista. Se não estiver, isso é um sinal negativo.

O erro mais comum: ter mais de um registro SPF publicado. O domínio deve ter exatamente um, e todas as origens autorizadas ficam dentro dele. Quando a empresa contrata uma ferramenta de e-mail marketing, depois um sistema de notas fiscais, depois um CRM, é frequente que cada fornecedor peça a publicação de um registro — e o resultado são vários registros conflitantes, o que invalida a verificação inteira.

O segundo erro mais comum: exceder o limite de consultas de DNS. A especificação do SPF permite no máximo dez consultas durante a avaliação, e cada inclusão de um serviço de terceiros consome uma ou mais. Registros que acumularam fornecedores ao longo dos anos estouram esse limite e falham silenciosamente.

Vale, portanto, tratar o SPF como um inventário: toda ferramenta que envia e-mail em nome da empresa precisa estar nele, e nenhuma que já foi descontinuada deve permanecer.

DKIM: a assinatura que prova a origem

O DKIM adiciona uma assinatura criptográfica às mensagens enviadas. O servidor de envio assina com uma chave privada; o servidor de destino busca a chave pública publicada no DNS do seu domínio e verifica a assinatura.

Se ela confere, duas coisas ficam demonstradas: a mensagem saiu mesmo de um servidor autorizado pelo domínio, e o conteúdo não foi alterado no caminho.

O DKIM é mais robusto que o SPF em um aspecto importante: ele sobrevive ao encaminhamento. Quando alguém redireciona uma mensagem, o servidor que a entrega deixa de ser o autorizado no SPF, e a verificação falha. A assinatura DKIM continua válida.

Na prática, a configuração do DKIM é feita pelo provedor de e-mail, que gera o par de chaves e fornece o registro a ser publicado no DNS. É comum haver mais de um, um para cada serviço de envio.

DMARC: a política que amarra tudo

SPF e DKIM verificam. O DMARC decide o que fazer com o resultado — e adiciona uma peça que os outros dois não têm.

Alinhamento. Este é o conceito que mais causa configuração incorreta. Não basta que SPF ou DKIM passem: o domínio verificado precisa corresponder ao domínio que o destinatário vê no campo do remetente. Uma ferramenta de terceiros pode passar no SPF usando o próprio domínio dela, enquanto a mensagem exibe o seu — tecnicamente autenticada, mas não alinhada, e portanto reprovada no DMARC.

Política. O registro DMARC informa o que o destinatário deve fazer quando a verificação falha, em três níveis:

Política	O que acontece	Quando usar
p=none	Nada; apenas gera relatórios	Fase inicial, para diagnóstico
p=quarantine	Mensagem vai para o spam	Depois de corrigir as falhas legítimas
p=reject	Mensagem é recusada	Quando todas as origens estão mapeadas

Relatórios. O DMARC permite receber relatórios sobre as tentativas de envio usando o seu domínio, incluindo as que falharam. É a única forma de descobrir tanto ferramentas legítimas esquecidas quanto tentativas de falsificação da sua marca.

A sequência recomendada é sempre a mesma: publicar com p=none, ler os relatórios por algumas semanas, corrigir o que aparecer, e só então endurecer a política. Publicar p=reject antes de mapear as origens é a forma mais rápida de bloquear os próprios e-mails da empresa.

Roteiro de diagnóstico

Se o problema já está acontecendo, siga nesta ordem — ela vai do mais provável ao menos provável:

1. Verifique se os três registros existem. Ferramentas públicas de consulta de DNS mostram SPF, DKIM e DMARC de qualquer domínio em segundos. Ausência dos três é a causa mais comum.
2. Confirme que há apenas um registro SPF e que ele inclui todas as ferramentas em uso hoje.
3. Verifique o alinhamento. O domínio que aparece no remetente é o mesmo que passa na verificação? Este é o erro clássico de quem usa ferramentas de terceiros.
4. Leia os relatórios DMARC. Eles apontam exatamente qual origem está falhando.
5. Cheque a reputação do IP de envio. Se as caixas estão no mesmo servidor de um site compartilhado, o comportamento de outros domínios pode afetar a sua entrega.
6. Revise a higiene da lista, se o problema for com disparos em massa: endereços inválidos, contatos que nunca abriram e ausência de descadastro fácil elevam a taxa de reclamação, e ela pesa mais que qualquer ajuste técnico.
7. Examine o conteúdo, por último: excesso de links encurtados, anexos incomuns e imagens sem texto alternativo contribuem — mas raramente são a causa principal.

O que a configuração não resolve

Vale ser honesto sobre o limite dessa solução, porque autenticação virou promessa de bala de prata.

SPF, DKIM e DMARC provam identidade, não qualidade. Um domínio perfeitamente autenticado que envia mensagens não solicitadas acumula reclamações e passa a ser filtrado assim mesmo. A reputação é construída pelo comportamento ao longo do tempo: taxa de reclamação, proporção de endereços inexistentes, engajamento dos destinatários.

Dois cenários em que a configuração correta não basta:

Volume súbito em domínio novo. Um domínio recém-criado que dispara milhares de mensagens no primeiro dia é tratado com desconfiança, independentemente da autenticação. O aquecimento gradual do volume é parte do processo.

Listas compradas ou antigas. Endereços inexistentes e reclamações de destinatários que não pediram para receber destroem a reputação mais rápido do que qualquer registro de DNS consegue reconstruir.

Separação entre e-mail transacional, marketing e conversacional

Uma prática que resolve problemas antes de eles aparecerem: não misturar os três tipos de envio na mesma origem.

• Conversacional é a troca de mensagens do dia a dia, das caixas da equipe.
• Transacional são mensagens disparadas por sistema: confirmação de pedido, redefinição de senha, nota fiscal.
• Marketing são campanhas e newsletters, enviadas para muitos destinatários ao mesmo tempo.

O problema de misturá-los é de contaminação: uma campanha com alta taxa de reclamação prejudica a reputação usada também pelas mensagens operacionais. E as operacionais são justamente as que não podem falhar — ninguém aceita que a confirmação de compra vá para o spam.

A separação costuma ser feita por subdomínio de envio, mantendo reputações independentes. Para quem tem volume relevante, vale também separar a infraestrutura: caixas em um serviço de e-mail dedicado e disparos automatizados em uma origem própria de SMTP, de modo que um problema não contamine o outro.

Manutenção contínua

Autenticação de e-mail não é uma tarefa que se conclui. Ela precisa de revisão sempre que:

• uma ferramenta nova passa a enviar e-mail em nome do domínio;
• um fornecedor é substituído — e o antigo precisa sair do SPF;
• a empresa troca de provedor de e-mail;
• os relatórios DMARC apontam origens desconhecidas.

Uma revisão trimestral do registro SPF e uma leitura mensal dos relatórios DMARC bastam para a maior parte das empresas. É pouco trabalho para um problema cujo custo é invisível e recorrente.

Conclusão

Mensagens legítimas que caem no spam quase sempre têm a mesma explicação: o domínio não consegue provar que elas são legítimas. SPF declara quem pode enviar, DKIM assina o que foi enviado, DMARC define o que fazer quando algo não confere — e mostra, em relatórios, o que você não sabia que estava acontecendo.

A ordem importa. Publique os três, comece o DMARC em modo de observação, corrija o que os relatórios apontarem e só então endureça a política. E lembre que autenticação prova identidade, não reputação: o comportamento de envio continua sendo determinante.

Se você não sabe dizer se o domínio da sua empresa tem esses registros publicados hoje, esse é o ponto de partida — e a verificação leva menos de um minuto. Conheça as soluções de e-mail corporativo da TBF Host e avalie a estrutura de envio adequada ao seu volume.

Perguntas frequentes

Por que meus e-mails caem no spam mesmo sendo legítimos?

A causa mais frequente é a ausência ou o erro de configuração de SPF, DKIM e DMARC no DNS do domínio. Sem esses registros, o servidor de destino não consegue verificar que a mensagem veio mesmo de quem diz ter vindo, e trata o envio com desconfiança independentemente do conteúdo.

O que são SPF, DKIM e DMARC?

São três registros publicados no DNS do domínio. O SPF lista quais servidores podem enviar mensagens em nome dele. O DKIM adiciona uma assinatura criptográfica que comprova a origem e a integridade da mensagem. O DMARC conecta os dois, define o que o destinatário deve fazer quando a verificação falha e permite receber relatórios.

Posso ter mais de um registro SPF no meu domínio?

Não. O domínio deve ter exatamente um registro SPF, com todas as origens autorizadas dentro dele. Registros duplicados invalidam a verificação. Esse erro é comum em empresas que foram contratando ferramentas ao longo do tempo e publicaram um registro para cada fornecedor.

O que é alinhamento no DMARC?

É a exigência de que o domínio verificado por SPF ou DKIM corresponda ao domínio exibido no campo do remetente. Uma ferramenta de terceiros pode passar na verificação usando o domínio dela enquanto a mensagem exibe o seu: tecnicamente autenticada, mas não alinhada, e portanto reprovada no DMARC.

Qual política DMARC devo usar?

Comece com p=none, que apenas gera relatórios sem afetar a entrega. Depois de algumas semanas lendo os relatórios e corrigindo as origens legítimas que estiverem falhando, avance para p=quarantine e, por fim, p=reject. Publicar p=reject antes de mapear todas as origens bloqueia os próprios e-mails da empresa.

Configurar SPF, DKIM e DMARC garante que meus e-mails cheguem?

Não. Esses registros provam identidade, não qualidade. Um domínio autenticado que envia mensagens não solicitadas acumula reclamações e passa a ser filtrado da mesma forma. A entrega depende também da reputação construída pelo comportamento de envio ao longo do tempo.

Meu provedor de e-mail configura esses registros automaticamente?

Em geral não. O provedor fornece os valores a serem publicados, mas os registros ficam no DNS do domínio e alguém precisa inseri-los. É por isso que empresas que já pagam por e-mail corporativo continuam tendo mensagens classificadas como spam.

Devo separar e-mails de marketing dos e-mails operacionais?

Sim, quando há volume relevante. Uma campanha com alta taxa de reclamação prejudica a reputação usada também pelas mensagens operacionais, como confirmações e redefinições de senha, que são justamente as que não podem falhar. A separação costuma ser feita por subdomínio de envio.