SPF, DKIM e DMARC: Por Que Seu E-mail Cai no Spam e Como Resolver

Poucas coisas frustram mais do que enviar um e-mail profissional, com o seu domínio próprio, e descobrir que ele foi parar na caixa de spam do destinatário — ou pior, que sumiu no caminho e nunca chegou. Você fez tudo certo: criou o endereço no domínio da empresa, escreveu uma mensagem legítima, e ainda assim os provedores tratam o seu e-mail como suspeito. A causa quase nunca é o conteúdo. É a falta de autenticação.

Este guia explica, em linguagem de gente, os três mecanismos que decidem se um e-mail é aceito como legítimo ou tratado como spam: SPF, DKIM e DMARC. Eles funcionam por trás dos bastidores, morando no DNS do seu domínio, e são o que os provedores de e-mail consultam para responder à pergunta mais importante: "esta mensagem realmente veio de quem diz que veio?". Configurar os três corretamente é o que separa um domínio que chega à caixa de entrada de um que vive no spam.

Por que e-mails legítimos caem no spam#

A internet foi construída de um jeito que permite a qualquer servidor enviar um e-mail dizendo ser de qualquer domínio. Nada, no protocolo original, impede alguém de mandar uma mensagem se passando por contato@suaempresa.com.br. Foi assim que golpes de falsificação de remetente se espalharam.

Para se defender, os provedores de e-mail passaram a desconfiar de qualquer mensagem que não prove sua origem. Se o seu domínio não diz claramente quais servidores estão autorizados a enviar em seu nome, e não assina as mensagens de forma verificável, o provedor do destinatário fica sem como distinguir você de um golpista — e, na dúvida, joga para o spam ou recusa. Autenticar o e-mail é, no fundo, dar aos provedores as provas de que você é quem diz ser.

SPF: quem tem permissão de enviar#

O SPF (Sender Policy Framework) responde a uma pergunta simples: quais servidores estão autorizados a enviar e-mail em nome do seu domínio? Ele é publicado como um registro TXT no DNS, e lista as origens legítimas.

Quando um servidor recebe uma mensagem que diz ser do seu domínio, ele consulta esse registro e verifica: o servidor que está enviando está na lista de autorizados? Se estiver, o e-mail passa nesse teste. Se não estiver, é um sinal de que a mensagem pode ser falsificada.

Um registro SPF tem uma aparência mais ou menos assim, de forma genérica:

• v=spf1 include:_spf.provedor.com ~all

Onde include referencia os servidores do serviço que você usa para enviar, e o final define o que fazer com quem não está na lista. Alguns cuidados importantes com o SPF:

• Um único registro SPF por domínio. Ter dois registros SPF separados quebra a validação. Todas as origens autorizadas devem caber em um só registro.
• Limite de consultas. O SPF tem um teto de consultas encadeadas (dez) que ele pode fazer. Encadear serviços demais estoura esse limite e faz a validação falhar. Manter o registro enxuto evita esse problema.

O SPF sozinho tem uma limitação: ele valida o servidor de envio, mas não protege o conteúdo da mensagem nem sobrevive bem a encaminhamentos. Por isso ele é só a primeira das três camadas.

DKIM: a assinatura que prova a integridade#

O DKIM (DomainKeys Identified Mail) resolve o que o SPF não cobre: ele assina criptograficamente cada mensagem, provando que ela veio mesmo do seu domínio e que não foi alterada no caminho.

Funciona com um par de chaves. O servidor de envio assina a mensagem com uma chave privada, que só ele conhece. No DNS do seu domínio, você publica a chave pública correspondente, num registro TXT. Quando a mensagem chega, o provedor do destinatário pega a chave pública no seu DNS e verifica a assinatura. Se ela bate, duas coisas ficam provadas:

• Autenticidade. A mensagem foi assinada por quem tem a chave privada do seu domínio.
• Integridade. O conteúdo não foi adulterado entre o envio e a chegada.

Ao contrário do SPF, o DKIM sobrevive a encaminhamentos, porque a assinatura viaja junto com a mensagem. Ele é a camada que garante que o e-mail é genuíno e íntegro, não apenas que saiu de um servidor autorizado.

DMARC: a política que amarra tudo#

SPF e DKIM, sozinhos, verificam coisas — mas não dizem ao provedor o que fazer quando a verificação falha, nem dão a você qualquer visibilidade sobre o que está acontecendo. É aí que entra o DMARC (Domain-based Message Authentication, Reporting and Conformance).

O DMARC, também publicado como registro TXT no DNS, faz três coisas:

• Define uma política. Ele diz ao provedor o que fazer com mensagens que falham na autenticação. As opções são:
• none — apenas monitora, sem agir. É o ponto de partida seguro.
• quarantine — manda as mensagens suspeitas para o spam.
• reject — recusa de vez as mensagens que falham.
• Exige alinhamento. O DMARC não aceita só que SPF ou DKIM passem: ele exige que o domínio verificado seja o mesmo que aparece como remetente para o destinatário. Esse alinhamento é o que fecha a porta para falsificações mais espertas.
• Envia relatórios. Ele pede aos provedores que enviem relatórios sobre as mensagens que dizem ser do seu domínio — quais passaram, quais falharam, de onde vieram. Isso dá visibilidade sobre uso legítimo e tentativas de abuso.

O DMARC é o maestro: ele depende de SPF e DKIM estarem configurados, define a consequência da falha e ainda te dá os olhos para acompanhar tudo.

