Defaults.Exposed › Correções › Guides

"DKIM Signature Not Valid" — as causas, pela ordem de verificaçã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.

“DKIM signature not valid” tem cinco causas comuns, que convém verificar por ordem: conteúdo modificado em trânsito, um registo de chave truncado, uma chave publicada que não corresponde ao assinador, o seletor errado, e canonicalização frágil. Só 10.092.481 de 261.086.232 domínios classificados (3,87%) detêm a tríade completa SPF + DKIM + DMARC com aplicação, segundo o censo do Defaults.Exposed (2026-06-29).

A ordem da correção importa porque a causa mais comum nem sequer está no seu DNS. Verifique primeiro o que alterou a mensagem em trânsito, depois trabalhe para dentro: a integridade do registo da chave, se ela corresponde ao que o seu servidor de correio está realmente a usar para assinar, o seletor, e por fim as definições de assinatura. A maioria das assinaturas inválidas fica corrigida no passo um ou dois.

O que significa realmente “DKIM signature not valid”?

Cada mensagem assinada com DKIM transporta um cabeçalho DKIM-Signature que nomeia um domínio (d=), um seletor (s=), um hash do corpo da mensagem (bh=), e uma assinatura criptográfica sobre o hash do corpo mais cabeçalhos selecionados (b=). O recetor obtém a sua chave pública no DNS em <selector>._domainkey.<domain>, recalcula ambos os hashes e verifica a assinatura (RFC 6376). “Signature not valid” é a linguagem de verificadores e cabeçalhos para: essa verificação correu e falhou — a chave foi encontrada, mas a matemática não bateu certo.

Essa última frase é ouro para o diagnóstico. Um verificador que não consegue encontrar a sua chave diz algo diferente — tipicamente um cabeçalho como dkim=fail (no key for signature) — e isso é um problema de seletor, coberto em DKIM “no key for signature” — correções de seletores e rotação. E um verificador que recalcula um hash de corpo diferente costuma dizê-lo explicitamente: body hash did not verify — a Microsoft reporta-o como dkim=fail (body hash did not verify), enquanto o Gmail apresenta muitas vezes o mesmo diagnóstico como dkim=neutral (body hash did not verify). Em qualquer caso aponta para modificação de conteúdo, coberta em “body hash did not verify” — o que alterou a sua mensagem. Leia a formulação exata no cabeçalho Authentication-Results antes de tocar em alguma coisa: diz-lhe qual das cinco causas tem em mãos.

Acertar nisto é raro: só 51,84% dos domínios classificados publicam sequer uma chave DKIM detetável no DNS, segundo o censo do Defaults.Exposed, e só 3,87% de 261 milhões de domínios classificados combinam SPF, DKIM e uma política DMARC com aplicação — a configuração que as regras de remetentes em massa agora assumem. O quadro etapa a etapa está no modelo de maturidade de adoção do SPF.

Quais são as cinco causas, por ordem?

A causa 1 está a negrito porque parte assinaturas em mensagens que foram assinadas na perfeição. Um gateway de segurança acrescenta um aviso legal, um rodapé de conformidade é carimbado depois da assinatura, uma lista de correio adiciona [listname] ao assunto — o corpo ou os cabeçalhos assinados mudam, os hashes deixam de corresponder, e a assinatura fica inválida sem culpa nenhuma do seu DNS. Se as falhas se correlacionam com correio que passou por um gateway, uma lista ou um salto de arquivo, comece por aí.

Como corrijo “DKIM signature not valid”?

1. Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Mostra se o registo publicado da sua chave está presente, bem formado e completo — separando “o seu DNS está partido” (causas 2–4) de “o seu DNS está bem, a mensagem está a ser alterada” (causa 1) num único passo.
2. Leia o cabeçalho Authentication-Results de uma mensagem que falha. body hash did not verify → causa 1, vá ao guia do body hash — os suspeitos do costume são rodapés de gateway e avisos legais, e a correção é assinar depois da modificação. no key for signature → causa 4, vá ao guia de seletores. Uma falha simples de assinatura → continue.
3. Verifique se a chave publicada está truncada. Consulte <selector>._domainkey.<yourdomain> como TXT (dig TXT selector._domainkey.example.com). Uma chave pública RSA de 2048 bits é mais longa do que o limite de 255 caracteres de uma única string TXT, portanto tem de ser publicada como várias strings entre aspas que os recetores concatenam — e as interfaces web dos fornecedores de DNS são famosas por truncarem silenciosamente a colagem, estropiarem a divisão, ou injetarem espaços e aspas no valor p=. Compare carácter a carácter com a chave que o seu assinador gerou; os nossos guias de configuração de DKIM cobrem as manias de cada fornecedor.
4. Confirme que a chave publicada corresponde ao assinador. Depois de uma rotação de chaves, migração de fornecedor ou reconexão de ESP, é comum o assinador ter uma chave privada nova enquanto o DNS ainda serve a chave pública antiga — cada assinatura é verificada contra a chave errada e falha. Copie de novo o registo atual da consola de administração do seu fornecedor. Melhor: onde o fornecedor oferecer delegação por CNAME, use-a — o fornecedor roda as chaves do lado dele e toda esta classe de falhas desaparece. E nunca apague um seletor antigo até o tráfego assinado com ele ter escoado.
5. Corrija as definições de assinatura, não só o registo. Defina a canonicalização como c=relaxed/relaxed, que tolera o reajuste de espaços e o redobramento de cabeçalhos que os servidores intermédios fazem legitimamente; a canonicalização simple falha com alterações que um humano nem consegue ver. E não use a tag l= de comprimento de corpo: foi pensada para deixar passar rodapés, mas deixa qualquer pessoa acrescentar conteúdo à sua mensagem assinada sem partir a assinatura — um vetor de ataque real — e mesmo assim não sobrevive à maioria das modificações de gateway. Sem l= é simultaneamente a escolha mais segura e a mais fiável.
6. Volte a verificar, depois confirme o alinhamento. Uma assinatura válida só ajuda o DMARC se o domínio d= alinhar com o seu domínio do From — uma assinatura que valida como d=yourcompany.gappssmtp.com passa o DKIM e continua a falhar o DMARC. Se é o seu caso, veja a armadilha da assinatura por omissão, e depois trabalhe o que mais a verificação assinalar na página corrigir o DKIM.

Perguntas frequentes

“DKIM signature not valid” é o mesmo que “body hash did not verify”? A mensagem de body hash é um subcaso específico: o corpo mudou depois da assinatura (rodapés, avisos legais, reescritas de listas). “Signature not valid” é o veredicto genérico para qualquer verificação falhada, incluindo chaves más e alterações de cabeçalhos — e é por isso que o passo 2 acima é ler o cabeçalho, e por isso que o caso do body hash tem guia próprio.

Uma assinatura DKIM inválida significa que o meu correio está a ser rejeitado? Não por si só — os recetores tratam uma assinatura partida como uma assinatura em falta. O dano chega via DMARC: se o SPF também não passar com alinhamento, a mensagem falha o DMARC e a sua política publicada aplica-se. À data do censo de 2026-06-29, só 3,87% de 261.086.232 domínios classificados detêm SPF, DKIM e uma política DMARC com aplicação em conjunto — mas o Gmail e a Microsoft esperam agora exatamente isso dos remetentes, portanto uma perna DKIM partida custa entregabilidade mesmo antes da rejeição.

Devo usar uma chave DKIM de 1024 ou de 2048 bits? 2048 bits — as chaves de 1024 bits estão abaixo das recomendações criptográficas atuais e alguns recetores penalizam-nas. O senão é puramente operacional: uma chave de 2048 bits não cabe numa única string TXT de 255 caracteres, portanto tem de ser dividida corretamente (causa 2 acima). A delegação por CNAME para o seu fornecedor contorna por completo o problema da divisão.

O meu DKIM passa num verificador mas o DMARC continua a falhar — como? Quase de certeza alinhamento: a assinatura valida, mas o seu domínio d= (digamos, yourcompany.gappssmtp.com ou yourtenant.onmicrosoft.com) não corresponde ao seu domínio do From, portanto o DMARC não a pode usar. Ative a assinatura com domínio próprio do seu fornecedor — o passo a passo completo está no guia da armadilha da assinatura por omissão.

Posso simplesmente desligar o DKIM se ele continuar a falhar? Não — desde os mandatos de remetentes em massa de 2024, o Gmail e o Yahoo exigem DKIM a remetentes de volume, e uma política DMARC com aplicação precisa realisticamente do DKIM porque o SPF sozinho parte-se com o reencaminhamento. Corrija a assinatura; as causas acima são todas corrigíveis numa tarde.

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 depois das suas alterações e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, com o DKIM a verde. É 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 — a diferença entre “corrigi uma coisa do DNS” e um antes-e-depois documentado que diz que o domínio autentica o seu correio.

Verifique o seu domínio → · Guia de “Body hash did not verify” → · Corrigir o DKIM → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.