SPF, DKIM e DMARC explicados sem jargão

Se você já abriu um ticket para o time de TI pedindo "configurar autenticação de e-mail" e recebeu um olhar vazio de volta — ou pior, um relatório de 40 páginas que não resolve nada — este guia é pra você. Vamos desmontar os três protocolos que controlam se o seu e-mail chega na caixa de entrada ou na lixeira, com exemplos reais e sem precisar virar engenheiro de infraestrutura.

Por que isso virou urgente em 2026

Em fevereiro de 2024, Gmail e Yahoo passaram a exigir SPF, DKIM e DMARC configurados para qualquer remetente que envie mais de 5.000 mensagens por dia. Leia as diretrizes oficiais do Google e você vai ver que não é sugestão — é requisito de entrega. Quem não atende tem e-mail rejeitado silenciosamente ou marcado como spam antes mesmo de chegar ao filtro do destinatário.

Isso significa que a sua campanha de lançamento, o fluxo de onboarding e o newsletter semanal dependem diretamente de três registros DNS que provavelmente foram configurados (ou não) há anos sem revisão.

---

SPF: quem pode enviar no seu nome

SPF (Sender Policy Framework, RFC 7208) é uma lista de permissões publicada no DNS do seu domínio. Quando um servidor de e-mail recebe uma mensagem de @suaempresa.com, ele consulta essa lista para verificar se o IP remetente está autorizado.

Exemplo de registro SPF

suaempresa.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.45 ~all"

Tradução linha a linha:

• v=spf1 — versão do protocolo, obrigatória
• include:_spf.google.com — autoriza os IPs do Google Workspace a enviar pelo seu domínio
• include:sendgrid.net — autoriza o SendGrid (ou o seu ESP)
• ip4:203.0.113.45 — autoriza um IP dedicado específico (servidor de transacional, por exemplo)
• ~all — qualquer outro IP que tente enviar recebe "softfail" (aceito, mas marcado)

~all vs -all: a diferença que importa

O ~all (softfail) avisa os servidores receptores que IPs não listados são suspeitos, mas não rejeita o e-mail imediatamente. O -all (hardfail) rejeita. Usar -all prematuramente é o erro mais comum: você descobre que esqueceu de listar o sistema de NF-e, o Mailchimp legado ou o CRM que marketing usa só nas quartas — e começa a perder e-mails críticos.

Regra prática: comece com ~all durante o mapeamento de todos os sistemas que enviam e-mail pelo seu domínio. Migre para -all só depois de ter certeza que a lista está completa e o DMARC em reject.

Armadilha comum: SPF tem limite de 10 consultas DNS recursivas. Cada include: conta. Se você usa cinco ESPs, dois CRMs e um sistema legado, já estourou o limite — e o registro passa a falhar silenciosamente para alguns servidores. A solução é usar um serviço de "SPF flattening" ou consolidar envios.

---

DKIM: a assinatura digital que prova autoria

DKIM (DomainKeys Identified Mail, RFC 6376) funciona como um selo de autenticidade. O servidor que envia o e-mail assina a mensagem com uma chave privada. O servidor receptor verifica a assinatura consultando a chave pública publicada no DNS do remetente.

A chave pública fica num registro DNS com um seletor — um apelido que permite ter múltiplas chaves ativas (uma por ESP, por exemplo):

Exemplo de registro DKIM

google._domainkey.suaempresa.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a8..."

• google é o seletor — cada provedor usa o seu
• v=DKIM1 é a versão
• k=rsa é o algoritmo (RSA 2048 bits é o padrão seguro hoje)
• p=... é a chave pública em si (truncada no exemplo)

Rotação de chaves: o que TI precisa fazer periodicamente

Chaves DKIM devem ser rotacionadas a cada 6 a 12 meses. O processo é:

1. Gerar um novo par de chaves (nova chave privada no servidor, nova chave pública no DNS com um seletor diferente, ex: google2)
2. Deixar as duas chaves ativas por 48 horas (TTL do DNS)
3. Desativar a chave antiga

Se o seu ESP gerencia as chaves (como o Google Workspace faz), isso é transparente. Se for um servidor próprio, precisa de procedimento documentado. Pergunte ao seu time de TI quando foi a última rotação — se a resposta for "nunca", é uma vulnerabilidade real.

---

DMARC: a política que une tudo

DMARC (RFC 7489) é a camada de orquestração. Ele define o que acontece quando SPF ou DKIM falham, e para onde enviar relatórios. Sem DMARC, SPF e DKIM são checagens sem consequência — o servidor receptor recebe as informações mas não sabe o que fazer com elas.

