Três camadas para provar que o e-mail é seu
O SMTP nasceu em uma internet de confiança mútua e nunca embutiu autenticação: o servidor que entrega a mensagem simplesmente afirma o remetente, e o destino, historicamente, acreditava. Os três mecanismos de hoje foram colados por cima do protocolo para consertar isso sem quebrá-lo. Eles resolvem problemas distintos e não se substituem, um provedor de destino tende a confiar em quem passa nos três e a rejeitar ou mandar para o spam quem falha.
| Registro | O que prova | Identidade que valida | Onde vive no DNS |
|---|---|---|---|
| SPF | Que o servidor de origem está autorizado | MAIL FROM (envelope, RFC 5321) | TXT no domínio |
| DKIM | Que a mensagem não foi adulterada | Domínio da assinatura (d=) | seletor._domainkey.domínio |
| DMARC | Que SPF ou DKIM se alinha ao “De” visível | From (cabeçalho, RFC 5322) | _dmarc.domínio |
Repare na coluna do meio: cada mecanismo autentica uma identidade diferente. É aí que mora a confusão de nove em cada dez configurações. O SPF olha para um endereço que o usuário nunca vê; o DMARC olha para o endereço que ele vê. Quando esses dois endereços pertencem a domínios diferentes, o que acontece o tempo todo com plataformas de envio,, o SPF pode dizer “passou” enquanto o DMARC diz “falhou”. O resto deste guia gira em torno de reconciliar essas identidades.
- Envelope / MAIL FROM (RFC 5321)
- O endereço declarado na conversa SMTP, para onde voltam as devoluções (Return-Path). Não aparece no cliente de e-mail. É o que o SPF verifica.
- Cabeçalho From (RFC 5322)
- O campo “De” que o destinatário lê na tela. É o que o phishing falsifica e o que o DMARC protege.
- Alinhamento (alignment)
- A regra do DMARC: o domínio autenticado por SPF ou por DKIM tem de casar com o domínio do From. Sem casar, não há DMARC pass, mesmo com SPF e DKIM válidos.
SPF: quem pode enviar pelo domínio
O SPF (Sender Policy Framework, RFC 7208) é um único registro TXT que lista, por meio de mecanismos, os servidores autorizados a usar o seu domínio no MAIL FROM. O destinatário pega o IP de origem da conexão e o compara com essa lista. Se bate, o SPF dá pass; se não bate, o resultado depende do qualificador que fecha o registro.
example.com. IN TXT "v=spf1 include:_spf.google.com ip4:198.51.100.25 -all"
v=spf1 → versão do registro (obrigatória, sempre primeiro)
include:_spf.google.com → autoriza os IPs do Google Workspace (1 consulta de DNS)
ip4:198.51.100.25 → autoriza este IP literal (0 consultas)
-all → hardfail: rejeita qualquer outro servidor| Mecanismo | O que autoriza | Conta no limite de 10? |
|---|---|---|
| all | Casa com tudo; fecha o registro com um qualificador | Não |
| ip4 / ip6 | Um IP ou faixa CIDR literal | Não |
| a | Os IPs do registro A/AAAA do domínio | Sim (1) |
| mx | Os IPs dos servidores MX do domínio | Sim (1) |
| include | Importa o SPF de outro domínio (o provedor) | Sim (1 + os de dentro) |
| exists | Testa se um nome resolve (usa macros) | Sim (1) |
| ptr | DNS reverso, desaconselhado pela RFC 7208 | Sim (1) |
| redirect= | Modificador: substitui o registro pelo de outro domínio | Sim (1) |
Cada mecanismo pode receber um qualificador que decide o veredito quando ele casa. Na prática, o único qualificador que importa é o do “all” no fim do registro, porque é ele que define o que acontece com quem não está na lista.
| Qualificador | Resultado | Efeito prático no fim (…all) |
|---|---|---|
| + | Pass (padrão) | +all autoriza QUALQUER servidor, nunca use |
| - | Fail (hardfail) | -all rejeita quem não está na lista (recomendado) |
| ~ | SoftFail | ~all aceita mas marca como suspeito (transição) |
| ? | Neutral | ?all não emite opinião, proteção quase nula |
Há uma armadilha estrutural no SPF que derruba domínios inteiros em silêncio: o limite de 10 consultas de DNS. A RFC 7208 (§4.6.4) exige que a avaliação não faça mais de 10 buscas provocadas por include, a, mx, ptr, exists e redirect, somando as buscas aninhadas dentro de cada include. Estourar esse teto não é softfail nem neutro: é permerror, e o SPF passa a ser tratado como se não existisse. Como cada provedor que você adiciona (Google, plataforma de marketing, CRM, ferramenta de nota fiscal) traz o próprio include, o orçamento acaba mais rápido do que parece. Vale a pena ver a conta.
# Exemplo ilustrativo: um SPF com includes aninhados que ESTOURA o limite
example.com: v=spf1 include:_spf.google.com include:spf.plataforma.net \
include:_spf.crm.com -all
_spf.google.com: v=spf1 include:_netblocks.google.com include:_netblocks2.google.com \
include:_netblocks3.google.com ~all
_netblocks*.google.com: só ip4/ip6 (0 consultas cada)
spf.plataforma.net: v=spf1 a mx include:relay.plataforma.net ~all
relay.plataforma.net: só ip4 (0 consultas)
_spf.crm.com: v=spf1 include:eu._spf.crm.com include:us._spf.crm.com ~all
eu/us._spf.crm.com: só ip4 (0 consultas cada)| # | Termo que dispara a consulta | Acumulado |
|---|---|---|
| 1 | include:_spf.google.com | 1 |
| 2 | ↳ include:_netblocks.google.com | 2 |
| 3 | ↳ include:_netblocks2.google.com | 3 |
| 4 | ↳ include:_netblocks3.google.com | 4 |
| 5 | include:spf.plataforma.net | 5 |
| 6 | ↳ a | 6 |
| 7 | ↳ mx | 7 |
| 8 | ↳ include:relay.plataforma.net | 8 |
| 9 | include:_spf.crm.com | 9 |
| 10 | ↳ include:eu._spf.crm.com | 10 |
| 11 | ↳ include:us._spf.crm.com → estoura | 11 → PermError |
Onze consultas, uma a mais do que o permitido: o registro inteiro devolve permerror e o SPF é descartado. Note que os três provedores parecem inocentes, três includes no topo,, mas o Google sozinho gasta quatro por causa dos seus includes internos. A saída é achatar (substituir includes por faixas ip4/ip6 quando o provedor publica IPs estáveis), remover fontes de envio que você não usa mais, ou delegar o envio a um subdomínio dedicado. O verificador de SPF, DKIM e DMARC mostra o contador “lookups: n/10” e acende o alerta a partir de 8. Se quiser inspecionar o que cada include resolve, o consulta DNS devolve os TXT crus de cada nome.
DKIM: a assinatura que prova integridade
O DKIM (DomainKeys Identified Mail, RFC 6376, hoje um Padrão da Internet, STD 76) resolve um problema que o SPF nem toca: a integridade. O servidor de envio calcula um hash do corpo e de um conjunto de cabeçalhos escolhidos e assina esse conjunto com uma chave privada. A assinatura viaja dentro de um cabeçalho DKIM-Signature; a chave pública correspondente fica publicada no DNS. Se o assunto ou o corpo mudam um único byte no caminho, a assinatura deixa de bater. É a mesma família de ideias do guia sobre hashing, criptografia e encoding: aqui usamos um hash para detectar adulteração e uma chave assimétrica para provar autoria.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
s=selector1; h=from:to:subject:date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AbCdE...assinatura codificada em base64...==
a= → algoritmo (rsa-sha256; ed25519-sha256 também é padrão)
c= → canonicalização cabeçalho/corpo (relaxed/relaxed)
d= → DOMÍNIO que assina, é ele que o DMARC alinha contra o From
s= → SELETOR: aponta para s=selector1 → selector1._domainkey.example.com
h= → lista de cabeçalhos cobertos pela assinatura
bh= → hash do CORPO (body hash)
b= → a assinatura sobre os cabeçalhos de h= mais o bh=selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq…IDAQAB"
v=DKIM1 → versão do registro
k=rsa → tipo de chave (rsa; ed25519 também é possível)
p=… → a chave PÚBLICA em base64; p= vazio significa seletor REVOGADO- Seletor (s=)
- Um rótulo escolhido por você que aponta para uma chave específica. Permite ter várias chaves ativas e trocá-las (rotação) sem parada: basta publicar um seletor novo e migrar.
- Canonicalização (c=)
- Como cabeçalho e corpo são normalizados antes do hash. “simple” é rígido (qualquer mudança quebra); “relaxed” tolera diferenças de espaço em branco e quebra de linha que os servidores introduzem no trânsito. Por isso relaxed/relaxed é o mais usado.
- Body hash (bh=) e assinatura (b=)
- bh= é o hash só do corpo; b= é a assinatura criptográfica sobre os cabeçalhos listados em h= mais o próprio bh=. Verificar os dois separa “o corpo mudou” de “um cabeçalho mudou”.
A grande virtude do DKIM é sobreviver a saltos que quebram o SPF. Como a prova viaja dentro da mensagem, e não amarrada ao IP da conexão, um encaminhamento que reescreve o envelope não destrói a assinatura, desde que ninguém altere o corpo nem os cabeçalhos assinados. É por isso que, na prática, o DKIM alinhado costuma ser o caminho mais confiável para passar no DMARC.
DMARC: alinhamento, política e relatórios
O DMARC é a camada que dá sentido às outras duas. Sozinhos, SPF e DKIM autenticam domínios que o usuário nunca vê. O DMARC (originalmente RFC 7489, hoje repadronizado pela RFC 9989) faz três coisas: exige que SPF ou DKIM se alinhe com o domínio do From visível, define uma política para quem falha, e pede relatórios de volta. O alinhamento é o coração, sem ele, tudo desmorona.
Vale montar o exemplo que confunde todo mundo: um e-mail que passa no SPF e mesmo assim falha no DMARC. É o cenário típico de quem dispara newsletter por uma plataforma de marketing.
Return-Path: <[email protected]> ← envelope (o SPF olha aqui)
DKIM-Signature: ... d=plataforma-envio.com; s=k1 ← assinatura da plataforma
From: Promoções <[email protected]> ← cabeçalho (o usuário vê isto)
SPF : pass para plataforma-envio.com (o IP está no SPF DA PLATAFORMA)
DKIM : pass para plataforma-envio.com (a assinatura d= confere)
Alinhamento DMARC, comparado com o From = loja.com.br:
SPF alinhado? plataforma-envio.com ≟ loja.com.br → NÃO
DKIM alinhado? plataforma-envio.com ≟ loja.com.br → NÃO
Resultado DMARC: FAIL → com p=reject em loja.com.br, a mensagem é RECUSADAA correção não é mexer na política, e sim reconciliar as identidades. Duas saídas: pedir à plataforma que assine o DKIM com d=loja.com.br (chave delegada), o que alinha o DKIM; ou configurar o Return-Path em um subdomínio seu, como bounce.loja.com.br, o que alinha o SPF. Basta uma das duas alinhar para o DMARC passar. É exatamente a regra que Google e Yahoo exigem dos grandes remetentes desde 2024: SPF e DKIM configurados, e ao menos um deles alinhado ao From.
O rigor do alinhamento é ajustável por duas tags: aspf (para o SPF) e adkim (para o DKIM). Cada uma aceita “r” (relaxed, o padrão) ou “s” (strict). No modo relaxado, basta coincidir o domínio organizacional, news.loja.com.br alinha com loja.com.br. No modo estrito, o domínio tem de ser idêntico, news.loja.com.br não alinha com loja.com.br. Comece sempre relaxado.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; \
adkim=s; aspf=r; pct=100"
v=DMARC1 → versão (obrigatória, sempre primeiro)
p= → política do domínio: none | quarantine | reject
rua= → destino dos relatórios AGREGADOS (diários, em XML)
ruf= → destino dos relatórios de FALHA por mensagem (opcional; cuidado com privacidade)
adkim=s → alinhamento DKIM estrito (domínio idêntico)
aspf=r → alinhamento SPF relaxado (mesmo domínio organizacional)
pct=100 → aplica a política a 100% das mensagens| Política (p=) | O que o destinatário faz | Quando usar |
|---|---|---|
| none | Só observa e reporta; nada é bloqueado | Início: colher relatórios sem risco |
| quarantine | Manda para o spam quem não alinha | Meio: quando o legítimo já passa |
| reject | Recusa a entrega na conexão SMTP | Fim: proteção máxima contra spoofing |
Os relatórios agregados (rua) são o que torna o DMARC operável: chegam por e-mail, em XML, e listam quais IPs enviaram em nome do seu domínio, quantas mensagens, e como cada uma se saiu no SPF, no DKIM e no alinhamento. Na revisão de 2026 (a chamada DMARCbis), o padrão foi dividido em três documentos, RFC 9989 (o protocolo), RFC 9990 (relatórios agregados) e RFC 9991 (relatórios de falha), e, o mais importante, o DMARC deixou de ser apenas Informational e entrou nos Standards Track do IETF como Proposed Standard. Para quem opera, a prática do dia a dia não muda: publicar, ler os relatórios, endurecer.
Por que o SPF quebra no encaminhamento, e o que ARC e SRS fazem
O calcanhar de Aquiles do SPF é o encaminhamento. Você manda um e-mail para alguém que redireciona a caixa para outro provedor; o servidor que reencaminha usa o SEU domínio no MAIL FROM, mas o IP dele não está no seu SPF, porque como estaria? Você nunca autorizou o servidor de um terceiro. O SPF, então, falha, apesar de a mensagem ser legítima. Duas soluções distintas atacam o problema em pontos diferentes da cadeia, e vale conhecer as duas antes de subir para p=reject.
- 2006SPF, experimental (RFC 4408)
A primeira tentativa de autorizar servidores por IP nasce como padrão experimental.
- 2007DKIM (RFC 4871)
A assinatura criptográfica une DomainKeys (Yahoo) e Identified Internet Mail (Cisco).
- 2011DKIM vira Padrão da Internet (RFC 6376, STD 76)
A versão consolidada do DKIM alcança o topo da escala de maturidade do IETF.
- 2014SPF repadronizado (RFC 7208)
O SPF deixa de ser experimental e vira Proposed Standard, com o limite de 10 consultas de DNS.
- 2015DMARC (RFC 7489)
Amarra SPF e DKIM ao From visível, cria o alinhamento e os relatórios, publicado como Informational.
- 2019ARC (RFC 8617)
Padrão experimental que preserva o resultado de autenticação ao atravessar listas e encaminhadores.
- 2024Google e Yahoo exigem autenticação
Desde 1º de fevereiro, quem envia mais de 5.000 mensagens/dia ao Gmail precisa de SPF, DKIM e DMARC alinhados.
- 2026DMARCbis (RFC 9989/9990/9991)
Três RFCs obsoletam a 7489 e movem o DMARC para os Standards Track como Proposed Standard.
Por que exatamente o SPF quebra no encaminhamento
O SPF checa o IP da conexão contra o domínio do MAIL FROM. Num encaminhamento simples (um “forward automático” de caixa), o servidor intermediário reenvia mantendo o seu domínio no envelope, mas a conexão agora parte do IP dele. Como esse IP nunca esteve na sua lista, o SPF falha. A mensagem é a mesma, o conteúdo é legítimo, só o caminho mudou. Esse é o motivo pelo qual ninguém deve confiar só no SPF para bater o martelo, e por que o DMARC aceita alinhamento por SPF OU por DKIM.
SRS, reescrever o envelope para o SPF voltar a passar
O SRS (Sender Rewriting Scheme) age no encaminhador: em vez de manter o seu domínio no MAIL FROM, ele reescreve o envelope para um endereço do próprio domínio dele, guardando de forma reversível o original para as devoluções voltarem ao lugar certo. Assim o SPF passa a checar o domínio de quem realmente reenvia, e volta a dar pass. O SRS não tem RFC formal, é uma especificação técnica de 2004 (Shevek, a partir da ideia de Meng Weng Wong) adotada de fato por servidores e provedores como convenção. Ele conserta o SPF, mas não o alinhamento com o From: por isso, sozinho, não salva o DMARC.
ARC, carregar o veredito de autenticação através dos saltos
O ARC (Authenticated Received Chain, RFC 8617, experimental) resolve o problema pela outra ponta. Cada intermediário confiável, uma lista de discussão, por exemplo, que modifica o assunto e quebra o DKIM, registra, assinado, qual foi o resultado de autenticação que ELE viu antes de mexer na mensagem. O destino final, se confia nessa cadeia, pode aceitar um e-mail que falharia no DMARC “cru”, porque a corrente ARC prova que ele estava legítimo antes das alterações do caminho. É uma ponte de confiança entre servidores, não um substituto do SPF ou do DKIM.
O que o DMARC NÃO resolve: domínios parecidos (cousin domains)
O DMARC protege o SEU domínio exato. Ele não faz nada contra um atacante que registra loja-pagamentos.com ou l0ja.com.br e manda e-mail perfeitamente autenticado a partir de lá, afinal, é o domínio DELE, com SPF e DKIM dele. Para o olho humano, parece você; para o DMARC, é outro domínio, e passa. Defesas contra isso ficam fora do trio: monitoramento de registros parecidos, filtros anti-phishing por reputação e conteúdo, e programas como o BIMI, que exibe o seu logotipo verificado ao lado das mensagens (exigindo DMARC em quarantine com pct=100 ou reject) para dar ao usuário um sinal visual de autenticidade. Um WHOIS do domínio suspeito ajuda a ver quando ele foi registrado e por quem.
Como implantar sem bloquear e-mail legítimo
- Inventarie e publique SPF e DKIMListe TODAS as fontes de envio (Google/Microsoft, marketing, CRM, faturamento, formulários) e cubra cada uma no SPF sem estourar as 10 consultas; peça a cada provedor um DKIM com d= alinhado ao seu domínio.
- Suba o DMARC em p=none com ruaPublique _dmarc com p=none e rua apontando para uma caixa sua. Nada é bloqueado; você só liga o fluxo de relatórios.
- Leia os relatórios por semanasNos XML agregados, procure fontes legítimas que falham no alinhamento e conserte cada uma (DKIM delegado ou Return-Path em subdomínio seu).
- Endureça para p=quarantineQuando o legítimo já passa, mude para quarantine (opcionalmente com pct menor no começo) e observe se algo cai no spam indevidamente.
- Feche em p=rejectCom tudo estável, vá para reject: a partir daí, qualquer mensagem que não alinhe com o seu From é recusada na porta.
Vale saber que autenticar o remetente é uma peça de um ecossistema maior. O MTA-STS (RFC 8461) e o TLS-RPT (RFC 8460) tratam de forçar e reportar TLS na entrega entre servidores; o BIMI cuida do logotipo verificado. Nada disso substitui o trio, todos pressupõem o DMARC funcionando. Para ler o veredito de autenticação de uma mensagem que já chegou (o cabeçalho Authentication-Results, com os resultados de SPF, DKIM e DMARC daquele e-mail), use o analisador de cabeçalhos de e-mail; ele reconstrói a rota e mostra onde a autenticação passou ou falhou.
- Um único registro SPF, terminando em -all (ou ~all durante a transição), dentro das 10 consultas de DNS.
- DKIM ativo com chave de ao menos 2048 bits e d= alinhado ao domínio do From.
- DMARC publicado em _dmarc, com rua para uma caixa que alguém realmente lê.
- Ao menos uma identidade, SPF OU DKIM, alinhada com o From em toda fonte de envio.
- Progressão none → quarantine → reject só depois de os relatórios confirmarem que o legítimo passa.
Perguntas frequentes
Por que meu e-mail passa no SPF mas falha no DMARC?
Preciso dos três ou o SPF basta?
O que é o limite de 10 consultas de DNS do SPF?
Por que começar com p=none?
DKIM ou SPF: qual sobrevive ao encaminhamento?
O DMARC protege contra domínios parecidos com o meu?
O DMARC virou um padrão oficial?
SPF autoriza servidores pelo envelope, DKIM assina o conteúdo, e o DMARC amarra os dois ao From visível exigindo alinhamento, é por isso que um e-mail pode passar no SPF e ainda falhar no DMARC. Fique dentro das 10 consultas do SPF, garanta ao menos uma identidade alinhada por fonte de envio, conheça o encaminhamento (que SRS e ARC tentam consertar) e implante em ordem: p=none com rua, leia os relatórios, e só então quarantine e reject.
Fontes e referências
- RFC 7208, Sender Policy Framework (SPF)
- RFC 6376, DomainKeys Identified Mail (DKIM), STD 76
- RFC 7489, DMARC (original, Informational, obsoletada)
- RFC 9989, DMARC (DMARCbis, obsoleta a RFC 7489)
- RFC 8617, Authenticated Received Chain (ARC)
- RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)
- Google, Diretrizes para remetentes de e-mail