E-mail Corporativo Caindo no Spam: SPF, DKIM e DMARC

Por que o e-mail legítimo da empresa cai no spam e como SPF, DKIM e DMARC corrigem a entrega, com diagnóstico pelo cabeçalho e implantação segura em etapas.

Quando o e-mail legítimo da empresa começa a cair na caixa de spam do cliente, o problema quase nunca é o texto da mensagem. Na maior parte dos casos, o provedor de quem recebe não consegue confirmar que aquele e-mail saiu de fato do seu domínio — e, na dúvida, desconfia.

Essa confirmação é feita por três registros publicados no DNS do domínio: SPF, DKIM e DMARC. Eles não são opcionais para quem depende de e-mail para vender, cobrar e atender. Este guia explica o que cada um faz, como descobrir qual está falhando e em que ordem corrigir sem bloquear mensagens legítimas no caminho.

Resumo para gestores

E-mail corporativo caindo no spam costuma ser um problema de autenticação do domínio, não de conteúdo. SPF diz quais servidores podem enviar em nome do domínio, DKIM assina a mensagem e DMARC diz ao destinatário o que fazer quando as duas verificações falham.

O caso mais comum é um sistema (site, ERP, emissor de nota, ferramenta de marketing) enviando e-mails sem estar autorizado no SPF.
DKIM desativado no Microsoft 365 ou no Google Workspace é outra causa frequente.
Domínio sem DMARC perde credibilidade junto aos grandes provedores.
A correção é feita no DNS e no painel do serviço de e-mail; não exige trocar de provedor.
DMARC deve ser implantado em etapas, começando por monitoramento.

Spam ou e-mail fora do ar? Primeiro, confirme o sintoma

Este artigo trata de entregabilidade: o e-mail sai, chega ao destino, mas é classificado como spam, vai para a quarentena ou é recusado pelo servidor de quem recebe. É diferente de um e-mail que não funciona — caixa que não abre, envio que trava, senha que expira. Para esse outro cenário, o caminho é o guia sobre e-mail corporativo caindo e configuração profissional.

Sintoma	Provável natureza	Onde investigar
Cliente diz que a mensagem estava no spam	Autenticação ou reputação	SPF, DKIM, DMARC e cabeçalhos
Mensagem volta com erro citando SPF, DKIM ou DMARC	Autenticação	Registros DNS do domínio
Só e-mails do site ou do sistema vão para o spam	Remetente não autorizado	SPF e DKIM do serviço que envia
Nenhum e-mail sai ou a caixa não abre	Disponibilidade ou configuração da conta	Provedor, licença, senha, cliente de e-mail
Mensagens somem depois de um login estranho	Possível conta comprometida	Regras de caixa de entrada e logs de acesso

Se o último cenário parece familiar, trate como incidente de segurança antes de mexer no DNS. O roteiro está em empresa sofreu ataque hacker: o que fazer.

O que são SPF, DKIM e DMARC

SPF: quem pode enviar em nome do domínio

O SPF (Sender Policy Framework) é um registro TXT no DNS que lista os servidores autorizados a enviar e-mails usando o seu domínio. Quando uma mensagem chega, o servidor de destino consulta essa lista e verifica se o servidor que entregou o e-mail está nela.

Um SPF típico de quem usa Microsoft 365 contém include:spf.protection.outlook.com; quem usa Google Workspace usa include:_spf.google.com. Cada serviço adicional que envia e-mail pelo domínio — o formulário do site, o emissor de boletos, a plataforma de newsletter — precisa ser incluído.

Atenção ao limite de consultas. A especificação do SPF limita a 10 o número de consultas DNS feitas durante a verificação. Cada include conta. Um SPF que acumula serviços ao longo dos anos pode ultrapassar esse limite e passar a falhar para todas as mensagens.

DKIM: a assinatura da mensagem

O DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada e-mail enviado. A chave pública fica publicada no DNS; o destinatário usa essa chave para confirmar que a mensagem não foi alterada no caminho e que foi assinada pelo domínio.

