E-mail da empresa caindo em spam: SPF, DKIM e DMARC explicados sem enrolação

A cena se repete em empresa de todo tamanho. O cliente pede o orçamento, o vendedor manda, e três dias depois o cliente cobra o orçamento que nunca chegou. Ele chegou. Está na pasta de spam, ou foi descartado antes de chegar à caixa, sem aviso para ninguém.

A reação normal é mexer no que se enxerga: reescrever o assunto, tirar o anexo, cortar a palavra promoção, trocar a assinatura. Às vezes melhora um pouco, por acaso. O problema quase nunca está aí.

O problema é o seu domínio não estar provando que aquele e-mail é mesmo seu. Sem essa prova, Gmail, Outlook e os filtros corporativos tratam a mensagem como suspeita, e a decisão deles é tomada antes de alguém ler uma única palavra do texto.

Por que existe essa desconfiança toda

O protocolo que entrega e-mail no mundo é de 1982 e foi desenhado para uma internet onde todo mundo se conhecia. Nele, o campo de remetente é livre: qualquer servidor pode enviar uma mensagem dizendo que vem de qualquer endereço. É o equivalente a escrever o remetente que quiser no verso do envelope.

Foi isso que transformou o e-mail no principal canal de fraude corporativa. O golpe da falsa troca de conta bancária, que ainda hoje desvia pagamentos de empresas inteiras, se apoia nessa liberdade: o criminoso escreve como se fosse o fornecedor, com o domínio do fornecedor, e o financeiro paga.

A resposta da indústria não foi trocar o protocolo, porque isso seria impossível. Foi acrescentar três camadas de verificação por cima dele, apoiadas no DNS do domínio. São elas o SPF, o DKIM e o DMARC, e desde 2024 Gmail e Outlook passaram a exigir esse conjunto de quem envia volume, com endurecimento progressivo desde então.

SPF: quem tem autorização para enviar por mim

O SPF é uma lista, publicada no DNS do seu domínio, dizendo quais servidores podem enviar e-mail em nome dele. Quando a mensagem chega, o servidor de destino consulta essa lista e compara com o endereço de onde a mensagem realmente partiu. Se não estiver na lista, ponto negativo.

Na prática é um registro de texto parecido com este:

• Servidor de e-mail da empresa, que é de onde sai o e-mail do dia a dia.
• A ferramenta de e-mail marketing, se a newsletter sai com o domínio da empresa.
• O sistema que envia notificação automática, como o formulário do site, a loja virtual, o sistema de nota fiscal ou o ERP.

Dois erros derrubam o SPF de empresas que acham que ele está certo. O primeiro é ter mais de um registro SPF no domínio, o que invalida os dois: a regra permite apenas um, e todas as autorizações precisam caber dentro dele. O segundo é estourar o limite de dez consultas de DNS, que acontece quando se empilha include de várias plataformas. Passou de dez, o SPF falha inteiro.

Há ainda uma limitação de desenho que explica por que o SPF sozinho não basta: ele valida o caminho, não o conteúdo. Se a mensagem for reencaminhada, o caminho muda e o SPF quebra, mesmo sendo uma mensagem legítima.

DKIM: a assinatura que viaja com a mensagem

O DKIM resolve o que o SPF não resolve. Ele assina a mensagem com uma chave criptográfica no momento do envio e publica a chave pública correspondente no DNS. O destinatário refaz a conta e confirma duas coisas: que a mensagem saiu mesmo daquele domínio e que ninguém alterou o conteúdo no caminho.

Como a assinatura está dentro da mensagem, ela sobrevive ao reencaminhamento. É por isso que os dois trabalham juntos e nenhum substitui o outro: o SPF cuida do trajeto, o DKIM cuida do envelope lacrado.

O ponto de atenção aqui é operacional. Cada plataforma que envia pelo seu domínio precisa da própria chave DKIM publicada. Ligar o DKIM no servidor de e-mail e esquecer do sistema da loja virtual deixa metade dos envios sem assinatura, e essa metade costuma ser justamente a que mais importa, porque é a transacional.

DMARC: a política que amarra as duas coisas

Com SPF e DKIM publicados, ainda falta responder uma pergunta: o que o servidor de destino deve fazer quando a verificação falha? Sem resposta, cada provedor decide por conta, e a decisão costuma ser a mais conservadora possível.

O DMARC é o registro que dá essa resposta. Ele faz duas coisas ao mesmo tempo:

1. Define a política para mensagens que falham na verificação: nenhuma ação, quarentena ou rejeição.
2. Pede relatórios. Os provedores passam a enviar, para um endereço que você indica, um resumo diário de tudo que foi enviado usando o seu domínio, com resultado de cada verificação.

O segundo item é subestimado e é o mais útil dos dois. É o relatório DMARC que mostra, sem adivinhação, quais sistemas estão enviando com o seu domínio, quais estão passando e quais estão falhando. Muita empresa descobre ali um sistema antigo que ninguém lembrava que existia, ainda disparando e-mail em nome dela.

