Verificador DKIM

Verifique o DKIM de um domínio como os servidores de destino encontram os registros, ou cole um e-mail para testar a assinatura: quais seletores respondem, quem assina, qual a força de cada chave e se ela se alinha com o DMARC.

Fontes: 140 seletores comuns de 67 provedores de e-mail, consultados pelo Google Public DNS (com a Cloudflare por trás) · verificações de chave das RFC 6376 e RFC 8301 · e-mails verificados no seu navegador · nada sobre você é armazenado

Como verificar um registro DKIM?

Digite o domínio acima: o verificador consulta os 140 seletores que os provedores de e-mail usam, mostra cada chave que encontra com o tamanho e o provedor e diz com honestidade quando não acha nenhuma. Sabe o seletor? Escolha Domínio + seletor e ele é verificado primeiro.

À mão você precisa do seletor, porque o DNS não consegue listá-los: dig +short TXT selector._domainkey.example.com, ou nslookup -type=TXT com o mesmo nome no Windows. O seletor é o s= no DKIM-Signature de qualquer e-mail (RFC 6376 §3.6.2.1).

O dig mostra o texto, não o que ele significa: não decodifica o tamanho da chave, não segue o CNAME do provedor nem distingue um espaço em espera de um quebrado. É isso que este verificador de registro DKIM acrescenta.

dig +short TXT selector._domainkey.example.com

Todas as strings TXT no nome: una-as para ler a chave.

O que o dig mostra e o que não mostra

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1O nome é selector._domainkey.domainSem seletor, sem resposta: o DNS não tem um “listar todas as chaves”.
  2. 2Duas strings, um registroUma string TXT guarda 255 bytes, então uma chave de 2048 bits é dividida; os servidores de destino as unem sem nada entre elas.
  3. 3O tamanho real da chaveO openssl decodifica p=: 2048 bits é o que a RFC 8301 pede.
  4. 4Um CNAME para o provedorNenhum TXT por trás: o espaço em espera do Microsoft 365, não um erro.
A chave de google.com e o selector1 de microsoft.com como o DNS da Cloudflare os devolveu em 25 de outubro de 2026.

Lendo o resultado: a busca de seletores

A resposta vem primeiro, em uma frase. Abaixo dela, quem assina e a própria chave, cada tag colorida sobre os caracteres exatos e o tamanho da chave na escala da RFC 8301; sobre o azul-marinho, cada seletor que a verificação consultou, para você ver o que foi tentado.

Sem pontuação: uma chave desativada ou o seletor vazio em espera de um provedor é normal, e “não encontrado entre os seletores comuns” nunca significa “sem DKIM”.

Verificação DKIM de github.com: doze chaves de seis provedores, a busca de seletores e o medidor do tamanho da chaveVerificação DKIM de github.com: doze chaves de seis provedores, a busca de seletores e o medidor do tamanho da chaveO vereditoUma frase: quantas chaves e o que precisa ser feito.Quem assinaUm cartão por provedor, achado pelo CNAME ou por um seletor documentado. Cada seletor abre a sua chave.A chaveCada tag colorida sobre os seus caracteres e o tamanho da chave na escala da RFC 8301.A busca de seletoresCada nome consultado, aceso quando responde: verde uma chave, âmbar 1024 bits, tracejado um espaço em espera.Alinhamento DMARCSe uma chave com o d= deste domínio se alinha com a política DMARC dele.
Uma verificação DKIM de github.com: o veredito, quem assina, a chave dividida em tags com o tamanho dela e, sobre o azul-marinho, cada seletor que a verificação consultou. Selecione um número para ver o que cada parte mostra.

O que é DKIM?

O DKIM (DomainKeys Identified Mail) é uma assinatura que o servidor de envio acrescenta a cada mensagem e que os servidores de destino verificam com uma chave pública que o domínio publica no DNS (RFC 6376). Uma assinatura DKIM válida prova duas coisas: o domínio em d= a assinou, e as partes assinadas não mudaram desde então.

O remetente calcula o hash do corpo em bh= e assina os cabeçalhos escolhidos mais esse hash com a chave privada em b=. O servidor de destino lê d= e s=, busca a chave em s._domainkey.d e refaz os dois cálculos. Um byte mudado no corpo, ou em um cabeçalho assinado, e ela falha.

