DKIM "No Key for Signature": correções de seletores e rotação (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

“No key for signature” significa que o recetor consultou o registo DNS para que a sua assinatura DKIM aponta — selector._domainkey.yourdomain — e não encontrou chave: nunca foi publicada, ou foi apagada a meio de uma rotação. Publique o seletor que o seu assinador realmente usa. Só 10.092.481 domínios — 3,87% — completam a tríade SPF+DKIM+DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios classificados.

A correção é um registo DNS, encontrado num cabeçalho. Leia as tags s= e d= de um cabeçalho DKIM-Signature real para saber com que seletor o seu correio está assinado, publique (ou repare) exatamente esse registo, e prefira a delegação por CNAME para que o seu fornecedor rode as chaves por si. Depois rode segundo o runbook abaixo — este erro normalmente significa que alguém apagou um seletor antigo cedo demais.

O que significa “dkim no key for signature”?

Cada assinatura DKIM transporta duas tags que dizem ao recetor onde ir buscar a chave pública: d= (domínio de assinatura) e s= (seletor). O recetor consulta um nome DNS construído a partir delas — s._domainkey.d — para obter a chave. “No key for signature” significa que essa consulta voltou vazia: a assinatura existe, mas a chave que ela nomeia não.

A formulação aparece em cabeçalhos Authentication-Results e em relatórios agregados DMARC — a redação exata varia por recetor, mas duas variantes importam:

String de resultado (fragmento, tal como amplamente observado)	O que realmente aconteceu	Transitório?
`dkim=temperror (no key for signature)`	A consulta DNS falhou ou expirou — o recetor não conseguiu obter resposta nenhuma	Sim — as repetições costumam passar; investigue só se persistir
`dkim=permerror (no key for signature)`	A consulta DNS teve sucesso e a resposta foi “não existe tal registo” — o seletor está genuinamente ausente	Não — o registo está em falta até você o publicar

Um temperror pontual é o clima do DNS. Um permerror — ou um temperror a repetir-se ao longo de dias e de recetores — significa que o registo para que a assinatura aponta não está na sua zona. É disso que trata este guia.

A consequência: uma assinatura não verificável conta como DKIM nenhum, e o DMARC recua para o SPF sozinho — e o SPF parte-se com o reencaminhamento. Se a assinatura está presente mas inválida em vez de em falta (body hash, chave estropiada), é uma falha diferente — veja “DKIM signature not valid”.

Como descubro com que seletor o meu correio está assinado?

Não adivinhe pela documentação do fornecedor — leia-o numa mensagem real:

Envie uma mensagem do sistema afetado para uma caixa de correio que controle (um endereço Gmail serve bem).
Abra o código-fonte (“Mostrar original” no Gmail, “Ver origem da mensagem” no Outlook).
Encontre o cabeçalho DKIM-Signature: e leia duas tags: s= é o seletor, d= é o domínio de assinatura. Um exemplo ilustrativo: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
O registo que o recetor consulta é s._domainkey.d — aqui, mail2026._domainkey.yourdomain.com. Verifique você mesmo: dig TXT mail2026._domainkey.yourdomain.com +short. Resposta vazia = o erro é real para todos os recetores.
Repita por sistema de envio. Uma mensagem pode transportar várias assinaturas DKIM — fornecedor de caixa de correio, ferramenta de newsletters, helpdesk — cada uma com o seu par s=/d= e o seu registo. Corrija a que falha, e anote o d= dela: só uma assinatura cujo d= corresponda ao seu domínio do From ajuda o DMARC.

Porque é que o registo do seletor está em falta?

Quatro causas explicam quase todos estes erros — verifique-as por esta ordem:

Nunca foi publicado. O assinador foi ligado (ou veio ligado por omissão) com um seletor que ninguém adicionou ao DNS. Comum com ferramentas novas e gateways que assinam inesperadamente.
Foi apagado a meio de uma rotação. Alguém “fez limpeza” ao seletor antigo enquanto mensagens assinadas com ele ainda estavam em trânsito, em fila de reenvio ou à espera de reencaminhamento. Esse correio já está assinado com s=old; apagar old._domainkey parte retroativamente todas essas mensagens.
A interface do seu DNS estropiou um alvo de CNAME. Muitos fornecedores delegam via CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), e muitos painéis de DNS acrescentam silenciosamente a sua zona ao alvo — guardando s1.domainkey.u123.esp.com.yourdomain.com, que não resolve para nada. Verifique o alvo: dig CNAME s1._domainkey.yourdomain.com +short. A mesma armadilha morde durante migrações de ferramentas — veja DKIM a falhar depois de mudar de ferramenta de email.
O fornecedor rodou, a sua zona não. Uma chave do fornecedor colada como registo TXT estático (em vez dos CNAMEs deles) fica órfã com a rotação agendada deles — o assinador passa para um seletor que você nunca publicou. Só 51,84% dos 261 milhões de domínios do censo apresentam uma chave DKIM detetável no momento da verificação (dados a 2026-06-29).