No Microsoft 365 e no Google Workspace, o DKIM do domínio próprio precisa ser ativado pelo administrador. Sem isso, as mensagens podem até sair assinadas com o domínio técnico do provedor, mas não com o seu, o que enfraquece o alinhamento exigido pelo DMARC.

DMARC: a política e os relatórios

O DMARC (Domain-based Message Authentication, Reporting and Conformance) amarra os dois anteriores. Ele exige que pelo menos um deles passe e esteja alinhado com o domínio que aparece no campo "De:" — aquele que o destinatário vê. Também informa o que fazer quando a verificação falha:

p=none: apenas monitorar, sem interferir na entrega.
p=quarantine: tratar como suspeito (normalmente, enviar para spam).
p=reject: recusar a mensagem.

Além da política, o DMARC permite receber relatórios agregados (rua) mostrando quem está enviando e-mails com o seu domínio e se essas mensagens passam ou falham. É esse relatório que revela o sistema esquecido que ninguém incluiu no SPF.

Por que os provedores ficaram mais rigorosos

Desde fevereiro de 2024, Google e Yahoo passaram a exigir autenticação de quem envia para seus usuários, com requisitos mais fortes para remetentes de grande volume (SPF, DKIM e DMARC, entre outros). A Microsoft anunciou exigências semelhantes para remetentes de alto volume que entregam em contas Outlook.com a partir de 2025.

Mesmo que a sua empresa não envie milhares de mensagens por dia, esse movimento mudou o padrão de confiança: domínios sem autenticação completa tendem a ser tratados com mais desconfiança. As regras oficiais estão listadas nas fontes ao fim do artigo.

Como descobrir o que está falhando

O caminho mais confiável é ler o cabeçalho completo de uma mensagem que chegou no spam. Peça ao destinatário para encaminhar o e-mail como anexo ou envie um teste para uma conta Gmail ou Outlook.com sob seu controle.

No Gmail, a opção é "Mostrar original"; no Outlook, "Exibir detalhes da mensagem". Procure a linha Authentication-Results. Ela traz algo como:

spf=pass · dkim=pass · dmarc=pass

Qualquer fail, softfail, none ou permerror aponta onde agir:

Resultado	O que significa	Próximo passo
spf=fail ou softfail	Servidor de envio não está autorizado	Incluir o serviço correto no SPF
spf=permerror	Registro SPF inválido ou acima de 10 consultas	Revisar sintaxe e reduzir includes
dkim=none	Mensagem sem assinatura do domínio	Ativar DKIM no provedor ou no sistema que envia
dkim=fail	Assinatura não confere	Conferir a chave publicada e alterações no caminho
dmarc=fail	Nenhuma verificação passou alinhada ao domínio do "De:"	Corrigir SPF/DKIM do remetente real
dmarc=none	Domínio sem política DMARC	Publicar DMARC em modo monitoramento

As causas mais comuns em empresas

Sistemas que enviam "em nome" da empresa

O e-mail do Outlook pode estar perfeito e, mesmo assim, as mensagens do formulário do site, do ERP, do sistema de cobrança ou da ferramenta de marketing caírem no spam. Cada um desses serviços envia por servidores próprios. Se não estiverem no SPF e não assinarem com DKIM do seu domínio, falham no DMARC.

Em escritórios, isso aparece em notificações de sistemas jurídicos ou contábeis; em clínicas, em lembretes de consulta; no comércio, em confirmações de pedido. Muitas vezes, o problema só é notado quando um cliente importante reclama.

Migração de e-mail sem revisão do DNS

Trocar de provedor e esquecer o SPF antigo — ou manter os dois sem critério — é uma causa clássica. Toda migração de e-mails corporativos deve terminar com revisão de MX, SPF, DKIM e DMARC.

Mais de um registro SPF

O domínio só pode ter um registro SPF. Dois registros v=spf1 fazem a verificação falhar. Isso acontece quando cada fornecedor publica o seu sem olhar o que já existe.