O DKIM não diz nada sobre o que fazer quando falha, e qualquer domínio pode assinar. Isso é trabalho do DMARC: ele pede uma assinatura aprovada cujo d= coincida com o domínio do From:.

Uma mensagem, assinada no remetente e verificada no destino

O servidor de example.comassina com a chave privada
a mensagem, com o DKIM-Signature
O servidor de destinoGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

A mensagem como foi enviada

  • O hash do corpo coincide com bh=
  • A assinatura dos cabeçalhos confere

dkim=pass header.d=example.com

A mesma mensagem, com o Subject editado no caminho

  • O hash do corpo coincide com bh=
  • A assinatura dos cabeçalhos não confere

dkim=fail (signature-mismatch)

Os dois resultados são do motor, a partir do e-mail de exemplo desta página e do mesmo e-mail com o Subject mudado depois de assinado. RFC 6376 §3.7, RFC 8301.

O que é um seletor DKIM e como achar o meu?

Um seletor é o nome de uma chave DKIM: o s= em uma assinatura e a primeira parte do nome DNS em que a chave fica (s1._domainkey.github.com). Um domínio pode ter quantos quiser: um por provedor, por servidor, por ano (RFC 6376 §3.1).

Para achar o seu, abra qualquer e-mail que o domínio enviou e veja o original: Mais (⋮) › Mostrar original, no Gmail, lista o DKIM-Signature, e o s= dele é o seletor. Ou cole o e-mail em Verificar um e-mail acima.

A maioria dos provedores usa nomes fixos, então a busca os acha. Amazon SES, Postmark, SparkPost e HubSpot geram um nome por conta, que só um e-mail ou o painel do provedor diz.

Da assinatura à chave, e os nomes que os provedores usam

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegoogleo administrador pode mudar o prefixo
Microsoft 365selector1 · selector2CNAMEs para o tenant; um ativo, um em espera
Twilio SendGrids1 · s2CNAMEs para u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAMEs para dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3três CNAMEs, um preenchido por vez
Proton Mailprotonmail · 2 · 3CNAMEs para domains.proton.ch
Amazon SES3 tokens aleatórios32 caracteres aleatórios cada: não dá para adivinhar
Postmark20240101000000pmuma data e “pm”: não dá para adivinhar
SparkPostscph + MMAAscph e o mês em que a chave foi feita
HubSpoths1-<HubID>o número da sua conta
O s1 de github.com como o DNS da Cloudflare o devolveu em 25 de outubro de 2026. Nomes dos provedores da documentação deles (67 provedores, 140 seletores na busca).

Formato do registro DKIM: todas as tags explicadas

Um registro DKIM é um registro TXT de pares tag=valor separados por ponto e vírgula; só p=, a chave pública, é obrigatória. v=DKIM1 é opcional, mas, quando existe, deve vir primeiro (RFC 6376 §3.6.1).

k= diz o tipo da chave (rsa, a menos que diga ed25519), t= leva flags (y teste, s estrito), h= limita os hashes e s= os serviços. Um p= vazio revoga a chave de propósito.

Os nomes das tags diferenciam maiúsculas de minúsculas, e uma tag repetida invalida o registro. Tags desconhecidas são ignoradas.

O registro, tag por tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagDefineValoresPadrãoNota
v=VersãoDKIM1DKIM1recomendada; primeira se existir
k=Tipo de chaversa · ed25519rsatipos desconhecidos: chave ignorada
p=Chave pública (base64)a chave, ou vazioobrigatóriavazio = revogada
t=Flagsy teste · s estritonenhumay: tratada como sem assinatura
h=Hashes permitidossha256 (sha1 proibido)todossó sha1 falha (RFC 8301)
s=Tipo de serviço* · email*só outros serviços: ignorada
n=Notas para pessoasqualquer texto–nunca lido pelo software

Qual o tamanho de p= e de quantas strings TXT ele precisa

RSA 1024216 caracteres · 1 string TXT
RSA 2048392 caracteres · 2 strings TXT
RSA 3072564 caracteres · 3 strings TXT
RSA 4096736 caracteres · 3 strings TXT
Ed2551944 caracteres · 1 string TXT