Como implantar os três sem quebrar seu e-mail#

Ligar tudo de uma vez no modo mais rígido é um jeito de bloquear os seus próprios e-mails legítimos por engano. O caminho seguro é gradual.

• Configure o SPF primeiro. Liste todas as origens que enviam em seu nome — o serviço de e-mail principal, ferramentas de disparo, sistemas que mandam notificações. Deixe o registro completo e único.
• Ative o DKIM. Habilite a assinatura no seu serviço de envio e publique a chave pública no DNS. Confirme que as mensagens estão saindo assinadas.
• Comece o DMARC em modo de monitoramento. Publique a política como none e leia os relatórios que chegarem. Eles revelam quais origens legítimas você esqueceu de autorizar — sem bloquear nada ainda.
• Aperte a política aos poucos. Quando os relatórios mostrarem que todo o e-mail legítimo está passando, avance para quarantine e, por fim, reject. Cada passo fecha mais a porta para falsificações, com a segurança de que você já validou o tráfego legítimo.

Essa progressão — monitorar, ajustar, apertar — é o que impede o tiro no próprio pé.

Um detalhe extra: PTR e reputação#

Além dos três protagonistas, dois fatores rondam a entregabilidade e vale conhecer.

• PTR (DNS reverso). É o registro que faz o caminho inverso: dado um IP, ele diz a qual nome pertence. Servidores de envio confiáveis costumam ter um PTR configurado e coerente. Sua ausência é um sinal negativo para alguns provedores. Em geral, quem cuida disso é o serviço de envio que você usa.
• Reputação de IP e de domínio. Provedores mantêm um histórico do comportamento de cada IP e domínio. Enviar para listas ruins, gerar muitas reclamações de spam ou disparar volumes suspeitos derruba essa reputação, e nem a autenticação perfeita salva um domínio malvisto. Autenticar é necessário, mas manter boas práticas de envio é o que sustenta a reputação no tempo.

Autenticação e reputação trabalham juntas: uma prova quem você é, a outra registra como você se comporta.

Por que "ter SSL" não tem nada a ver com isso#

Uma confusão comum: a pessoa instala um certificado SSL no site, vê o cadeado no navegador e presume que o e-mail também está "seguro" e vai chegar. São coisas completamente diferentes. O SSL protege a conexão entre o visitante e o seu site; ele não diz absolutamente nada sobre quem está autorizado a enviar e-mail em nome do seu domínio. A entregabilidade de e-mail se resolve no DNS, com SPF, DKIM e DMARC — não com o certificado do site.

Erros comuns que mantêm você no spam#

Mesmo depois de ouvir falar em SPF, DKIM e DMARC, muita gente configura de um jeito que não funciona. Alguns tropeços se repetem tanto que vale nomeá-los.

• Registro SPF duplicado. Publicar dois registros SPF separados, muitas vezes ao adicionar um serviço novo sem mexer no antigo, invalida a verificação. Precisa ser um só registro, com todas as origens dentro.
• Estourar o limite de consultas. Encadear muitos include de serviços diferentes ultrapassa o teto de dez consultas do SPF e faz a validação falhar em silêncio.
• Esquecer uma origem de envio. Ferramentas de newsletter, sistemas que mandam notificações automáticas, o financeiro que dispara boletos — cada uma envia em seu nome e precisa estar autorizada, ou aqueles e-mails específicos vão para o spam.
• Deixar o DMARC em monitoramento para sempre. A política none só observa; ela não protege contra falsificação. Ficar nela indefinidamente é ter os relatórios sem colher o benefício de bloquear os abusos.
• Configurar e nunca verificar. Publicar os registros e presumir que funcionaram, sem testar, é como trancar a porta sem checar se a chave girou.

Evitar esses erros costuma resolver os casos em que "eu configurei tudo e mesmo assim cai no spam".

Por que isso melhora até a sua reputação#

Há um benefício que vai além de escapar do spam. Quando o seu domínio está bem autenticado, você dificulta que golpistas se passem por você — mandando mensagens fraudulentas em nome da sua empresa para os seus próprios clientes. A falsificação de remetente é uma das bases de golpes de phishing, e um domínio com DMARC em política rígida fecha essa porta. Ou seja: configurar SPF, DKIM e DMARC não protege só a sua entregabilidade; protege a sua marca e as pessoas que confiam nela. É segurança para os dois lados da conversa.

Como testar e um checklist final#

Depois de configurar, é essencial verificar se tudo está funcionando antes de confiar. Enviar uma mensagem de teste e checar se ela passou nas três validações no cabeçalho, e acompanhar os relatórios do DMARC, mostra o estado real da sua autenticação.

Em resumo, para o seu e-mail parar de cair no spam:

• Publique um SPF único e completo, com todas as origens legítimas, respeitando o limite de consultas.
• Ative o DKIM e confirme que as mensagens saem assinadas.
• Implante o DMARC começando em monitoramento e apertando a política aos poucos, lendo os relatórios.
• Garanta que o PTR do seu servidor de envio está correto e cuide da reputação com boas práticas.
• Lembre que SSL do site não tem relação com entregabilidade de e-mail.

Configurados juntos, esses mecanismos dão aos provedores exatamente as provas que eles pedem para confiar no seu domínio. O e-mail deixa de ser um suspeito automático e passa a chegar onde deveria desde o começo: na caixa de entrada.