Envio em massa pela caixa do usuário

Disparar comunicados para centenas de contatos pela conta pessoal do Microsoft 365 ou do Google Workspace prejudica a reputação e pode bater em limites de envio. Comunicação em massa deve sair por uma plataforma própria, autenticada no domínio.

Conta comprometida enviando spam

Se uma conta da empresa foi invadida e usada para enviar golpes, a reputação do domínio cai e mensagens legítimas passam a ser filtradas. Nesse caso, corrigir o DNS não resolve: é preciso conter a conta, revisar regras de encaminhamento e ativar MFA em todas as contas.

Conteúdo e links

Conteúdo influencia menos do que a autenticação, mas conta: links encurtados, anexos executáveis, imagens sem texto e assuntos alarmistas aumentam o risco de filtragem. Também ajuda que a assinatura e o site citados no e-mail estejam no mesmo domínio do remetente.

Seus clientes estão encontrando seus e-mails no spam? A Suporte de TI - Resolve Tecnologias revisa SPF, DKIM, DMARC e os sistemas que enviam em nome do seu domínio, com atendimento remoto e presencial no Rio de Janeiro. Fale com a empresa Suporte de TI - Resolve Tecnologias.

Como corrigir no Microsoft 365

Conferir se o SPF inclui spf.protection.outlook.com e todos os outros serviços que enviam pelo domínio
Ativar o DKIM do domínio próprio no portal do Microsoft Defender, publicando os dois registros CNAME indicados
Publicar o registro DMARC no DNS, começando por p=none com endereço para relatórios
Revisar conectores e serviços que fazem relay de impressoras, sistemas ou scanners
Verificar se alguma conta aparece bloqueada para envio por suspeita de spam

A administração completa da plataforma, incluindo segurança e migração, está em Microsoft 365 para empresas.

Como corrigir no Google Workspace

Conferir se o SPF inclui _spf.google.com e os demais serviços que enviam pelo domínio
Gerar a chave DKIM no Admin Console (Gmail → Autenticar e-mail), publicar o TXT e iniciar a autenticação
Publicar o DMARC em modo monitoramento
Revisar rotas de SMTP relay usadas por sistemas internos
Acompanhar o Postmaster Tools do Google quando o volume de envio justificar

Implantação, domínio e migração ficam detalhados em Google Workspace para empresas.

DMARC em etapas: como endurecer sem bloquear e-mail legítimo

Publicar p=reject no primeiro dia é a forma mais rápida de fazer a nota fiscal, o boleto ou o formulário do site pararem de chegar. O caminho seguro é gradual:

1. Monitorar (p=none). Publicar o DMARC com relatórios e observar por algumas semanas quem envia pelo domínio.

2. Corrigir. Incluir no SPF e configurar DKIM em cada serviço legítimo encontrado. Descartar o que não deveria estar enviando.

3. Quarentena (p=quarantine). Quando os envios legítimos passarem de forma consistente, endurecer a política, se necessário com aplicação parcial (pct).

4. Rejeição (p=reject). Com o ambiente estável, recusar o que falhar. Isso também dificulta que criminosos usem o seu domínio em golpes.

Dica Suporte de TI - Resolve Tecnologias. Antes de mudar a política, faça uma lista de todos os sistemas que enviam e-mail em nome da empresa e de quem é responsável por cada um. Essa lista resolve metade do problema e evita surpresas quando o DMARC endurece.

DMARC também protege contra golpes com o seu domínio

Um efeito menos lembrado: sem DMARC em modo de aplicação, qualquer pessoa pode enviar uma mensagem com o seu domínio no campo "De:" e ela tem mais chance de chegar. É a base de golpes de boleto falso e de falsa cobrança em nome de fornecedores. Uma política quarantine ou reject bem implantada reduz esse abuso — e complementa a orientação da equipe contra phishing corporativo.

Checklist de entregabilidade

