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.
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.
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.
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:
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.
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.
Um único registro TXT:
empresa.com.br. IN TXT "v=spf1 ip4:200.150.100.10 include:_spf.google.com -all"Quebrando:
v=spf1 — versãoip4:200.150.100.10 — autoriza esse IPinclude:_spf.google.com — autoriza IPs do Google Workspace-all — qualquer outro IP é rejeitadoMecanismos 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) |
Só Google Workspace:
"v=spf1 include:_spf.google.com -all"Só Microsoft 365:
"v=spf1 include:spf.protection.outlook.com -all"Híbrido (M365 + servidor próprio + marketing + transacional):
"v=spf1 ip4:200.150.100.10 include:spf.protection.outlook.com include:_spf.mailgun.org include:sendgrid.net -all"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.
dig TXT empresa.com.br +short
# Ferramentas:
# - mxtoolbox.com/spf.aspx
# - dmarcian.com/spf-survey/
# - kitterman.com/spf/validate.html+all ou ?all — anula a proteçãoinclude apontando pra domínio inexistenteAssinatura digital criptográfica em cada e-mail enviado.
Garante autenticidade (veio mesmo do dono da chave) e integridade (não foi alterado no caminho).
default._domainkey.empresa.com.br. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7VK..."default.domainkey.empresa.com.br — formato [seletor].domainkey.[dominio]v=DKIM1 — versãok=rsa — algoritmop=... — chave pública em Base64O seletor permite ter múltiplas chaves DKIM ativas simultaneamente. Cada serviço usa seu próprio seletor.
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):
sudo apt install opendkim opendkim-tools
sudo mkdir -p /etc/opendkim/keys/empresa.com.br
cd /etc/opendkim/keys/empresa.com.br
sudo opendkim-genkey -s mail -d empresa.com.br -b 2048
sudo chown opendkim:opendkim mail.private
cat mail.txt # registro DNS pra publicarHeader DKIM-Signature adicionado a cada e-mail:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=empresa.com.br; s=default;
h=from:to:subject:date:message-id;
bh=BASE64_HASH_DO_BODY;
b=BASE64_ASSINATURAd= — domínio que assinous= — seletorh= — headers assinadosbh= — hash do corpob= — assinaturaQuebra com modificação no caminho. Listas de discussão que adicionam footer invalidam a assinatura.
Chave fraca. Use 2048 bits no mínimo. RSA 1024 é considerado quebrado.
Rotação inexistente. Boas práticas dizem rotacionar a cada 6-12 meses. Quase ninguém faz.
Não protege o From: visível por si só — o d= pode ser diferente do From:. É aí que entra o DMARC.
dig TXT default._domainkey.empresa.com.br +shortMelhor forma: mande um e-mail pra check-auth@verifier.port25.com e receba relatório completo.
SPF e DKIM verificam coisas técnicas mas não impõem decisões. E nenhum dos dois verifica se o From: visível bate com o domínio autenticado.
DMARC resolve:
From: visível bata com domínio autenticado_dmarc.empresa.com.br. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@empresa.com.br; ruf=mailto:dmarc-forensic@empresa.com.br; fo=1; adkim=s; aspf=s; pct=100"| Parâmetro | Função | |---|---| | v=DMARC1 | Versão | | p= | Política: none, quarantine, reject | | sp= | Política para subdomínios | | rua= | E-mail pra relatórios agregados (XML diário) | | ruf= | E-mail pra relatórios forenses | | pct= | % do tráfego que aplica a política | | adkim= | Alinhamento DKIM: r ou s | | aspf= | Alinhamento SPF: r ou s | | fo= | Quando gerar relatórios forenses |
p=none — modo monitoramento. Não faz nada, mas envia relatórios. Comece sempre por aqui.
p=quarantine — quarentena. E-mails que falham vão pro spam.
p=reject — rejeição. E-mails que falham são rejeitados na entrega. O objetivo final.
Relaxed (r): domínios organizacionais batem. email.empresa.com.br alinha com empresa.com.br. Padrão.
Strict (s): tem que ser exatamente igual.
Pra passar DMARC, o e-mail precisa:
MAIL FROM alinhar com o From:, OUd= alinhar com o From:Quando você define rua=, recebe XMLs diários do Google, Microsoft, Yahoo, etc. com:
Você descobre coisas como:
Os XMLs são horríveis de ler. Use serviços que fazem parsing: Postmark DMARC Monitoring (gratuito), Dmarcian, EasyDMARC, Valimail, OnDMARC.
1. Configure SPF e DKIM primeiro.
2. Comece com p=none:
"v=DMARC1; p=none; rua=mailto:dmarc@empresa.com.br; fo=1"3. Monitore por 2-4 semanas com Dmarcian/Postmark.
4. Migre para p=quarantine com pct=10:
"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@empresa.com.br; fo=1"5. Aumente o pct= gradualmente — 25%, 50%, 75%, 100%.
6. Passe pra p=reject:
"v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@empresa.com.br; ruf=mailto:dmarc-forensic@empresa.com.br; fo=1; adkim=s; aspf=s"A jornada leva 1-3 meses pra fazer com calma. Não pule pro reject direto a menos que queira passar a noite explicando pro CEO por que os e-mails pararam.
p=reject diretosp= para subdomíniosAtacante manda e-mail dizendo From: ceo@empresa.com.br. Sem SPF/DKIM/DMARC, chega normalmente.
Defesa: SPF com -all + DMARC com p=reject.
empresa.com.br tem DMARC. Mas vendas.empresa.com.br não. Atacante usa o subdomínio.
Defesa: sempre sp=reject no DMARC do principal.
Atacante registra empressa.com.br (dois s), empresa.com.co, empresa-suporte.com. Tecnicamente é dele, passa todos os checks, parece o seu.
Defesa: monitoramento de domínios similares (DomainTools, DNSTwist), treinamento, BIMI, ferramentas de proteção de marca.
Atacante usa próprio e-mail mas coloca "Ceo Empresa" no nome de exibição. Cliente mobile só mostra "Ceo Empresa".
Defesa: treinamento + filtros que detectam display name spoofing.
Atacante consegue acesso à conta legítima (phishing, senha vazada). Tudo passa todos os checks porque é mesmo legítimo.
Defesa: MFA, monitoramento de comportamento anômalo.
Atacante compromete fornecedor seu. Manda e-mails do servidor real do fornecedor, frequentemente respondendo threads existentes.
Defesa: vigilância, treinamento, verificação fora do canal pra solicitações financeiras.
"HSTS do e-mail". Garante entrega via TLS criptografado, impede downgrade. Configuração tem duas partes: registro DNS + página HTTPS em mta-sts.empresa.com.br.
Relatórios sobre falhas de TLS na entrega.
_smtp._tls.empresa.com.br. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@empresa.com.br"Logo verificado da sua marca aparecendo na inbox do destinatário. Exige DMARC com p=quarantine ou p=reject + logo SVG + idealmente VMC (certificado pago).
Diferencial visual enorme de credibilidade.
Resolve o problema de forwarding/listas que quebram SPF/DKIM. Servidores intermediários atestam a autenticação original. Implementado pelos grandes provedores automaticamente.
Protege contra falsificação do próprio DNS. Assina criptograficamente os registros. Camada extra essencial.
Em ordem de frequência:
Análise completa:
Terminal:
dig TXT empresa.com.br +short | grep spf
dig TXT default._domainkey.empresa.com.br +short
dig TXT _dmarc.empresa.com.br +short
dig MX empresa.com.br +short
dig -x 200.150.100.10 +shortHeaders de e-mail recebido: Gmail → três pontinhos → "Mostrar original". Procure Authentication-Results::
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=sender@empresa.com.br;
dkim=pass header.i=@empresa.com.br header.s=default;
dmarc=pass (p=REJECT) header.from=empresa.com.brpass em todos os três é o que você quer.
-all, abaixo de 10 lookupsp=none — comece monitorandop=quarantine gradualmentep=rejectsp=reject pra subdomíniosAutenticação de e-mail parece complicada até você fazer uma vez. SPF, DKIM e DMARC juntos resolvem 95% dos problemas de entregabilidade e impedem 95% dos ataques de spoofing diretos.
Não fazer isso, em 2026, é negligência. Google e Yahoo já estão rejeitando massivamente quem não autentica. Daqui a alguns anos, mandar e-mail sem SPF/DKIM/DMARC vai ser tão impensável quanto modem discado.
E o melhor: não é caro. Os três protocolos são gratuitos, a documentação é abundante, ferramentas de monitoramento têm tier gratuito, resultado é imediato.
O SentinelHub varre exatamente isso: monitora SPF, DKIM, DMARC, MTA-STS, DNSSEC e todos os registros DNS críticos do seu domínio. Quando algo muda — alguém adiciona um serviço novo e estoura o limite de SPF, alguém remove acidentalmente o registro DMARC, alguém esquece de renovar uma chave DKIM — você fica sabendo. Em português.
Cliente que recebe e-mail seu na caixa de spam é cliente que perde confiança. Cliente que recebe e-mail de golpista se passando por você é cliente que você perde.
Achou útil? Compartilha com seu time de marketing e com o sysadmin que cuida do servidor de e-mail. Especialmente se vocês ainda mandam e-mails marcados como "[SPAM]" pra própria caixa.