limites de string TXT de 255 bytes (contando “v=DKIM1; k=rsa; p=”)

Os tamanhos de p= são de chaves SubjectPublicKeyInfo medidas. yahoo.com publica a chave de 2048 bits em 4 strings: qualquer divisão serve, já que os servidores de destino as unem sem nada entre elas (RFC 6376 §3.6.2.2).

Chaves DKIM de 1024 ou 2048 bits, e como fazer a rotação

Use RSA de 2048 bits. A RFC 8301 ainda exige que os verificadores aceitem chaves de 1024 bits, mas pede aos remetentes pelo menos 2048 e manda os verificadores rejeitarem chaves abaixo de 1024 bits. O M3AAWG chama 1024 bits de “no limite do ataque” e relata uma chave de 512 bits quebrada em cerca de 72 horas por cerca de US$ 75.

Uma chave Ed25519 é pequena (44 caracteres de p=) e, por compatibilidade com versões anteriores, a RFC 8463 permite que quem assina acrescente uma assinatura RSA ao lado dela: dois seletores, duas assinaturas (RFC 8463).

Faça a rotação publicando a nova chave em um novo seletor, trocando a assinatura, mantendo a chave antiga de 7 a 30 dias para os e-mails em trânsito e depois esvaziando o p= dela. O M3AAWG sugere a cada seis meses. Provedores como Fastmail e Microsoft 365 fazem isso por você com seletores em espera.

Onde ficam chaves reais na escala da RFC 8301

FalhaVálida, passe para 2048BoaPode falhar em alguns servidores de destino
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Rotação sem intervalo (M3AAWG)

  1. Dia 0Publique a nova chave em um novo seletor
  2. Dia 1+Passe a assinar com ela
  3. +7–30 diasMantenha a chave antiga para os e-mails em trânsito
  4. DepoisEsvazie o p= antigo; não reutilize o nome
fastmail.comfm1p= vaziofm22.048fm3p= vaziotrês CNAMEs, um preenchido: a rotação é uma mudança de DNS do lado do Fastmail
Tamanhos de chave lidos do DNS em 25 de outubro de 2026, decodificados de cada p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Por que o DKIM falha? Hash do corpo, encaminhamento e listas de e-mail

O DKIM falha quando os bytes assinados mudaram, quando a chave não é encontrada ou quando a chave não combina com a assinatura. O encaminhamento que deixa a mensagem inalterada mantém o DKIM intacto (ao contrário do SPF); as listas de e-mail em geral o quebram, porque acrescentam rodapés ou etiquetam o assunto.

O verificador desta página confere o hash do corpo e a assinatura dos cabeçalhos separadamente, então distingue um rodapé acrescentado no caminho de uma falsificação.

O hash do corpo não confere

Uma lista de e-mail acrescentou um rodapé de 153 bytes. Os cabeçalhos ainda conferem com a chave de project.example, então isso não é falsificação.

Correção Listas que mantêm o corpo intacto, ou ARC (RFC 8617) para que os servidores de destino seguintes vejam o resultado original.

body-hash-mismatch

A assinatura não confere

Um cabeçalho assinado mudou depois da assinatura (uma lista que acrescenta o próprio nome ao Subject), ou o seletor agora tem outra chave.

Correção Não reescreva cabeçalhos assinados; publique uma nova chave em um novo seletor em vez de substituir uma.

signature-mismatch

Sem chave para a assinatura

s=2023old._domainkey.shop.example é NXDOMAIN: o seletor foi apagado enquanto ainda havia e-mails assinados com ele em trânsito.

Correção Mantenha as chaves antigas publicadas de 7 a 30 dias depois da troca; esvazie o p= em vez de apagar.

key-not-found

Encaminhamento: um encaminhador que repassa a mensagem sem mudá-la mantém o DKIM válido, e é por isso que o DMARC em geral sobrevive ao encaminhamento pelo DKIM mesmo quando o SPF falha.

DKIM x SPF x DMARC

O SPF diz quais servidores podem enviar por um domínio, o DKIM prova que um domínio assinou a mensagem e que ela não foi alterada, e o DMARC liga os dois ao endereço From: e diz o que fazer quando falham.