Um único registro SPF, válido e com até 10 consultas DNS
Todos os serviços que enviam pelo domínio listados no SPF
DKIM ativo no provedor principal e nos sistemas que permitem assinatura própria
DMARC publicado, com relatórios sendo lidos
Política DMARC evoluindo de none para quarantine ou reject
Envios em massa feitos por plataforma própria, autenticada
MFA ativo em todas as contas de e-mail
Revisão de DNS após toda troca de provedor, site ou sistema
Teste de cabeçalho após cada mudança

Precisa de ajuda para autenticar o domínio da sua empresa? A Suporte de TI - Resolve Tecnologias configura e acompanha o e-mail corporativo dentro do suporte de TI para empresas. Solicitar revisão.

Perguntas frequentes

Por que o e-mail da minha empresa está indo para spam?

Na maioria dos casos, porque o provedor de destino não consegue confirmar que a mensagem saiu de um servidor autorizado pelo seu domínio. SPF incompleto, DKIM desativado e ausência de DMARC são as causas mais comuns. Conta comprometida e envio em massa pela caixa do usuário também derrubam a reputação.

O que é SPF em termos simples?

SPF é uma lista, publicada no DNS do domínio, com os servidores autorizados a enviar e-mails em nome da empresa. Quando uma mensagem chega, o destinatário compara o servidor que entregou o e-mail com essa lista. Se o servidor não estiver nela, a verificação falha e a mensagem perde confiança.

O que é DKIM?

DKIM é uma assinatura digital adicionada a cada e-mail enviado. A chave pública fica no DNS e permite ao destinatário verificar que a mensagem foi assinada pelo seu domínio e não foi alterada no caminho. No Microsoft 365 e no Google Workspace, o DKIM do domínio próprio precisa ser ativado.

O que é DMARC?

DMARC é a política que diz ao destinatário o que fazer quando SPF e DKIM falham: apenas monitorar, mandar para spam ou recusar. Ele exige que a verificação esteja alinhada ao domínio exibido no "De:". Também gera relatórios que mostram quem está enviando e-mails com o seu domínio.

Preciso dos três registros?

Sim. Cada um cobre uma parte do problema: SPF autoriza servidores, DKIM assina a mensagem e DMARC aplica a política e gera relatórios. Os grandes provedores passaram a exigir autenticação completa de remetentes de alto volume e tratam com mais desconfiança domínios que não publicam os três registros.

Como sei se o meu domínio tem SPF, DKIM e DMARC?

O jeito mais prático é enviar um e-mail para uma conta Gmail ou Outlook.com e abrir o cabeçalho completo. A linha Authentication-Results mostra se SPF, DKIM e DMARC passaram. Também é possível consultar os registros TXT do domínio com ferramentas de DNS ou pedir a revisão ao suporte de TI.

Posso ter dois registros SPF?

Não. O domínio deve ter um único registro SPF. Quando existem dois registros iniciados por v=spf1, a verificação retorna erro e pode falhar para todas as mensagens. A solução é juntar os serviços em um só registro, respeitando o limite de 10 consultas DNS.

O que acontece se o SPF passar de 10 consultas?

A verificação retorna erro permanente (permerror), e o destinatário pode tratar as mensagens como não autenticadas. Isso ocorre quando muitos serviços são incluídos ao longo do tempo. A correção envolve remover serviços que já não enviam, consolidar includes e avaliar se algum sistema pode assinar com DKIM.

Por que só os e-mails do site ou do sistema vão para spam?

Porque esses serviços enviam por servidores próprios, diferentes do Microsoft 365 ou do Google Workspace. Se não estiverem autorizados no SPF nem assinarem com DKIM do seu domínio, falham no DMARC. É preciso configurar cada sistema, ou fazê-lo enviar pelo provedor principal com autenticação.

Posso ativar DMARC com p=reject direto?

Não é recomendado. Começar com rejeição pode bloquear boletos, notas fiscais e formulários enviados por sistemas ainda não configurados. O caminho seguro é publicar p=none, ler os relatórios, corrigir cada remetente legítimo e só então passar para quarantine e, depois, reject.

