Defaults.Exposed › Correções › Guides

DKIM 'Body Hash Did Not Verify' — o que alterou a sua mensagem e como corrigir (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.

“Body hash did not verify” significa que a sua assinatura DKIM era válida quando a mensagem saiu de si — e algo reescreveu o corpo da mensagem depois. A assinatura não está avariada; a mensagem foi modificada em trânsito. Só 3,87% dos domínios — 10.092.481 — completam a tríade SPF-DKIM-DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios (2026-06-29).

A correção é uma caça, depois uma decisão. Encontre o salto que modifica o seu correio — um gateway a acrescentar um disclaimer, um equipamento a reescrever links, uma lista de distribuição a adicionar um rodapé. Depois assine depois desse salto, pare a modificação, ou torne a assinatura tolerante a ela — por esta ordem.

O que significa realmente “body hash did not verify”?

Uma assinatura DKIM (RFC 6376) transporta dois hashes: bh=, um hash do corpo da mensagem tal como foi assinado, e b=, que assina os cabeçalhos mais esse hash do corpo. O verificador recalcula o hash do corpo a partir da mensagem que recebeu; se não corresponder ao bh=, a verificação para com a frase que toda a gente cola numa caixa de pesquisa — um cabeçalho do recetor como:

Authentication-Results: …; dkim=fail (body hash did not verify)

Essa é a string de motivo documentada da Microsoft; o Gmail apresenta muitas vezes o mesmo diagnóstico como dkim=neutral (body hash did not verify). Em qualquer dos casos, o veredicto estreita enormemente o problema. A sua chave DNS, o seletor e a configuração de assinatura estão todos bem. A criptografia fez o seu trabalho: o corpo mudou entre a assinatura e a verificação — uma linha acrescentada, um URL reescrito, um carácter recodificado chega. (Uma mensagem diferente — signature did not verify, no key for signature — significa uma falha diferente; comece por “DKIM signature not valid”.) E é urgente porque uma assinatura falhada não pode dar ao DMARC um resultado positivo alinhado: a menos que o SPF passe com alinhamento na mesma mensagem, o correio falha o DMARC por completo.

O que alterou a sua mensagem? Os suspeitos do costume

Algo no percurso de entrega editou o corpo depois de o seu assinador o ter selado. Na prática é uma de quatro coisas:

Verifique primeiro a linha a negrito — o servidor de correio assina, o dispositivo de borda edita, e todas as mensagens saem com uma assinatura que foi verdadeira durante trinta milissegundos.

Como encontro o salto que está a modificar o meu correio?

Diagnóstico diferencial — compare um percurso que funciona com o percurso que falha:

1. Envie uma mensagem de teste direta para uma caixa de correio que controle num grande recetor (o Gmail serve bem), contornando o máximo possível da sua cadeia de saída.
2. Envie uma segunda mensagem pelo percurso que falha — através do gateway, através da lista, para o domínio do destinatário afetado.
3. Compare as linhas Authentication-Results nos dois cabeçalhos completos. Envio direto dkim=pass, percurso com falha dkim=fail (ou dkim=neutral) com body hash did not verify: o modificador vive entre essas duas rotas.
4. Olhe para o corpo recebido: um disclaimer, banner ou rodapé que não escreveu? Links reescritos para um domínio de análise? Aí está o seu salto, com nome — e a cadeia Received: mostra que relay aparece apenas no percurso que falha.

Os seus relatórios agregados DMARC contam a mesma história em escala: uma origem que reporta consistentemente DKIM fail com SPF pass é normalmente modificação em trânsito na sua própria rota, não um atacante.

Como corrijo?

1. Execute a verificação gratuita em defaults.exposed antes de tocar em qualquer coisa. Confirma que as suas chaves DKIM publicadas e a política DMARC estão sãs, para que esteja a depurar o único problema real — a modificação — e não a caçar fantasmas no DNS. A página corrigir o DKIM cobre as verificações do lado dos registos.
2. Assine depois do salto que modifica. A correção arquiteturalmente correta: mova a assinatura DKIM para o dispositivo mais exterior que toca na mensagem. Instalações Exchange-mais-gateway devem assinar no gateway (Mimecast, Proofpoint e congéneres suportam-no todos) e desativar a assinatura a montante. Se o Google Workspace ou o Microsoft 365 for o seu último salto, assine aí e não deixe nada editar o correio depois dele — veja configurar o DKIM no Google Workspace ou Microsoft 365.
3. Ou pare a modificação. Tire a edição do percurso de transporte: disclaimer na assinatura do cliente de email ou no modelo em vez de uma regra de transporte; banner “EXTERNAL:” limitado apenas ao correio recebido (etiquetar o seu próprio correio de saída como externo é uma má configuração a dobrar); correio de saída autenticado isento da reescrita de links.
4. Use canonicalização relaxed/relaxed (c=relaxed/relaxed). A canonicalização de corpo simple falha com uma única linha requebrada; relaxed tolera alterações de espaços e de fins de linha. Seja honesto quanto ao limite: relaxed perdoa formatação, nunca conteúdo — um rodapé acrescentado continua a falhar, como deve.
5. Volte a testar ambos os percursos e depois a verificar. As duas rotas devem agora mostrar dkim=pass com o seu domínio em d=, e o relatório da verificação deve estar limpo.

Devo usar a tag l= para o DKIM ignorar conteúdo acrescentado?

Não — e desconfie de qualquer guia que o sugira. A tag l= faz hash apenas dos primeiros N bytes do corpo, de modo que um rodapé acrescentado deixa de partir a assinatura. “Funciona” ao deixar o fim da sua mensagem sem assinatura: qualquer pessoa na posse de uma mensagem legítima assinada pode acrescentar conteúdo arbitrário e a sua assinatura válida continua a verificar sobre o resultado. Isso é um buraco de spoofing vestido de correção — o abuso prático já foi demonstrado, e alguns recetores penalizam ou ignoram o l= exatamente por esta razão. Resolva a modificação; não deixe parte do seu correio por assinar.

E as listas de distribuição — consigo corrigir essas?

Na maior parte dos casos, não — e saber isso poupa-lhe semanas. Uma lista que adiciona uma etiqueta no assunto ou um rodapé parte o seu hash do corpo por design, e você não controla a lista. Duas coisas ajudam:

• Este resíduo é exatamente a razão por que a adoção do DMARC é faseada. Passar de p=none por p=quarantine com uma rampa pct=, enquanto lê os relatórios agregados, significa que as mensagens mutiladas por listas vão para quarentena em vez de serem destruídas enquanto avalia o impacto — o tema de de p=none a p=reject sem perder email legítimo.
• O ARC é o mecanismo do recetor, não o seu. O Authenticated Received Chain permite que a lista ateste como estava a autenticação à chegada e que o recetor decida se confia nela. Não há nada para si, o remetente, configurar. Listas bem geridas mitigam reescrevendo o cabeçalho From; as mal geridas simplesmente partem o seu correio.

O reencaminhamento é o caso adjacente — parte o SPF de forma fiável mas só às vezes o DKIM, e é por isso que o DKIM alinhado é a sua perna à prova de reencaminhamento quando o corpo sobrevive: veja email reencaminhado falha o SPF — porque não o consegue corrigir.

Porque é que o DKIM se parte tantas vezes quando tão poucos domínios têm sequer a stack completa?

Porque o DKIM é o filho do meio frágil da tríade: o SPF é um registo DNS estático, o DMARC uma declaração de política, mas o DKIM tem de sobreviver à viagem. Só 51,84% dos domínios classificados publicam sequer uma chave DKIM detetável no DNS, segundo o censo do Defaults.Exposed, e só 10.092.481 domínios — 3,87% dos 261.086.232 classificados — têm SPF, DKIM e uma política DMARC aplicada em conjunto (o modelo de maturidade da adoção do SPF desmonta a escada). Acertar nesta correção é a parte mais difícil de entrar nesses 3,87%.

Perguntas frequentes

“Body hash did not verify” é sinal de que alguém está a fazer spoofing do meu domínio? Normalmente não — um falsificador tipicamente não consegue de todo produzir a sua assinatura DKIM, portanto o correio dele não mostra assinatura ou mostra no key. Um hash do corpo falhado significa que uma mensagem genuinamente assinada pela sua infraestrutura foi editada depois. Verifique o seu próprio gateway antes de presumir um atacante.

O SPF passa nestas mensagens — continuo bem? Por agora, talvez: o DMARC só precisa de um resultado positivo alinhado. Mas o resultado do SPF evapora-se no momento em que alguém reencaminha a mensagem, e se não estiver alinhado com o seu domínio do From nunca contou para o DMARC de qualquer forma. Com só 3,87% dos domínios a ter a tríade completa (censo de 2026-06-29 de 261.086.232 domínios), “uma perna a coxear” é o estado normal — e o que se corrige.

Mudar para canonicalização relaxed/relaxed corrige o meu problema do disclaimer? Não. Relaxed tolera apenas alterações de espaços e de quebra de linhas. Um disclaimer acrescentado é uma alteração de conteúdo, e o hash tem de falhar com ela — isso é o DKIM a funcionar corretamente. Mova o ponto de assinatura ou mova o disclaimer.

A falha só acontece com o domínio de um cliente. Porquê? O lado dele quase de certeza modifica o correio recebido — um equipamento de segurança a reescrever links ou a carimbar banners antes de o verificador correr, ou um reencaminhamento interno a recodificar o corpo. Envie-lhes a secção de diagnóstico desta página; a correção está no gateway deles, não no seu DNS.

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. Quando o salto que modifica estiver corrigido, volte a executar a verificação gratuita e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, com o estado do DKIM e do DMARC numa página. É o comprovativo de que vão precisar na renovação do seguro cibernético e no próximo questionário de fornecedor — prova de que o correio que sai da empresa é agora o correio que chega.

Verifique o seu domínio → · Guia “DKIM signature not valid” → · Corrigir o DKIM → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.