Eles respondem a perguntas diferentes, então você precisa dos três: Gmail e Yahoo exigem SPF e DKIM de quem envia em massa, além de um registro DMARC, e a RFC 9989 pede aos domínios em p=reject que assinem com DKIM em vez de depender do SPF.

Três registros, três perguntas

Três registros, três perguntasSPFDKIMDMARC
O que provaEste servidor pode enviar pelo domínio do MAIL FROMO domínio d= assinou; as partes assinadas não mudaramO From: coincide com um domínio que passou no SPF ou no DKIM
Onde ficaTXT em github.comTXT em s1._domainkey.github.comTXT em _dmarc.github.com
github.com hojev=spf1 … ~all12 chaves, 6 provedoresp=quarantine; sp=reject
Sobrevive ao encaminhamentoNão: o IP do encaminhador não está listadoSim, quando a mensagem chega sem alteraçãoSim, por uma aprovação de DKIM alinhada
Quebra quandoum novo serviço de envio não está no registroo corpo ou um cabeçalho assinado mudanenhum dos dois passa para o domínio do From:
Os registros de github.com como lidos em 25 de outubro de 2026.

Como ler o cabeçalho DKIM-Signature de um e-mail

Abra a mensagem original e ache o cabeçalho DKIM-Signature: d= é quem assinou, s= é qual chave, h= lista os cabeçalhos assinados, e bh= e b= são os dois hashes que um servidor de destino confere.

O veredito do servidor de destino é um cabeçalho separado, acrescentado na chegada: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. A página Mostrar original do Gmail (em inglês) o resume como “DKIM: 'PASS' with domain example.com”.

Uma mensagem pode levar várias assinaturas, uma por quem assina (o seu domínio e o seu serviço de e-mail, ou uma lista de e-mail). Basta uma assinatura aprovada com d= alinhado para o DMARC.

A assinatura do e-mail de exemplo, tag por tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Versão v=sempre 1
  2. 2Algoritmo a=rsa-sha256 (ou ed25519-sha256)
  3. 3Canonicalização c=relaxed tolera quebras de linha refeitas
  4. 4Domínio de assinatura d=comparado com o From: para o DMARC
  5. 5Seletor s=a chave em s._domainkey.d
  6. 6Assinado em t=hora Unix: 24 de out. de 2026, 09:12
  7. 7Cabeçalhos assinados h=from duas vezes = sobreassinado
  8. 8Hash do corpo bh=SHA-256 do corpo canônico
  9. 9Assinatura b=sobre os cabeçalhos de h= e este campo

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

O e-mail de exemplo inventado que esta página carrega (example.com, uma chave feita para ele), verificado pelo motor.

Verificador DKIM: perguntas frequentes

O que é um registro DKIM?

Um registro DKIM é um registro TXT que publica a chave pública de um domínio em selector._domainkey.domain, como google._domainkey.example.com. Ele tem pares tag=valor: p= é a chave em base64 e é obrigatória, k= o tipo da chave, t= as flags. Os servidores de destino o buscam para verificar o DKIM-Signature dos e-mails recebidos. Um domínio pode publicar vários, um por seletor, em geral um por serviço de envio.

Como achar o meu seletor DKIM?

Abra qualquer e-mail que o domínio enviou, veja a mensagem original e ache o cabeçalho DKIM-Signature: o valor depois de s= é o seletor, e d= é o domínio. No Gmail, use Mais (⋮) › Mostrar original; no Outlook na web, Exibir › Exibir detalhes da mensagem. Ou cole o e-mail em Verificar um e-mail, acima, que lê s= e d= para você.

Por que o verificador não acha chave se os meus e-mails são assinados?

Porque o DNS não lista seletores: uma chave só é achada perguntando pelo nome exato dela. O verificador consulta os 140 nomes que os provedores usam; se o seu assina com outro (Amazon SES e Postmark geram um por conta), a busca não o vê. Acrescente o seletor do s= de um e-mail e ele é verificado primeiro, ou verifique um e-mail.

Uma chave DKIM de 1024 bits ainda serve?

