SPF, DKIM e DMARC: por que o e-mail vai para o spam e como resolver

05/10/2026 · 9 min de leitura

Profissional de TI analisando métricas de rede e configurações de domínio em um monitor de computador em escritório iluminado

Enviar uma proposta comercial, um boleto ou a resposta para uma dúvida de cliente e descobrir que a mensagem foi parar na pasta de lixo eletrônico é um dos problemas operacionais mais frustrantes para quem gerencia um negócio. Quando isso acontece com frequência, a empresa perde vendas, atrasa recebimentos e passa uma imagem amadora.

A causa desse problema raramente é o texto do e-mail em si. Na maioria das vezes, o motivo está na infraestrutura técnica do domínio: os servidores que recebem a sua mensagem não conseguem confirmar com segurança que quem enviou foi realmente a sua empresa. Sem essa comprovação, os filtros de segurança assumem uma postura defensiva e jogam o e-mail no spam ou simplesmente rejeitam o recebimento.

Para resolver isso de forma definitiva, existem três protocolos fundamentais: SPF, DKIM e DMARC. Compreender como eles trabalham em conjunto é o primeiro passo para proteger a reputação do seu domínio.

A conferência de identidade em três camadas

Pense no tráfego de e-mails como um serviço de entrega de encomendas físicas. Qualquer pessoa mal-intencionada pode pegar um envelope em branco, escrever o nome da sua empresa no campo do remetente e postar a carta. Para impedir que fraudadores se passem por você, a internet utiliza três camadas de autenticação que atuam como uma conferência rigorosa de crachá e assinatura.

SPF: a lista de quem tem autorização para enviar

O SPF (Sender Policy Framework, ou Estrutura de Diretiva de Remetente) funciona como uma lista de funcionários autorizados na portaria. Quando o seu domínio envia uma mensagem, o servidor destinatário consulta o DNS (Domain Name System, o sistema que traduz nomes de sites em endereços de rede) do seu domínio para verificar quais servidores e serviços de computação têm permissão oficial para despachar e-mails em seu nome.

Se a sua empresa usa um provedor de e-mail corporativo e um sistema de emissão de notas fiscais, ambos precisam estar declarados nessa lista. Se um e-mail chegar de um endereço IP que não consta no seu SPF, o destinatário recebe um sinal de alerta de que aquela mensagem pode ser falsa.

DKIM: o lacre com assinatura digital

Se o SPF confere a origem da entrega, o DKIM (DomainKeys Identified Mail, ou Correio Identificado por Chaves de Domínio) atua como um lacre de segurança inviolável assinado por cartório. Quando o e-mail sai do seu servidor, o sistema anexa ao cabeçalho da mensagem uma assinatura criptográfica exclusiva.

Ao receber a mensagem, o servidor de destino busca a chave pública no seu DNS para checar se a assinatura confere. Isso garante duas coisas: a mensagem partiu de um sistema que tem a sua chave privada e o conteúdo do e-mail não sofreu nenhuma alteração no caminho entre a saída e a entrega.

DMARC: a ordem expressa sobre o que fazer se algo falhar

Mesmo com SPF e DKIM, faltava uma regra para orientar o destinatário sobre o que fazer caso o remetente não passe no teste. É aqui que entra o DMARC (Domain-based Message Authentication, Reporting, and Conformance, ou Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio), formalizado na norma técnica RFC 9989 (publicada em 2026, Proposed Standard, que atualizou e tornou obsoletas as antigas RFC 7489 e RFC 9091).

O DMARC permite que você publique uma instrução clara para o mundo: se alguém enviar um e-mail com o endereço da minha empresa e não passar na validação de SPF ou DKIM, o que você deve fazer? As opções são apenas monitorar sem interferir, isolar a mensagem na quarentena (spam) ou rejeitar o recebimento por completo. Além disso, o DMARC solicita relatórios diários de volta para que você saiba quem está tentando enviar mensagens usando o seu nome.

O que os grandes provedores exigem hoje

Antigamente, manter esses registros era opcional para a maioria das empresas. Hoje, os grandes serviços de correio eletrônico tratam a autenticação como pré-requisito técnico.

O Google estabeleceu regras claras para quem envia para contas pessoais do Gmail, em vigor desde 1 de fevereiro de 2024. Todos os remetentes precisam ter SPF ou DKIM configurados, registros de DNS direto e reverso válidos, conexão segura por TLS (Transport Layer Security, tecnologia que criptografa o tráfego) e manter uma taxa de reclamações de spam abaixo de 0,3% na ferramenta Postmaster Tools.

Para quem envia grandes volumes (acima de 5.000 mensagens por dia para contas Gmail), a exigência sobe de patamar: é obrigatório ter SPF, DKIM e DMARC ativos, com o domínio exibido no cabeçalho do remetente (campo From) alinhado ao domínio autenticado pelo SPF ou pelo DKIM, além de oferecer cancelamento de inscrição com um único clique em mensagens comerciais. Nessa regra de volume, o Google aceita que a política de DMARC seja inicialmente de apenas monitoramento.

O Yahoo também adota critérios rígidos: exige SPF e DKIM para remetentes em massa, registro DMARC válido com resultado satisfatório (no mínimo em política de monitoramento) e atendimento aos pedidos de cancelamento de cadastro em até 2 dias. As diretrizes públicas do Yahoo não fixam um volume específico para classificar um remetente em massa.

