SPF, DKIM e DMARC explicados: como os três registros funcionam juntos

O SPF diz quais servidores podem enviar e-mails pelo seu domínio. O DKIM assina cada mensagem para que os destinatários possam provar qual domínio a enviou e que ela não foi alterada no caminho. O DMARC liga os dois ao endereço From que as pessoas realmente veem: uma mensagem só passa no DMARC se o SPF ou o DKIM passar para um domínio que corresponde ao domínio do From, e o registro DMARC diz aos destinatários o que fazer quando isso não acontece.

Você pode checar os três para qualquer domínio agora mesmo com os nossos verificador de SPF, verificador de DKIM e verificador de DMARC, todos gratuitos. O resto deste guia explica o que essas ferramentas estão lendo e por que cada resultado importa.

A versão curta em uma tabela

	SPF	DKIM	DMARC
Padrão	RFC 7208 (2014)	RFC 6376 (2011)	RFC 7489 (2015), substituída pela RFC 9989 (maio de 2026)
O que verifica	O remetente do envelope (MAIL FROM) e o nome HELO	Uma assinatura no cabeçalho DKIM-Signature	Se o SPF ou o DKIM passou para o domínio do From
Onde fica	Registro TXT em example.com	Registro TXT em selector._domainkey.example.com	Registro TXT em _dmarc.example.com
Sobrevive ao encaminhamento	Geralmente não	Sim, se a mensagem não for modificada	Sim, via DKIM
Diz aos destinatários o que fazer	Só de forma fraca (-all vs ~all)	Não	Sim: none, quarantine ou reject

Existem três registros porque cada um, sozinho, deixa uma brecha. SPF e DKIM autenticam um domínio, mas não necessariamente o que aparece no From. O DMARC fecha essa brecha.

SPF: quem pode enviar

O SPF é uma lista de servidores autorizados a enviar e-mails usando o seu domínio no remetente do envelope. O servidor de destino consulta o registro TXT do domínio informado no comando MAIL FROM (o endereço para onde vão os bounces, muitas vezes exibido como Return-Path) e verifica se o IP que está se conectando está na lista. A RFC 7208 também permite verificar o nome HELO.

Um registro típico de uma empresa no Google Workspace que também envia newsletters por uma plataforma de marketing:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.esp-example.net -all"

Lendo da esquerda para a direita:

• v=spf1 identifica o registro como SPF. Só pode existir um registro desses por domínio.
• include: puxa a lista SPF de outro domínio, aqui a do Google e a da plataforma de e-mail.
• -all significa que tudo o que não está listado deve falhar (fail). ~all significa softfail: suspeito, mas não rejeite só com base no SPF. ?all é neutro e não dá quase nada aos destinatários.

Dois limites pegam muita gente. A seção 4.6.4 da RFC 7208 diz que as implementações "DEVEM limitar o número total" de termos que fazem consultas DNS (include, a, mx, ptr, exists e redirect) a 10, e ultrapassar esse número é um erro permanente. Ela também diz que as consultas que não retornam nada, chamadas de "void lookups", DEVERIAM ser limitadas a duas. Se você foi empilhando includes ao longo dos anos, o nosso exemplo prático de como corrigir excesso de consultas DNS mostra como voltar para dentro do limite, e erros comuns de SPF cobre o resto.

O que o SPF não faz: ele não diz nada sobre o endereço From que o leitor vê. Um spammer pode usar o próprio domínio no MAIL FROM, passar no SPF para ele e colocar o seu domínio no cabeçalho From. E quando uma mensagem é encaminhada, o IP do servidor que encaminha não está no seu registro, então o SPF geralmente falha.

DKIM: uma assinatura que viaja com a mensagem

O DKIM anexa uma assinatura criptográfica a cada mensagem. O servidor de envio assina cabeçalhos selecionados e o corpo com uma chave privada e acrescenta um cabeçalho DKIM-Signature. Duas tags desse cabeçalho são as que mais importam para entendê-lo:

• d= é o domínio que assina, o domínio que assume a responsabilidade pela mensagem.
• s= é o seletor, que diz ao destinatário onde encontrar a chave pública.

O destinatário busca a chave pública no DNS em selector._domainkey.domain, por exemplo:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

v=DKIM1 é a versão, k=rsa o tipo de chave e p= a própria chave pública (cortada aqui). Se a assinatura for validada, o destinatário sabe que o domínio d= assinou a mensagem e que as partes assinadas não foram alteradas. Um p= vazio significa que a chave foi revogada.

Como a assinatura fica dentro da mensagem, o DKIM sobrevive ao encaminhamento comum. Ele quebra quando um intermediário altera o conteúdo assinado, o que listas de discussão que adicionam rodapés ou tags no assunto costumam fazer.

O tamanho da chave importa. A RFC 8301 diz que quem assina "DEVE usar chaves RSA de pelo menos 1024 bits" e "DEVERIA usar chaves RSA de pelo menos 2048 bits". O nosso estudo sobre tamanho de chave DKIM mediu quantos domínios ainda usam chaves de 1024 bits. O verificador de DKIM encontra os seletores mais comuns automaticamente e decodifica o tamanho da chave. Os guias de configuração das duas maiores plataformas estão aqui: Google Workspace e Microsoft 365.

O que o DKIM não faz: assim como o SPF, ele autentica o domínio d=, que pode ser qualquer domínio. Uma mensagem assinada por d=bulk-sender.net com From: you@example.com passa no DKIM, mas não prova nada sobre example.com.

DMARC: ligando os dois ao endereço From

