DKIM vs SPF vs DMARC não é uma escolha entre alternativas: os três padrões respondem a perguntas diferentes e só funcionam em conjunto. O SPF lista quais servidores podem enviar e-mails em nome do domínio do envelope; o DKIM anexa uma assinatura feita com uma chave publicada sob um domínio; o DMARC exige que pelo menos um deles passe para um domínio que corresponda ao endereço From: visível e publica a política do dono do domínio e os endereços para onde enviar relatórios.
Visão geral
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Especificação | RFC 7208 (2014) | RFC 6376 (2011), RFC 8301, RFC 8463 | RFC 9989, 9990, 9991 (maio de 2026), que substituem a RFC 7489 |
| Pergunta respondida | Este IP pode enviar pelo domínio do envelope? | Este domínio assinou este conteúdo, sem alterações? | Um domínio autenticado corresponde ao domínio do From:, e o que acontece se não corresponder? |
| Identidade verificada | MAIL FROM (Return-Path) e HELO | O domínio d= em DKIM-Signature | O domínio do cabeçalho From: |
| Onde é publicado | TXT no próprio domínio | TXT em selector._domainkey.domain | TXT em _dmarc.domain |
| Sobrevive ao encaminhamento simples | Não (o IP do encaminhador não está na lista) | Sim, se a mensagem não for alterada | Sim, por meio do DKIM |
| Sobrevive a listas de discussão que editam as mensagens | Não | Não (o corpo ou os cabeçalhos assinados mudam) | Só se a lista reescrever o From: ou se o receptor confiar no ARC |
| Limites rígidos | 10 termos que consultam o DNS por avaliação, 2 consultas vazias | RSA de pelo menos 1024 bits (2048 recomendado); rsa-sha1 proibido | Percurso da árvore DNS com no máximo 8 consultas |
| Efeito por si só | Apenas um resultado; os receptores decidem | Apenas um resultado; os receptores decidem | Política do dono do domínio: none, quarantine, reject |
| Relatórios | Nenhum | Nenhum | Relatórios agregados em XML (rua), relatórios de falha (ruf) |
Como cada um funciona
O SPF é avaliado durante a sessão SMTP: o receptor usa o domínio do remetente do envelope (ou o do HELO, no caso de mensagens de devolução), busca o registro TXT desse domínio e compara o IP que está se conectando com os termos ip4, ip6, a, mx e include listados. O resultado é pass, fail (-all), softfail (~all), neutral, none ou um erro. Cada include, a, mx, ptr, exists e redirect custa uma consulta DNS, e mais de 10 tornam o resultado permerror (RFC 7208 §4.6.4), o que quebra o SPF para todos os e-mails do domínio.
O DKIM calcula o hash do corpo canonicalizado (bh=) e dos cabeçalhos listados (h=) e os assina com a chave privada do domínio. O receptor busca a chave pública em um registro TXT cujo nome é formado pelo seletor s= e pelo domínio d= (por exemplo, google._domainkey.github.com) e verifica a assinatura. A RFC 8301 proíbe rsa-sha1 e exige chaves de pelo menos 1024 bits; a RFC 8463 acrescenta ed25519-sha256, que normalmente é publicado junto com uma assinatura RSA porque o suporte dos verificadores ainda é incompleto.
O DMARC é executado depois dos dois: ele passa quando o SPF passa para um domínio alinhado com o From: ou quando uma assinatura DKIM é verificada com sucesso para um domínio alinhado com o From:. O alinhamento é relaxado por padrão (mesmo domínio organizacional, então mail.example.com se alinha com example.com) ou estrito com aspf=s e adkim=s.
O script abaixo lê registros reais (20 de outubro de 2026, dig 9.10.6 e OpenSSL 3.6.5).
echo "== SPF: google.com and its include"
dig +short TXT google.com | grep "v=spf1"
dig +short TXT _spf.google.com
echo "== DMARC: google.com and github.com"
dig +short TXT _dmarc.google.com
dig +short TXT _dmarc.github.com
echo "== DKIM: key size behind two github.com selectors"
for sel in google pf2023; do
printf '%s: ' "$sel"
dig +short TXT "$sel._domainkey.github.com" | tr -d '" \n' | sed 's/.*p=//' \
| openssl base64 -d -A | openssl pkey -pubin -inform DER -noout -text | head -1
done
== SPF: google.com and its include
"v=spf1 include:_spf.google.com ~all"
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
== DMARC: google.com and github.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
== DKIM: key size behind two github.com selectors
google: Public-Key: (2048 bit)
pf2023: Public-Key: (1024 bit)
Três detalhes merecem atenção. O SPF do Google termina em ~all (softfail), enquanto a política DMARC dele é reject: com a política DMARC aplicada, quem decide é o resultado do DMARC, então o qualificador do SPF pouco importa. O GitHub ainda publica pct=100, uma tag que a RFC 9989 removeu; os receptores ignoram tags desconhecidas e 100 era o valor padrão, então isso é inofensivo. E um dos seletores do GitHub ainda usa uma chave de 1024 bits, o mínimo que a RFC 8301 permite. O analisador de autenticação de e-mail faz as mesmas verificações para qualquer domínio.
O alinhamento decide o resultado
A tabela mostra fluxos típicos de uma mensagem com From: news@example.com.
| Fluxo | SPF | DKIM | DMARC |
|---|---|---|---|
Seu próprio servidor, assinando como example.com | pass, alinhado | pass, alinhado | pass |
Provedor de serviço de e-mail com domínio de retorno (bounce) próprio, assinando como example.com | pass para o domínio do provedor, não alinhado | pass, alinhado | pass (DKIM) |
| Provedor que assina só com o próprio domínio | pass, não alinhado | pass, não alinhado | fail |
| Mensagem encaminhada sem alterações por uma regra da caixa de correio | fail (IP do encaminhador) | pass, alinhado | pass (DKIM) |
| Lista de discussão adiciona um rodapé ou uma tag no assunto | fail ou não alinhado | fail (hash do corpo) | fail, a menos que o From: seja reescrito ou que o ARC seja considerado confiável |
From: falsificado, enviado do servidor de outra pessoa | fail ou none | none | fail, política aplicada |
A terceira linha mostra o erro de implantação mais comum: um remetente passa no SPF e no DKIM, mas falha no DMARC porque nenhum dos domínios autenticados é seu. Configure cada provedor para assinar com uma chave sob seu domínio (normalmente um CNAME que aponta para a chave do provedor) e use um domínio de retorno personalizado se quiser que o SPF também fique alinhado.
Encaminhamento, listas de discussão e ARC
O SPF autentica o último salto, então qualquer encaminhamento o quebra; os esquemas de reescrita do remetente (Sender Rewriting Scheme, SRS) corrigem o SPF para o próprio domínio do encaminhador, mas nunca o alinham. O DKIM autentica o conteúdo, então sobrevive a retransmissões que não mexem na mensagem e falha quando listas adicionam rodapés ou tags. O ARC (RFC 8617, Experimental) permite que um intermediário sele os resultados de autenticação que viu, e os receptores que confiam nesse selador podem aceitar a mensagem apesar da falha no DMARC; o visualizador de cadeia ARC mostra a cadeia. A fraqueza que resta é o ataque de repetição de DKIM (DKIM replay): uma mensagem com assinatura válida pode ser reenviada a novos destinatários, um problema que um grupo de trabalho da IETF trata nos seus rascunhos do DKIM2.
O que os provedores de e-mail exigem
Desde 1º de fevereiro de 2024, o Gmail exige que todo remetente use SPF ou DKIM, DNS direto e reverso válidos, TLS e uma taxa de spam informada abaixo de 0,3%. Quem envia 5.000 mensagens ou mais por dia para contas pessoais do Gmail também precisa de SPF e DKIM, de um registro DMARC (p=none basta), de um From: alinhado com o SPF ou o DKIM e de cancelamento da inscrição com um clique (RFC 8058) nos e-mails de marketing. O Yahoo introduziu regras equivalentes na mesma época. A Microsoft aplicou os mesmos limites de volume ao Outlook.com a partir de 5 de maio de 2025 e rejeita os e-mails que não cumprem os requisitos com 550 5.7.515. Os logotipos BIMI exigem, além disso, DMARC em quarantine ou reject.
A RFC 9989 (maio de 2026) levou o DMARC para o Standards Track e mudou o registro: pct, rf e ri deixaram de existir, t=y substitui pct=0 para testes, np define uma política para subdomínios inexistentes, psd marca domínios de sufixo público, e um percurso da árvore DNS substitui a Public Suffix List na busca pelo domínio organizacional.
Para que serve cada um
- SPF: autorize seus próprios servidores de saída e os provedores que usam seu domínio como endereço de retorno; publique
v=spf1 -allem domínios e subdomínios que nunca enviam e-mails. - DKIM: assine todos os e-mails enviados com seu próprio domínio, inclusive os enviados por provedores; faça a rotação dos seletores pelo menos uma vez por ano e substitua chaves de 1024 bits por chaves de 2048 bits.
- DMARC: colete relatórios primeiro e só depois aplique a política; adicione
np=reject(ousp=reject) para que atacantes não possam usar subdomínios inventados. - Domínios estacionados:
v=spf1 -all,v=DMARC1; p=reject;e nenhum seletor DKIM. - Proteção do transporte e proteção do conteúdo são problemas diferentes: use MTA-STS para o TLS entre servidores e S/MIME ou OpenPGP para a assinatura de ponta a ponta.
Notas de migração
- Faça um inventário dos remetentes com os relatórios agregados do DMARC em
p=nonedurante duas a quatro semanas; toda fonte legítima deve mostrar DKIM alinhado, SPF alinhado ou ambos. - Corrija o DKIM primeiro: ative a assinatura com domínio personalizado em cada provedor, publique chaves de 2048 bits (o gerador de registros DKIM as divide em strings de 255 caracteres) e verifique com o depurador de DKIM.
- Enxugue o SPF para menos de 10 consultas removendo includes que não são usados; substitua os includes por faixas de IP (flattening) só se você conseguir mantê-las atualizadas automaticamente.
- Aplique a política gradualmente:
p=quarantinecomt=ypara observar, depoisp=quarantine, depoisp=reject; mantenha os relatóriosruachegando. - Proteja os subdomínios com
spounpe publique registros nulos em todo domínio que não deve enviar e-mails.
Referências
- RFC 7208, SPF (§4.6.4, limites de consultas)
- RFC 6376, DKIM, RFC 8301, atualização criptográfica do DKIM, RFC 8463, Ed25519 para o DKIM
- RFC 9989, DMARC, RFC 9990, relatórios agregados, RFC 9991, relatórios de falha
- RFC 8617, ARC
- RFC 8058, cancelamento da inscrição com um clique
- Google: diretrizes para remetentes de e-mail
- Microsoft: requisitos mais rígidos do ecossistema de e-mail para remetentes de alto volume