Uma mensagem com vários DKIM assinaturas precisam de uma avaliação por assinatura. Contar as assinaturas ou selecionar o primeiro resultado aprovado pode identificar incorretamente o domínio que autenticou o autor visível. Sob RFC 9989 §4.4.1, qualquer identificador autenticado por DKIM que se alinhe ao domínio do autor poderá fornecer o caminho DKIM para DMARC passar.
Preservar a identidade de cada resultado
Exporte a mensagem bruta por meio de um processo aprovado. Registre o domínio From visível e, para cada assinatura, seu d= domínio de assinatura, s= seletor, a= algoritmo e relevante canonização configurações. Associe o resultado do sistema receptor confiável a essa assinatura. Duas assinaturas podem usar o mesmo domínio, mas seletores ou algoritmos diferentes, portanto, o domínio sozinho pode não distingui-las.
Não confie em um arbitrário Authentication-Results campo simplesmente porque aparece na mensagem. RFC 8601 §1.2 explica o limite de confiança para esses campos. Use resultados atribuíveis ao sistema receptor cuja avaliação você está investigando e preserve essa fonte ao exportar evidências. Um remetente pode inserir um texto de cabeçalho enganoso; um rótulo de status copiado não é uma verificação independente.
Mantenha a verificação e o alinhamento como decisões separadas
A verificação estabelece se uma assinatura é validada para seu domínio de assinatura. Alinhamento compara esse domínio autenticado com o domínio do autor sob a regra DMARC aplicável. A assinatura de um provedor não relacionado pode ser perfeitamente válida sem autenticar o domínio visível do autor para DMARC .
Para um alinhamento estrito DKIM , os domínios devem corresponder exatamente, com comparação de casos de nomes de domínio a seguir RFC 1035 §2.3.3. O alinhamento relaxado usa seu relacionamento de domínio organizacional conforme determinado pelo processo DMARC aplicável. RFC 9989 §4.10.2 define DNS Tree Walks para esta determinação. Não decida o alinhamento a partir de uma palavra comum em dois nomes de domínio e não presuma silenciosamente que todos os destinatários adotaram a implementação de descoberta mais recente.
Trabalhe por meio de uma mensagem sintética
Suponha uma política DMARC aplicável válida, um domínio de autor de example.com e não alinhado SPF passar. A assinatura A usa d=example.net, verifica com sucesso e não alinha. A assinatura B usa d=example.com mas falha na verificação após uma alteração de conteúdo downstream. Nenhum dos dois fornece uma identidade DKIM de passagem alinhada, portanto esta combinação não produz passagem DMARC .
Agora adicione a assinatura C com d=example.com que verifica com sucesso. Ele se alinha exatamente, fornecendo o caminho DKIM para a passagem DMARC . A aprovação não relacionada e a assinatura com falha não cancelam automaticamente C. Esta é uma avaliação ilustrativa, não uma afirmação sobre uma mensagem capturada do cliente ou posicionamento garantido na caixa de correio.
Escreva o exemplo em colunas separadas no seu registro de investigação: identificador de assinatura, resultado da verificação, resultado do alinhamento e contribuição para DMARC . Nunca combine a passagem da assinatura A com o domínio alinhado da assinatura B para fabricar um resultado que nenhuma assinatura individual alcançou.
Explique por que existem múltiplas assinaturas
Algoritmos paralelos, a assinatura operacional de um provedor e a assinatura posterior de um intermediário podem criar resultados múltiplos. Estas são hipóteses até que a configuração da rota e do signatário estabeleça o motivo. RFC 8463 §6 descreve seletores distintos para RSA e Ed25519 assinaturas de transição; seus resultados devem ser acompanhados individualmente.
Se um gateway assinar novamente o correio modificado, inspecione seu novo domínio. Uma assinatura de gateway de passagem não repara automaticamente a autenticação do autor original. Quando a organização controlar a fase final de assinatura, verifique se ela assina o conteúdo de pós-processamento pretendido sob uma identidade aprovada. Não remova uma assinatura aparentemente redundante sem verificar a sua finalidade operacional.
Encerre com a conclusão no nível da mensagem
Depois de avaliar todas as assinaturas DKIM relevantes, avalie o identificador autenticado e o alinhamento do SPF separadamente. Se nenhuma política DMARC aplicável for descoberta, não rotule a situação como uma falha normal DMARC . Distinguir os resultados da autenticação da disposição final do destinatário, que pode refletir política ou filtragem adicional.
Retenha a mensagem original, a fonte confiável do resultado, a análise por assinatura e o motivo da conclusão final. Se as ferramentas de relatório agregarem assinaturas de forma diferente, compare as suas evidências brutas antes de tratar resumos diferentes como uma contradição de protocolo. O resultado útil é um caminho de identidade explicável, e não simplesmente um maior número de indicadores verdes.
Grave o exemplo sem misturar identidades
Para a mensagem sintética acima, mantenha uma linha por assinatura:
- R: example.net ; passe de verificação; alinhamento não; Contribuição DKIM para DMARC no.
- B: example.com ; falha na verificação; o domínio corresponderia, mas não seria autenticado; Contribuição DKIM nº.
- C: example.com ; passe de verificação; alinhamento sim; Contribuição DKIM sim.
Antes de C estar presente, a ausência declarada de SPF alinhado não deixa caminho de passagem. Com C presente, DMARC passa pela política aplicável assumida. Nenhum resultado real do receptor ou resultado da colocação na caixa de entrada é reivindicado.
Leitura relacionada
Alinhamento DKIM : compare d= com o domínio From visível · Assinaturas RSA e Ed25519 DKIM : questões de implantação e interoperabilidade.