O registro fica em _dmarc.seudominio.com:

Exemplo de registro DMARC

_dmarc.suaempresa.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@suaempresa.com; ruf=mailto:dmarc@suaempresa.com; pct=100; adkim=r; aspf=r"

• p=quarantine — e-mails que falham vão para spam (não são rejeitados)
• p=none — modo monitor: não faz nada, só coleta relatórios
• p=reject — rejeita e-mails que falham na autenticação
• rua= — endereço para relatórios agregados (JSON/XML diários)
• ruf= — endereço para relatórios forenses (detalhes por mensagem)
• pct=100 — aplica a política em 100% dos e-mails
• adkim=r e aspf=r — modo relaxed para alinhamento (mais flexível que s=strict)

Para aprofundar a lógica de políticas e alinhamento, o dmarc.org mantém documentação excelente com casos de uso reais.

---

Sequência de implementação em 4 semanas

A ordem importa. Ativar DMARC com p=reject antes de ter SPF e DKIM funcionando corretamente vai rejeitar seus próprios e-mails.

Semana 1 — Inventário e SPF

• Liste todos os sistemas que enviam e-mail no seu domínio (ESP, CRM, sistema de NF, suporte, transacional)
• Crie ou corrija o registro SPF com ~all
• Valide em /verificar-email ou no mail-tester.com

Semana 2 — DKIM

• Configure DKIM em cada ESP listado
• Publique as chaves públicas no DNS
• Aguarde propagação (24-48h) e verifique assinaturas

Semana 3 — DMARC em none

• Publique _dmarc com p=none e os endereços rua/ruf
• Analise os relatórios: você vai descobrir sistemas esquecidos que estão enviando no seu nome (muitas vezes, spammers usando seu domínio)
• Corrija SPF/DKIM para os sistemas legítimos encontrados

Semana 4 — Escalonamento de política

• Migre para p=quarantine; pct=25 (aplica em 25% dos e-mails primeiro)
• Monitore bounce rate e entregas por mais 7-10 dias
• Suba para pct=100 e depois p=reject quando os relatórios mostrarem zero falsos positivos de sistemas legítimos

Esse processo está detalhado no nosso guia completo de deliverabilidade (seção 4), com checklists por tipo de stack.

---

Como monitorar depois que estiver no ar

Relatórios DMARC agregados (rua): chegam diariamente por e-mail em formato XML. São ilegíveis puro, mas ferramentas como Postmark DMARC, DMARC Digests e Google Postmaster Tools transformam em dashboards legíveis. O que você quer ver: taxa de alinhamento SPF e DKIM acima de 95%.

mail-tester.com: ferramenta gratuita — você envia um e-mail para um endereço gerado pela ferramenta e recebe uma pontuação de 0 a 10 com diagnóstico por item. Útil para validação pontual antes de um grande envio.

Google Postmaster Tools: conecta seu domínio e mostra reputação de domínio e IP, taxa de spam report e tendências de entrega específicas para Gmail — onde provavelmente está a maior parte da sua lista.

---

FAQ rápido

Preciso de DMARC se ja tenho SPF e DKIM? Sim. Sem DMARC, qualquer um pode usar seu domínio no campo "From" mesmo que SPF e DKIM falhem — e o receptor não tem instrução de o que fazer. DMARC fecha esse buraco.

Meu domínio de marketing é diferente do domínio principal — preciso configurar nos dois? Sim. Cada domínio (e subdomínio usado como From) precisa de registros próprios. Um domínio sem autenticação é um vetor de phishing gratuito apontado para a sua marca.

p=reject pode quebrar encaminhamentos de e-mail? Pode. Quando alguém encaminha um e-mail usando um cliente ou servidor que altera o cabeçalho, a assinatura DKIM pode quebrar. É um problema real mas de nicho — monitore os relatórios DMARC para identificar se está acontecendo na sua base antes de preocupar o time de TI com isso.

Com que frequência revisar a configuração? A cada nova ferramenta de envio adicionada ao stack e pelo menos uma vez por trimestre. Rodar /verificar-email no seu domínio principal leva dois minutos e mostra imediatamente se algo regrediu.

---

Autenticação de e-mail não é projeto de segurança — é pré-requisito de marketing. Sem ela, você está pagando por uma lista, um ESP e uma estratégia de conteúdo que pode não chegar nem à caixa de entrada. Com ela, você tem base para exigir métricas reais do time de TI e do seu ESP, porque sabe que o canal está funcionando corretamente.