Ainda funciona: a RFC 8301 exige que os verificadores aceitem chaves RSA de 1024 a 4096 bits, e Gmail e Yahoo definem 1024 bits como mínimo. Mas a RFC 8301 pede aos remetentes pelo menos 2048 bits, e o M3AAWG chama 1024 de no limite do ataque. Planeje uma rotação: Microsoft 365 e Google Workspace oferecem chaves de 2048 bits. A RFC 8301 manda os verificadores rejeitarem chaves abaixo de 1024 bits.

O que significa um p= vazio?

Um p= vazio significa que a chave foi revogada: as assinaturas com esse seletor falham, exatamente como se a chave não existisse. Em geral é de propósito. O Google mantém assim os seletores antigos com data, e o Fastmail e o Microsoft 365 mantêm seletores vazios em espera para alternar. Só é problema se for o seletor com que os seus e-mails são assinados hoje.

O que significa t=y em um registro DKIM?

t=y marca a chave como em teste: os servidores de destino devem tratar o e-mail assinado com ela como sem assinatura, mesmo que a assinatura confira. Serve para a primeira configuração e muitas vezes é esquecido. t=s é diferente: significa estrito, então o i= nas assinaturas deve ser exatamente o domínio de assinatura, não um subdomínio. Alguns serviços de e-mail publicam t=s nas chaves deles; as chaves do SendGrid para github.com têm esse valor.

Por que o DKIM falha com “body hash did not verify”?

O corpo que o servidor de destino calculou não coincide com o valor de bh= na assinatura, então o corpo mudou depois de assinado. Listas de e-mail que acrescentam rodapé, gateways de segurança que reescrevem links e avisos legais acrescentados por um servidor causam isso. Se a assinatura dos cabeçalhos ainda confere, a mensagem é genuína, mas modificada; o verificador desta página confere as duas separadamente.

O DKIM sobrevive ao encaminhamento de e-mail?

Em geral, sim. Um encaminhador que repassa a mensagem sem mudá-la mantém a assinatura válida, porque o DKIM assina o conteúdo, não o caminho. Essa é a diferença para o SPF, que falha no endereço IP do encaminhador. Encaminhadores que alteram a mensagem, como listas de e-mail que acrescentam rodapés ou etiquetas no assunto, quebram o DKIM; o ARC permite que eles atestem o resultado original.

Preciso de DKIM se já tenho SPF?

Sim. O SPF quebra quando o e-mail é encaminhado e cobre só o endereço MAIL FROM, que fica oculto, enquanto o DKIM sobrevive ao encaminhamento e pode se alinhar com o domínio do From: que o DMARC confere. Gmail e Yahoo exigem os dois de quem envia em massa, o Outlook.com desde maio de 2025, e a RFC 9989 pede aos domínios com p=reject que assinem os e-mails com DKIM.

Com que frequência devo fazer a rotação das chaves DKIM?

O M3AAWG recomenda pelo menos a cada seis meses. Publique a nova chave em um novo seletor, passe a assinar com ela, mantenha a chave antiga publicada de 7 a 30 dias para que os e-mails em trânsito ainda sejam verificados e depois esvazie o p= dela em vez de apagá-la. Nunca reutilize o nome de um seletor. Provedores hospedados com seletores CNAME fazem a rotação das chaves por você.

O meu e-mail é enviado quando eu o verifico aqui?

Não. Este validador DKIM verifica o e-mail no seu navegador: o DNS público é consultado só pelos nomes das chaves (s._domainkey.d), e o dnsrobot.net só pela política DMARC do domínio do From e dos domínios de assinatura. A única exceção é uma assinatura Ed25519 que o navegador não consegue verificar: a página pergunta antes de enviar o e-mail uma vez ao nosso servidor, que o verifica na memória e não armazena nada.

Posso usar uma chave DKIM Ed25519?

Sim. A RFC 8463 a define e exige que os verificadores a aceitem. Por compatibilidade com versões anteriores, publique-a no próprio seletor ao lado de uma chave RSA e assine cada mensagem duas vezes, como o archlinux.org faz com dkim-ed25519 e dkim-rsa: os servidores de destino que não verificam Ed25519 ainda têm a assinatura RSA. Microsoft 365 e Google Workspace oferecem só chaves RSA.