DNS, SPF, DKIM, DMARC: Por Que Seu E-mail Vai Pro Spam (e Como Atacantes Se Passam por Você) Tudo que você precisa saber sobre os três protocolos que separam o seu e-mail legítimo da caixa de spam — e que separam a sua marca de ser usada por golpistas. Introdução Você manda um e-mail importante pro cliente.
DNS, SPF, DKIM, DMARC: Por Que Seu E-mail Vai Pro Spam (e Como Atacantes Se Passam por Você) Tudo que você precisa saber sobre os três protocolos que separam o seu e-mail legítimo da caixa de spam — e que separam a sua marca de ser usada por golpistas. Introdução Você manda um e-mail importante pro cliente. Ele responde dois dias depois: "desculpa, foi pro spam". Você manda outro pra um lead, e ele simplesmente nunca chega. E enquanto isso, alguém na internet está mandando e-mail se passando pela sua empresa , pedindo PIX pros seus clientes, e você só descobre quando o cliente liga pra reclamar. Bem-vindo ao mundo da autenticação de e-mail. Um lugar onde três siglas — SPF , DKIM e DMARC — decidem se você existe digitalmente ou não. A boa notícia é que esses três protocolos resolvem 95% dos problemas de entregabilidade e de spoofing. A má notícia é que a maioria absoluta dos domínios na internet não tem nem um deles configurado direito . E desde fevereiro de 2024, Google e Yahoo passaram a exigir DMARC pra remetentes que mandam mais de 5.000 e-mails por dia. Parte 1: O problema fundamental do e-mail O protocolo de e-mail (SMTP) foi criado em 1982 e não tinha nenhum mecanismo de autenticação . Literalmente nenhum. Qualquer servidor pode mandar um e-mail dizendo ser de qualquer endereço. Por décadas isso funcionou porque a internet era pequena. Veio o spam, veio o phishing, veio a fraude organizada. A solução não foi reescrever o SMTP — foi adicionar camadas de autenticação por cima, usando o DNS: SPF (2006) — quais servidores podem enviar e-mail em nome do seu domínio DKIM (2007) — assina criptograficamente cada e-mail enviado DMARC (2012) — diz o que fazer quando SPF e DKIM falham, e te dá relatórios Os três trabalham juntos. Sozinhos, têm furos. Combinados, formam defesa razoável. Autenticação de e-mail não é "segurança opcional". É infraestrutura básica. Sem ela: e-mails legítimos vão pro spam, atacantes podem se passar por você, e Google/Yahoo simplesmente rejeitam muito do tráfego de quem não autentica. Parte 2: SPF — Sender Policy Framework 2.1 O que é Você publica no DNS uma lista de servidores autorizados a enviar e-mail em nome do seu domínio. O servidor de destino consulta essa lista e verifica se o IP de origem está autorizado. 2.2 Como configurar Um único registro TXT: Quebrando: v=spf1 — versão ip4:200.150.100.10 — autoriza esse IP include: spf.google.com — autoriza IPs do Google Workspace -all — qualquer outro IP é rejeitado Mecanismos comuns: Mecanismo O que faz ip4:1.2.3.4 IP específico ip4:1.2.3.0/24 Faixa de IPs a IP do registro A mx IPs dos MX include:dominio.com Inclui SPF de outro domínio redirect=outro.com Substitui pelo SPF de outro Qualificadores: Sintaxe Significado +all Aceita tudo (NUNCA use) -all Rejeita tudo que não está na lista all SoftFail — aceita mas marca ?all Neutro (igual a não ter SPF) 2.3 Exemplos reais Só Google Workspace: Só Microsoft 365: Híbrido (M365 + servidor próprio + marketing + transacional): 2.4 Os limites do SPF Limite de 10 lookups DNS. Cada include, a, mx, exists conta. Estourou? SPF quebra com permerror e pra muitos servidores isso equivale a falhar. O limite é recursivo — se você inclui o SPF do Google, e o Google inclui outros, todos contam. Quebra com forwarding. E-mail encaminhado vem de um servidor que não está no seu SPF. Falha. Não protege o "From:" visível. SPF verifica o MAIL FROM (envelope), não o From: que aparece pro usuário. Atacante pode passar SPF perfeitamente e mostrar From: ceo@suaempresa.com.br. Não tem criptografia. Só verifica IP. Servidor autorizado comprometido? Atacante manda o que quiser. 2.5 Verificar SPF 2.6 Erros comuns +all ou ?all — anula a proteção Múltiplos registros SPF no mesmo domínio (só pode ter um) Sintaxe errada (espaços, aspas, ordem) Esquecer de incluir serviço novo Excedendo 10 lookups include apontando pra domínio inexistente Parte 3: DKIM — DomainKeys Identified Mail 3.1 O que é Assinatura digital criptográfica em cada e-mail enviado. Você gera par de chaves (privada + pública) Chave pública vai pro DNS Chave privada fica no servidor de e-mail Servidor assina cada e-mail enviado Servidor de destino busca a chave pública e verifica matematicamente Garante autenticidade (veio mesmo do dono da chave) e integridade (não foi alterado no caminho). 3.2 Como funciona um registro DKIM default. domainkey.empresa.com.br — formato [seletor]. domainkey.[dominio] v=DKIM1 — versão k=rsa — algoritmo p=... — chave pública em Base64 O seletor permite ter múltiplas chaves DKIM ativas simultaneamente. Cada serviço usa seu próprio seletor. 3.3 Como configurar Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate. Publica o registro que ele te dá. Microsoft 365: Defender → Email & collaboration → Threat policies → DKIM → ativar (usa CNAMEs). Mailgun, SendGrid, Mailchimp, Amazon SES: todos têm wizards. Servidor próprio (Postfix com OpenDKIM): 3.4 Como o DKIM assina Header DKIM-Signature adicionado a cada e-mail…