A Microsoft, em seus serviços de e-mail voltados ao consumidor (como contas Outlook.com), rejeita mensagens com o código de erro específico 550 5.7.515 para domínios que enviam 5.000 ou mais mensagens sem cumprir os requisitos técnicos: ter SPF e DKIM publicados e aprovados na entrega, manter registro DMARC publicado e garantir alinhamento do SPF ou do DKIM com o domínio do remetente.

Mesmo que uma pequena ou média empresa comum envie volumes muito menores no dia a dia, esses limites mostram a direção adotada pela indústria. Adotar esses três padrões é uma boa prática elementar para evitar que mensagens legítimas sejam barradas preventivamente pelos filtros automáticos.

Roteiro de implantação em ordem segura

Configurar a autenticação de forma precipitada pode fazer a sua própria equipe parar de receber ou enviar mensagens. A forma correta e sem sustos exige uma sequência bem definida.

1. Mapear todas as fontes de envio

Antes de mexer em qualquer configuração, liste tudo o que dispara e-mails com a extensão do seu domínio. Isso inclui:

  • A ferramenta principal de trabalho da equipe (como o serviço de caixas postais corporativas);
  • O sistema de gestão interna, CRM ou faturamento que emite faturas e notificações automáticas;
  • O software de disparo de informativos e comunicações de marketing;
  • Ferramentas de suporte ou atendimento com formulários de contato.

2. Configurar o SPF de forma unificada

O SPF é adicionado como uma linha de texto (registro do tipo TXT) na zona de DNS do domínio. Cada domínio ou subdomínio precisa do seu próprio apontamento, e as alterações podem levar até 48 horas para se propagarem completamente pela rede mundial.

Se a sua empresa utiliza apenas o Google Workspace como fonte de envio, a linha oficial definida pela documentação é:

v=spf1 include:_spf.google.com ~all

Se a sua empresa usa mais de um serviço, todos eles devem constar juntos na mesma linha, usando múltiplos modificadores include:. O mecanismo ~all ao final indica um resultado moderado (softfail) para envios que não venham dos servidores listados, avisando o destinatário para receber com atenção em vez de descartar de imediato.

3. Gerar e publicar as chaves DKIM

O DKIM é ativado gerando um par de chaves criptográficas no painel do seu fornecedor de e-mail corporativo. O provedor fornece uma chave pública que deve ser inserida como um registro TXT no DNS, geralmente sob o endereço seletor._domainkey.seudominio.com.br.

O Google recomenda a criação de chaves de 2048 bits quando a zona de DNS da empresa permitir esse tamanho, aceitando chaves de 1024 bits apenas em sistemas legados que não suportem o tamanho maior. Após publicar o registro, pode levar até 48 horas para que o serviço valide a chave e inicie a assinatura de cada mensagem de saída.

Se você usa plataformas secundárias para envio de notas ou boletins, cada uma delas deve gerar o seu próprio seletor DKIM exclusivo no DNS.

4. Iniciar o DMARC no modo neutro

Depois de ativar o SPF e o DKIM e aguardar o período de propagação de 48 horas, chega o momento de ativar o DMARC. O maior erro técnico é tentar ativar o bloqueio logo no primeiro dia.

O início seguro deve ser sempre com a política p=none. Nessa modalidade, o DMARC não pede o descarte nem o isolamento de nenhuma mensagem que falhar. Ele apenas pede aos servidores de destino que processem a entrega normalmente e enviem relatórios de diagnóstico para uma caixa postal que você definir na tag rua.

O registro é publicado como um TXT no endereço _dmarc.seudominio.com.br, com um conteúdo básico semelhante a:

v=DMARC1; p=none; rua=mailto:relatorios@seudominio.com.br

Depois de algumas semanas analisando esses relatórios e garantindo que todos os envios legítimos da empresa estão passando sem erros de alinhamento, aí sim é prudente alterar gradualmente o parâmetro p= para quarantine (encaminhar suspeitos ao spam) e, em um estágio avançado de maturidade, para reject (recusa total de falsificações).

Erros comuns que você deve evitar

A criação desses registros segue normas técnicas rígidas. Dois erros frequentes derrubam a entrega de e-mails em pequenas empresas:

  • Publicar mais de um registro SPF: A norma técnica RFC 7208 proíbe terminantemente a existência de mais de um registro SPF para o mesmo domínio. Ter duas linhas separadas iniciadas com v=spf1 faz a validação ser desconsiderada pelo servidor de destino. Se você tem três serviços autorizados, todos devem ficar agrupados em uma única linha.
  • Passar do limite de 10 consultas DNS: A mesma RFC 7208 determina que a avaliação do SPF só pode disparar no máximo 10 consultas de resolução de nomes na internet. Ao acumular muitos comandos include, a, mx ou ptr, você atinge essa trava e o resultado da verificação passa a ser permerror (erro permanente), prejudicando a pontuação do domínio.

Próximos passos práticos

Embora manter esses protocolos alinhados seja indispensável, nenhum ajuste de configuração garante de forma mágica que 100% dos seus e-mails cairão sempre na caixa de entrada principal, já que os filtros avaliam também o engajamento dos leitores e a relevância das mensagens enviadas.

O passo mais imediato para a sua empresa é abrir o gerenciador de DNS do domínio e auditar o que já existe lá hoje. Verifique se existe apenas uma linha de SPF, certifique-se de que o DKIM já está gerado e assinado, e adicione uma política inicial de DMARC em modo de observação. Caso a gestão de DNS envolva configurações sensíveis com o seu site ou outros sistemas da empresa, vale alinhar essa conferência técnica com a sua equipe de suporte ou consultoria de TI.