O caminho correto de implantação é gradual, e essa ordem não é opcional:

1. Publicar o DMARC em política none, que não bloqueia nada, e só coletar relatório por algumas semanas.
2. Corrigir tudo que aparecer falhando: sistema sem DKIM, remetente fora do SPF, plataforma esquecida.
3. Subir para quarantine, que manda o que falha para spam.
4. Só depois subir para reject, que descarta o que falha.

Publicar reject de imediato é o erro mais caro dessa área. Ele derruba silenciosamente os envios legítimos que ainda não estavam autenticados, e como o descarte acontece no servidor de destino, não há mensagem de erro na sua caixa avisando.

O que mais joga o e-mail para o spam

Autenticação resolve a maior parte dos casos, mas não todos. Vale conhecer os outros fatores, porque eles aparecem depois que o DMARC já está no lugar.

• Reputação do endereço de IP e do domínio. Hospedagem compartilhada barata coloca você no mesmo IP de quem dispara spam, e a reputação é do vizinho também.
• Domínio novo enviando volume alto de uma vez. Domínio sem histórico precisa de aquecimento gradual.
• Lista com endereço inválido. Taxa alta de erro permanente é sinal clássico de lista comprada, e derruba a reputação rápido.
• Ausência de link de descadastro em envio em massa. Quem quer sair e não consegue marca como spam, que é a pior denúncia possível.
• Enviar marketing pelo mesmo domínio do e-mail comercial sem separar por subdomínio. Uma campanha malsucedida contamina a reputação do endereço que fecha negócio.

Como testar o que está publicado hoje

Antes de mexer em qualquer coisa, vale medir. Três conferências resolvem o diagnóstico inicial:

1. Consultar os registros de DNS do domínio e verificar se existe SPF, se ele é único, e se há DMARC publicado.
2. Enviar um e-mail para uma conta do Gmail e abrir a opção de exibir original. Ali aparecem, em texto claro, os resultados de SPF, DKIM e DMARC daquela mensagem específica.
3. Repetir o teste a partir de cada sistema que envia: o webmail, o formulário do site, a loja virtual, o disparador de newsletter. Eles falham de formas diferentes, e o resultado de um não vale para o outro.

O terceiro passo é o que costuma revelar o problema real. O e-mail do vendedor passa, o pedido automático da loja não passa, e ninguém nunca tinha testado o segundo porque ele é lido por quem compra, não por quem trabalha na empresa.

Isso depende de ter domínio e e-mail próprios

Nada do que está acima é configurável em endereço de provedor gratuito. SPF, DKIM e DMARC são publicados no DNS do domínio, e quem não tem domínio próprio não tem onde publicá-los.

Esse é o custo escondido de rodar o comercial em um endereço genérico: além de não passar credibilidade, ele nunca vai autenticar como empresa, porque a autenticação pertence a quem controla o domínio. O raciocínio completo está em e-mail corporativo com domínio próprio, e a parte da titularidade, que é o que garante o acesso ao DNS, está em domínio próprio: titularidade e renovação.

Vale também conferir quem hoje tem acesso ao painel de DNS. É comum encontrar o domínio da empresa sob o cadastro de um ex-fornecedor, e nesse caso qualquer correção de autenticação depende de alguém de fora atender o telefone.

A rotina que mantém isso funcionando

Autenticação de e-mail não é projeto com fim. Ela se desarruma sozinha toda vez que a empresa contrata uma ferramenta nova que envia em nome dela.

• Toda ferramenta nova entra no SPF e ganha DKIM antes do primeiro disparo, não depois da primeira reclamação.
• Ferramenta descontinuada sai do SPF, para não gastar consulta de DNS nem deixar autorização aberta.
• Alguém lê o relatório DMARC, ainda que uma vez por mês. Ele é o único lugar onde aparece o envio que você não sabia que existia.
• Separe marketing de comercial por subdomínio quando o volume de campanha crescer.
• Depois de trocar de servidor ou de hospedagem, refaça o teste dos três registros. Migração costuma levar o DKIM embora.

O que fica

O e-mail que cai em spam quase nunca é um problema de redação. É o domínio não conseguir provar que aquele envio é legítimo, e essa prova é uma configuração de DNS, não um talento de escrita.

SPF diz quem pode enviar. DKIM assina o que foi enviado. DMARC decide o que fazer quando algo não bate e conta para você tudo que está acontecendo. Os três levam pouco tempo para configurar e mudam a taxa de entrega de forma imediata e mensurável.

Se o orçamento da sua empresa está sumindo no caminho, o lugar de olhar é o DNS. Fale com a NSWeb para auditar a autenticação do seu domínio e deixar o e-mail da empresa chegando onde precisa chegar.

Perguntas frequentes