Quando um DKIM chave aparece em um painel de controle DNS , mas a verificação falha, inspecione a resposta que o verificador realmente recupera. As capturas de tela podem ocultar um valor truncado, um sufixo de domínio duplicado ou vários registros independentes. A tarefa é estabelecer o nome exato do proprietário e os bytes da chave antes de alterar o signatário.
Comece pela assinatura recebida
Ler d= e s= dos afetados DKIM-Signature. O nome de pesquisa os combina como seletor. _domainkey.signing-domain. Uma mensagem sintética com d=example.com e s=notify portanto usa notify._domainkey.example.com. Uma chave publicada em notifications._domainkey.example.com não irá consertá-lo.
Registre o algoritmo da assinatura e o motivo exato do destinatário. Chave ausente, chave malformada, algoritmo inadequado, incompatibilidade de assinatura e incompatibilidade de hash corporal não são diagnósticos intercambiáveis. Se existirem múltiplas assinaturas, mantenha seus seletores e resultados separados.
Reconstrua um registro TXT corretamente
DNS Registros TXT pode conter várias sequências de caracteres. RFC 6376 §3.6.2.2 requer que essas strings em um único registro sejam concatenadas sem adição de espaços em branco antes do uso. Dividir uma chave longa em strings em um registro é diferente de criar vários registros TXT , cada um contendo uma parte. Esta última não é uma forma segura de publicar uma chave DKIM . A seção 3.6.2.2 requer um registro TXT exclusivo para o seletor e deixa os resultados de vários registros indefinidos; as escolhas do verificador na seção 6.1.2 não tornam os fragmentos combináveis.
Os pedaços citados mostrados por uma ferramenta DNS são uma apresentação do registro. Não presuma que as aspas de exibição sejam bytes de chave literais e não remova caracteres indiscriminadamente da interface DNS . Siga o formato de entrada suportado, consulte DNS autoritativo e compare o valor reconstruído com o valor público gerado. RFC 1035 §3.3.14 define a representação da cadeia de caracteres TXT .
Inspecione quanto a truncamento nos limites da interface, rótulos de linha colados, separadores ausentes e edições acidentais no valor base64. Registros longos precisam de comparação exata, não de inspeção visual do primeiro e do último caractere. Preservar o valor público original gerado para essa comparação; nunca substitua um arquivo de chave privada.
Valide tags e material chave juntos
Sob RFC 6376 §3.6.1, o p= tag carrega os dados de chave pública. Um valor vazio significa uma configuração revogada e não parcialmente concluída. O k= tag identifica o tipo de chave, com RSA como padrão na RFC 6376 ; Ed25519 usa a extensão definida por RFC 8463 §4.2. A seção 3.6.1 RFC 6376 marca formalmente o registro-chave v= tag RECOMENDADO, com DKIM1 como padrão quando estiver ausente. Se incluída, deverá ser a primeira tag e seu valor deverá ser exatamente DKIM1 ; esse valor diferencia maiúsculas de minúsculas.
Use um validador compatível com DKIM para analisar o registro completo e confirmar se o material público decodificado é apropriado para o tipo de chave declarado. A base64 válida por si só não prova que o conteúdo seja uma chave pública RSA ou Ed25519 adequada. Da mesma forma, um registro sintaticamente válido pode conter a chave pública errada para o assinante privado ativo.
Isole a camada de publicação da camada de assinatura
Uma falha ilustrativa envolve uma 2048 bits Chave pública RSA copiada em dois registros TXT separados. Repare a representação no formulário de registro único multistring suportado pelo provedor DNS e, em seguida, leia a resposta. Não encurte a chave para silenciar o erro de interface sem revisar a causa e as implicações de segurança.
Se a chave pública correta for resolvida intacta, mas uma mensagem ainda falhar, investigue o mapeamento do seletor ativo, o par de chaves correspondente, o algoritmo e as alterações na mensagem assinada. Não continue republicando dados DNS idênticos enquanto as evidências apontam para outro lugar. Um provedor gerenciado CNAME deve ser rastreado até seu registro chave final; ela não deve ser substituída por uma cópia local como solução alternativa de sintaxe genérica.
Prove o reparo em uma nova mensagem
Registre resultados oficiais e recursivos, contabilizando dados antigos ou respostas negativas. Envie através do aplicativo afetado e inspecione o resultado do destinatário confiável. Retenha o nome do proprietário corrigido, o valor público reconstruído ou seu resumo, a comparação do valor gerado e as evidências de teste. Um reparo é concluído quando a chave recuperada e o signatário real concordam, e não apenas quando o editor DNS aceita o formulário.
Verifique a estrutura sem uma chave real
Apresentação ilustrativa de um registro: " v=DKIM1; k=rsa; p=AB" "CD". A concatenação produz v=DKIM1; k=rsa; p=ABCD, sem espaço inserido entre AB e CD. ABCD deliberadamente não é uma chave pública RSA utilizável válida; este exemplo demonstra apenas a estrutura TXT e não deve ser publicado. Dois registros separados terminados em p=AB e contendo CD não são equivalentes. Depois de reconstruir o valor real gerado, um analisador compatível com DKIM ainda deve validar suas tags e material de chave decodificado.
Leitura relacionada
Publicação DKIM TXT e CNAME : siga o modelo de gerenciamento de chaves do provedor · Comprimento e algoritmos da chave DKIM : verifique o suporte atual do receptor.