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
Consulta os 140 seletores que os provedores de e-mail usam em selector._domainkey. mais o domínio, já que o DNS não os lista
ou solte um arquivo .eml nesta caixa
Verificado no seu navegador: o e-mail fica neste dispositivo, a menos que tenha uma assinatura Ed25519 que este navegador não consegue verificar e você escolha enviá-lo ao nosso servidor. Só o nome da chave (s._domainkey.d) vai para o DNS público, e os domínios do From e da assinatura vão para o dnsrobot.net, para a política DMARC deles.
Experimente
O que você vai ver
Cada DKIM-Signature: quem assinou, com qual chave e sobre quais cabeçalhos
O hash do corpo e a assinatura dos cabeçalhos verificados separadamente, para que um rodapé acrescentado no caminho não seja chamado de falsificação
Se o d= se alinha com o domínio do From para o DMARC
Riscos que uma aprovação pode esconder: l=, From não sobreassinado, chave abaixo de 2048 bits
O que sai deste dispositivo quando você verifica
Este dispositivo
O e-mailVerificaçõesWebCrypto
selector._domainkey.d TXT?o nome da chave
From · d=domínios do From e do d=
DNS público
Cloudflare, Google como reserva
dnsrobot.net
a política DMARC
O e-mail em si fica atrás da linha verde: só nomes saem, e as respostas deles voltam. A única exceção é escolha sua: uma assinatura Ed25519 que este navegador não consegue verificar pode ser enviada ao nosso servidor, que a verifica na memória e não guarda nada.
Um e-mail inventado, assinado por example.com, para ver cada parte
Publicidade
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.
1O nome é selector._domainkey.domainSem seletor, sem resposta: o DNS não tem um “listar todas as chaves”.
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.
3O tamanho real da chaveO openssl decodifica p=: 2048 bits é o que a RFC 8301 pede.
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”.
O 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.
Publicidade
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 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
32 caracteres aleatórios cada: não dá para adivinhar
Postmark
20240101000000pm
uma data e “pm”: não dá para adivinhar
SparkPost
scph + MMAA
scph e o mês em que a chave foi feita
HubSpot
hs1-<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.
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).
Publicidade
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
5121.0242.0484.096
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)
Dia 0Publique a nova chave em um novo seletor
Dia 1+Passe a assinar com ela
+7–30 diasMantenha a chave antiga para os e-mails em trânsito
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
chavecorpocabeçalhos
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
chavecorpocabeçalhos
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
chavecorpocabeçalhos
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 perguntas
SPF
DKIM
DMARC
O que prova
Este servidor pode enviar pelo domínio do MAIL FROM
O domínio d= assinou; as partes assinadas não mudaram
O From: coincide com um domínio que passou no SPF ou no DKIM
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.
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.