O DMARC responde à pergunta que os outros dois deixam em aberto: esta mensagem veio mesmo do domínio que está no cabeçalho From? Uma mensagem passa no DMARC quando uma destas condições é verdadeira:

1. O SPF passa e o domínio do MAIL FROM se alinha com o domínio do From, ou
2. O DKIM passa e o domínio d= se alinha com o domínio do From.

Uma aprovação alinhada basta. Tanto a RFC 7489 quanto a RFC 9989 definem assim.

Como funciona o alinhamento

O alinhamento tem dois modos, definidos separadamente para o SPF (aspf) e para o DKIM (adkim):

• Relaxado (r, o padrão): os dois domínios compartilham o mesmo domínio organizacional. bounces.example.com se alinha com example.com.
• Estrito (s): os dois domínios precisam ser idênticos.

Veja como isso funciona numa newsletter enviada por uma plataforma de terceiros:

Cabeçalho	Valor	Resultado
From	news@example.com	O domínio que o DMARC protege
MAIL FROM	bounce-123@mail.platform.net	SPF passa para platform.net, não alinhado
DKIM d=	example.com (DKIM personalizado configurado)	DKIM passa, alinhado
DMARC		Passa, via DKIM

Tire o DKIM personalizado e a plataforma passa a assinar com o próprio domínio. Agora SPF e DKIM passam, nenhum dos dois está alinhado, e o DMARC falha. Essa é a falha de DMARC mais comum em domínios pequenos: tudo "passa" nos cabeçalhos e a mensagem mesmo assim falha. O nosso guia para ler cabeçalhos de e-mail mostra onde encontrar cada um desses valores.

O registro DMARC

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• v=DMARC1 precisa vir primeiro.
• p= é a política para os e-mails que falham: none (só monitorar), quarantine (tratar como suspeito, normalmente pasta de spam) ou reject (recusar).
• rua= é para onde os destinatários enviam os relatórios agregados diários, que mostram todas as origens que enviam em nome do seu domínio e se passaram ou não.

p=none não muda nada na entrega. Ele existe para que você colete relatórios e corrija os remetentes legítimos antes de aplicar a política. Os nossos exemplos comentados de registros DMARC cobrem as outras tags, e como passar de p=none para p=reject cobre a implantação.

O que mudou em 2026

A RFC 9989, publicada em maio de 2026, substituiu a RFC 7489 como padrão do DMARC. Ela levou o DMARC de Informational para Standards Track, removeu as tags pct, rf e ri, acrescentou uma tag t para modo de teste e uma tag psd, e incorporou a tag np para subdomínios inexistentes. Ela também troca a dependência da Public Suffix List por um "DNS Tree Walk" para encontrar o domínio organizacional. Para a maioria dos donos de domínio, a mudança prática é pequena: registros com pct continuam funcionando nos destinatários que ainda não se atualizaram, e a nova abordagem de teste está explicada no guia de implantação citado acima.

O que Gmail, Yahoo e Microsoft exigem

Os três grandes provedores de caixa postal publicam hoje regras de autenticação, lidas nas próprias páginas deles em outubro de 2026:

Provedor	Todos os remetentes	Remetentes em massa
Gmail	"Configure SPF ou DKIM"	SPF e DKIM; registro DMARC, p=none aceitável; From alinhado com o domínio do SPF ou do DKIM (cerca de 5.000+ mensagens por dia para contas pessoais do Gmail)
Yahoo	"Implemente pelo menos SPF ou DKIM"	SPF e DKIM; "uma política DMARC válida com pelo menos p=none" e o DMARC precisa passar; alinhamento relaxado aceitável
Outlook.com	Não especificado	Mais de 5.000 e-mails por dia: SPF precisa passar, DKIM precisa passar, DMARC pelo menos p=none alinhado com SPF ou DKIM

(As citações são traduções livres dos originais em inglês.)

Repare na redação da Microsoft. O DMARC em si se satisfaz com uma aprovação alinhada, mas as regras de alto volume da Microsoft pedem que SPF e DKIM passem os dois. Um domínio que só passa no DMARC via DKIM cumpre a regra do Gmail e pode não cumprir a da Microsoft. Os detalhes estão em os requisitos do Gmail e do Yahoo e os requisitos do Outlook.

Como checar o seu domínio em cinco minutos

1. SPF. Passe o seu domínio no verificador de SPF. O ideal é exatamente um registro v=spf1, com todos os serviços que enviam por você incluídos, 10 consultas DNS ou menos e terminando em -all ou ~all.
2. DKIM. Rode o verificador de DKIM. O ideal é uma chave válida para cada plataforma que envia em nome do seu domínio, com 2048 bits onde a plataforma permitir. Se uma plataforma não aparecer, procure o seletor dela na documentação de configuração.
3. DMARC. Rode o verificador de DMARC. O ideal é um registro em _dmarc, uma política e um endereço rua que alguém de fato leia. Se você não tem registro, o gerador de DMARC monta um.
4. Alinhamento. Envie uma mensagem de cada plataforma para um endereço do Gmail, abra "Mostrar original" e confirme que o SPF ou o DKIM passa para o seu próprio domínio, não para o da plataforma.
5. Acompanhe os relatórios. Os relatórios agregados vão revelar remetentes que você esqueceu, como um sistema de cobrança ou um CRM, antes de você passar para a aplicação da política.

Os três registros custam pouco para publicar e só têm valor juntos. SPF e DKIM provam que algum domínio enviou a mensagem; o DMARC é o que faz desse domínio o seu.