Uma mensagem que verifica antes de encaminhar e falha depois exige uma comparação dos bytes assinados e do contexto da assinatura. Não presuma que todo cabeçalho adicionado quebra DKIM ou aquele relaxado canonização permite edição arbitrária. A assinatura identifica os campos de cabeçalho protegidos, canonização e hash de corpo. Reconstrua essas escolhas antes de decidir qual transformação é importante.
Preservar artefatos comparáveis
Referências: RFC 6376 §3.5, RFC 6376 §3.7.
Retenha a mensagem original e final bruta sem abrir e salvar novamente por meio de um cliente que possa normalizar os finais de linha ou recodificar MIME . Registre o domínio do signatário, seletor, algoritmo, lista de cabeçalhos assinados, canonização e qualquer limite de comprimento do corpo. Mantenha a saída do verificador e a observação da chave DNS com o carimbo de data/hora. Uma mensagem visualmente idêntica pode ter bytes codificados diferentes.
Encontre o signatário na cadeia de processamento. Um rodapé adicionado antes da assinatura final faz parte do conteúdo assinado; o mesmo rodapé anexado após a assinatura pode invalidar o hash do corpo. Inventário lista software, gateways, mecanismos de isenção de responsabilidade, reescritores de antivírus e caminhos de arquivamento como possíveis pontos de transformação. Somente evidências da rota real podem identificar qual deles agiu.
Entenda o que a canonização permite
Referências: RFC 6376 §3.4, RFC 6376 §5.4, RFC 6376 §8.2.
RFC 6376, seção 3.4, define canonização simples e relaxada. O processamento corporal relaxado normaliza os espaços em branco especificados e as linhas vazias finais. Isso não faz desaparecer um parágrafo adicionado ou um valor alterado. A canonização do cabeçalho tem regras próprias e não deve ser substituída por regras do corpo.
Um prefixo Assunto afeta uma assinatura que cobre o campo Assunto relevante. Apenas adicionar um cabeçalho não assinado não relacionado é um caso diferente. Campos assinados duplicados e seleção de cabeçalho exigem as regras do verificador, não uma diferença visual casual. Quando uma assinatura incluir um limite de comprimento corporal, entenda o risco do conteúdo descoberto; não introduza essa opção como uma maneira conveniente de tornar seguros os rodapés arbitrários.
Execute uma comparação de hash de corpo real
Referências: RFC 6376 §3.4.4.
O acessório local aplica canonização corporal relaxada a três corpos sintéticos. Ele calcula SHA-256 e base64 para o original, uma variação apenas com espaços em branco e uma versão anexada ao rodapé. Os casos originais e de espaço em branco correspondem; o caso do rodapé é diferente. Os arquivos .eml originais e modificados gerados preservam os bytes do corpo ilustrativos para inspeção.
Esta é uma transformação de hash observada, não uma Assinatura DKIM verificação. Nenhuma chave de assinatura privada, pesquisa de chave DNS , assinatura de cabeçalho ou serviço de recebimento confiável está envolvida. O efeito esperado em uma assinatura completa permanece condicionado à assinatura real que cobre os bytes alterados. As evidências retidas abaixo registram o histórico de assinatura local e verificação antes e depois; as evidências da rota de produção permanecem não coletadas.
Corrija a ordem antes de enfraquecer a cobertura
Referências: RFC 9989 §4.4.1, RFC 9989 §5.3.5.
Sempre que possível, aplique as transformações necessárias antes da etapa final de assinatura do domínio legítimo. Para um intermediário que não pode assinar em nome do autor original, preservar o conteúdo original assinado pode manter uma passagem alinhada. Uma assinatura substituta do intermediário autentica seu próprio domínio e não é automaticamente alinhada com o endereço De original. RFC 9989 suprimentos que separam a comparação.
Teste novamente a mesma transformação com o verificador completo e o conteúdo MIME representativo. Inclua anexos, alternativas multipartes e mensagens não-ASCII se estiverem no escopo. Preserve os controles negativos para que um teste não seja bem-sucedido simplesmente porque a assinatura desapareceu. O encerramento deve dizer qual transformação mudou, qual assinatura agora é validada e se essa assinatura fornece autenticação alinhada no destinatário final.
Evidência laboratorial retida
Referências: RFC 6376 §6.
Na captura de 7 de novembro de 2026, um temporário 2048 bits A chave RSA assinou os bytes originais com dkimpy antes de encaminhar. O registro DNS público da chave é retido e a chave privada é excluída após a execução. dkimpy verifica as mensagens originais e de encaminhamento preservadas e rejeita o corpo anexado ao rodapé. O caso de lista aplica alterações de atribuição e rodapé antes de criar sua assinatura de domínio de lista, que verifica. Estes são testes de assinatura DKIM completos e genuínos, não fornecem resultados booleanos. O auxiliar de corpo relaxado agora também trata entradas vazias como zero octetos.
O corredor retido e a captura em 7 de novembro de 2026 foram inspecionados; nenhum experimento de rede foi executado novamente para esta revisão. O experimento original usou apenas loopback e não enviou nenhum email pela Internet. Seu receptor cria Authentication-Results provenientes dos seus próprios controlos, dando a esses domínios uma proveniência laboratorial conhecida. O resultado e a disposição da autenticação permanecem separados: todas as seis amostras SMTP recebem 250 sob uma política de captura explícita, incluindo amostras com falha. O limite de confiança é este laboratório controlado, não um fornecedor de caixa de correio de produção. O adaptador DNS fornece respostas de fixtures retidas em vez de consultar DNS público, e o DMARC o avaliador usa apenas igualdade estrita de domínio. A descoberta completa do domínio organizacional, a análise da política de produção e os resultados da implantação em tempo real permanecem não testados.