Como corrijo “no key for signature”?

Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Lê os seus registos DKIM, SPF e DMARC em produção e mostra o que os recetores realmente veem — incluindo se o seletor resolve e se um alvo de CNAME foi estropiado.
Publique o seletor que o assinador realmente usa — o valor s= do cabeçalho, não o de um runbook antigo. Obtenha o registo na consola de administração do fornecedor (configuração de DKIM no Google Workspace · configuração de DKIM no Microsoft 365) e adicione-o exatamente em s._domainkey.yourdomain.com.
Prefira a delegação por CNAME a colar uma chave TXT. Se o seu fornecedor oferecer CNAMEs de DKIM, use-os: a chave vive na zona deles, portanto rodam-na sem você voltar a tocar no DNS — a causa 4 torna-se impossível. As plataformas de newsletters funcionam quase todas assim; veja emails de Mailchimp/Brevo/Klaviyo a falhar o DMARC.
Verifique a partir de fora do seu painel. dig TXT s._domainkey.yourdomain.com +short (ou dig CNAME … para seletores delegados) a partir de uma máquina fora da sua rede. O painel mostrar o registo não prova nada se a zona servir outra coisa.
Volte a verificar e a enviar a mensagem de teste. O Authentication-Results deve agora mostrar dkim=pass. Depois trabalhe o que mais a verificação assinalar na página corrigir o DKIM — uma assinatura que passa mas não alinha com o seu domínio do From continua a falhar o DMARC.

Como rodo as chaves DKIM sem causar este erro?

A rotação é onde as configurações que funcionavam se partem. A regra que o evita: um seletor só se apaga depois de a última mensagem assinada com ele ter escoado — nunca no momento da transição. O correio assinado vive mais do que pensa: as filas de reenvio correm durante dias, e as mensagens reencaminhadas são reverificadas sempre que se movem.

Passo	Ação	Condição antes do passo seguinte
1. Adicionar	Publique o seletor novo (`s2._domainkey…`) ao lado do antigo	O `dig` confirma que resolve a partir de fora
2. Mudar	Aponte o assinador para o seletor novo	A mensagem de teste mostra `s=s2` e `dkim=pass`
3. Esperar	Deixe o seletor antigo publicado enquanto o tráfego em trânsito, em fila e reencaminhado escoa	≥ 7 dias; acompanhe os relatórios agregados DMARC até o seletor antigo deixar de aparecer
4. Retirar	Remova a chave antiga — ou melhor, republique-a com uma tag `p=` vazia: “retirada”, não “nunca existiu”	Nunca comece isto na transição — a eliminação prematura é a causa n.º 1 de “no key for signature”

Com delegação por CNAME, o seu fornecedor executa exatamente este runbook dentro da própria zona e você nunca o vê — o argumento mais forte a favor de delegar.

Perguntas frequentes

“No key for signature” é um temperror ou um permerror? As duas strings existem: temperror é uma consulta DNS que falhou ou expirou — transitória, muitas vezes desaparece na repetição — enquanto permerror significa que o DNS respondeu “não existe tal registo”. Um temperror a repetir-se em vários recetores normalmente acaba por ser também um registo genuinamente em falta. Verifique com dig e confie na resposta, não no rótulo.

Este erro significa que alguém está a fazer spoofing do meu domínio? Não — um falsificador não assinaria com o seu seletor. Significa que o seu próprio correio transporta uma assinatura que os recetores não conseguem verificar, portanto conta como não assinado e o DMARC apoia-se no SPF sozinho. A autenticação completa e alinhada é rara: só 10.092.481 de 261.086.232 domínios (3,87%) completaram a tríade SPF+DKIM+DMARC no censo do Defaults.Exposed (dados a 2026-06-29).

Posso simplesmente apagar o seletor antigo assim que o novo funcionar? Não imediatamente. As mensagens assinadas com ele ainda estão em filas de reenvio e percursos de reencaminhamento; apagar a chave parte-as retroativamente. Mantenha o registo antigo pelo menos uma semana, acompanhe os seus relatórios DMARC até o seletor antigo deixar de aparecer, e depois retire-o — idealmente com um p= vazio em vez de o apagar.

O verificador do meu fornecedor diz que o DKIM está configurado, mas os recetores continuam a reportar falta de chave. Como? Quase sempre é a armadilha do alvo do CNAME: o seu painel de DNS acrescentou a sua zona ao alvo (…esp.com.yourdomain.com), portanto o registo existe mas aponta para lado nenhum. dig CNAME selector._domainkey.yourdomain.com +short mostra o alvo guardado tal e qual — compare-o carácter a carácter com o que o fornecedor pediu.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente ou para o seu empregador, feche o ciclo com evidência. Volte a executar a verificação gratuita assim que o seletor resolver e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, com o DKIM agora a verificar. É o comprovativo de que vão precisar na renovação do seguro cibernético e no próximo questionário de segurança de fornecedor — prova de um controlo a funcionar, não apenas um ticket fechado.

Verifique o seu DKIM gratuitamente

Veja se os seus seletores resolvem — e exatamente o que corrigir — em privado e apenas para o proprietário.

Verifique o seu domínio → · “DKIM signature not valid” → · Corrigir o DKIM → · Configurar o DKIM no Google Workspace → · Apenas dados agregados. Dados armazenados e processados na UE.