Quanto tempo leva para a correção fazer efeito?

As mudanças de DNS costumam propagar em minutos ou poucas horas, conforme o TTL configurado. A reputação do domínio, porém, melhora de forma gradual, à medida que os provedores passam a ver mensagens autenticadas. Por isso, além de corrigir os registros, é importante evitar envios em massa e acompanhar os resultados.

Trocar de provedor de e-mail resolve o spam?

Normalmente não. Se o problema é autenticação, ele acompanha o domínio para qualquer provedor. Microsoft 365 e Google Workspace entregam bem quando SPF, DKIM e DMARC estão corretos. A troca só faz sentido por outros motivos, e deve terminar sempre com revisão completa do DNS.

Conteúdo da mensagem influencia?

Influencia, mas pesa menos do que a autenticação. Links encurtados, anexos executáveis, mensagens só com imagem e assuntos alarmistas aumentam o risco de filtragem. Manter assinatura, links e site no mesmo domínio do remetente e evitar envios em massa pela caixa do usuário ajudam.

Uma conta invadida pode prejudicar a entrega de todos?

Sim. Se uma conta for usada para enviar spam ou golpes, a reputação do domínio cai e mensagens legítimas de outros usuários passam a ser filtradas. É preciso conter a conta, trocar senhas, revogar sessões, revisar regras de encaminhamento e ativar MFA antes de tratar a entregabilidade.

DMARC protege contra golpes usando o meu domínio?

Ajuda bastante. Com política quarantine ou reject, mensagens que usam o seu domínio no "De:" sem passar na autenticação tendem a ser filtradas ou recusadas. Isso dificulta golpes de boleto falso e falsa cobrança em nome da empresa, embora não impeça domínios parecidos registrados por criminosos.

Quem deve ler os relatórios DMARC?

Alguém com conhecimento técnico de e-mail e DNS. Os relatórios agregados são arquivos XML enviados pelos provedores e costumam ser lidos com ferramentas que os resumem. O importante é que alguém acompanhe, identifique remetentes desconhecidos e decida o que autorizar ou bloquear.

A Suporte de TI - Resolve Tecnologias configura SPF, DKIM e DMARC?

Sim. Suporte de TI - Resolve Tecnologias revisa os registros do domínio, ativa o DKIM no Microsoft 365 ou no Google Workspace, identifica os sistemas que enviam em nome da empresa e conduz a implantação do DMARC em etapas, para empresas no Rio de Janeiro e na Região Metropolitana.

Isso faz parte do suporte mensal?

Pode fazer. Em contratos de suporte de TI, a revisão de DNS e de autenticação de e-mail entra na rotina, especialmente após trocas de sistema, site ou provedor. Também atendemos de forma pontual, quando o problema surge e precisa de diagnóstico rápido.

Conclusão

E-mail no spam raramente se resolve reescrevendo a mensagem. O caminho é provar, com SPF, DKIM e DMARC, que o seu domínio é quem diz ser — e manter essa prova correta sempre que entra um sistema novo, um site novo ou um provedor novo.

Comece pelo cabeçalho de uma mensagem que caiu no spam: ele mostra exatamente qual verificação falhou. A partir daí, a correção é técnica, previsível e, feita em etapas, não interrompe a comunicação da empresa.

Precisa resolver a entrega dos e-mails da sua empresa? A Suporte de TI - Resolve Tecnologias atua com Microsoft 365, Google Workspace e cibersegurança para empresas, com atendimento remoto e presencial no Rio de Janeiro. Fale conosco pelo WhatsApp (21) 99063-9244 ou pelo e-mail resolvetecnologias@resolvetecnologias.com.br.

Fontes oficiais

IETF — RFC 7208: Sender Policy Framework (SPF)
IETF — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
IETF — RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Google — Diretrizes para remetentes de e-mail
Microsoft Learn — Configurar o DKIM no Microsoft 365
Microsoft Learn — Configurar o DMARC no Microsoft 365