Quand un DKIM La clé apparaît dans un panneau de contrôle DNS mais la vérification échoue, inspectez la réponse que le vérificateur récupère réellement. Les captures d'écran peuvent masquer une valeur tronquée, un suffixe de domaine dupliqué ou plusieurs enregistrements indépendants. La tâche consiste à établir le nom exact du propriétaire et les octets clés avant de changer le signataire.
Partir de la signature reçue
Lire d= et s= des personnes touchées DKIM-Signature. Le nom de la recherche les combine comme sélecteur. _domainkey.signing-domain. Un message synthétique avec d=example.com et s=notify utilise donc notify._domainkey.example.com. Une clé publiée sur notifications._domainkey.example.com ne le réparera pas.
Enregistrez l'algorithme de la signature et la raison exacte du destinataire. Clé manquante, clé mal formée, algorithme inadapté, inadéquation de signature et inadéquation de hachage corps ne sont pas des diagnostics interchangeables. S'il existe plusieurs signatures, conservez leurs sélecteurs et leurs résultats séparés.
Reconstruire correctement un enregistrement TXT
DNS Enregistrements TXT peut contenir plusieurs chaînes de caractères. RFC 6376 §3.6.2.2 nécessite que ces chaînes au sein d'un seul enregistrement soient concaténées sans espace ajouté avant utilisation. Diviser une clé longue en plusieurs chaînes dans un seul enregistrement diffère de la création de plusieurs enregistrements TXT , chacun contenant un morceau. Ce dernier n'est pas un moyen sûr de publier une clé DKIM . La section 3.6.2.2 requiert un enregistrement TXT unique pour le sélecteur et laisse les résultats de plusieurs enregistrements indéfinis ; les choix du vérificateur dans la section 6.1.2 ne rendent pas les fragments composables.
Les morceaux cités affichés par un outil DNS sont une présentation de l'enregistrement. Ne présumez pas que les guillemets affichés sont des octets de clé littéraux et ne supprimez pas les caractères sans discernement de l'interface DNS . Suivez son format d'entrée pris en charge, interrogez DNS faisant autorité et comparez la valeur reconstruite avec la valeur publique générée. RFC 1035 §3.3.14 définit la représentation de la chaîne de caractères TXT .
Inspectez la troncature aux limites de l'interface, les étiquettes de ligne collées, les séparateurs manquants et les modifications accidentelles de la valeur base64. Les enregistrements longs nécessitent une comparaison exacte, et non une inspection visuelle des premiers et derniers caractères. Préserver la valeur publique générée à l'origine pour cette comparaison ; ne remplacez jamais un fichier de clé privée.
Valider ensemble les balises et les éléments clés
Sous RFC 6376 §3.6.1, le p= La balise transporte les données de clé publique. Une valeur vide signifie une configuration révoquée et non partiellement terminée. Le k= la balise identifie le type de clé, avec RSA comme valeur par défaut dans RFC 6376 ; Ed25519 utilise l'extension définie par RFC 8463 §4.2. La section 3.6.1 RFC 6376 marque formellement l'enregistrement de clé. v= balise RECOMMANDÉE, avec DKIM1 par défaut lorsqu'elle est absente. S'il est inclus, il doit s'agir de la première balise et sa valeur doit être exactement DKIM1 ; cette valeur est sensible à la casse.
Utilisez un validateur compatible DKIM pour analyser l'enregistrement complet et confirmer que le matériel public décodé est approprié pour le type de clé indiqué. Une base64 valide ne prouve pas à elle seule que le contenu est une clé publique RSA ou Ed25519 appropriée. De même, un enregistrement syntaxiquement valide peut contenir une clé publique incorrecte pour le signataire privé actif.
Isoler la couche de publication de la couche de signature
Un échec illustratif implique un 2048 bits Clé publique RSA copiée dans deux enregistrements TXT distincts. Réparez la représentation dans le formulaire à enregistrement unique multichaîne pris en charge par le fournisseur DNS , puis relisez la réponse. Ne raccourcissez pas la clé pour faire taire l’erreur d’interface sans en examiner la cause et les implications en matière de sécurité.
Si la clé publique correcte est résolue intacte mais qu'un message échoue toujours, étudiez le mappage du sélecteur actif, la paire de clés correspondante, l'algorithme et les modifications du message signé. Ne continuez pas à republier des données DNS identiques alors que les preuves indiquent ailleurs. Un fournisseur géré CNAME doit être retracé jusqu'à son enregistrement de clé final ; il ne doit pas être remplacé par une copie locale comme solution de contournement de syntaxe générique.
Prouvez la réparation sur un nouveau message
Enregistrez les résultats faisant autorité et récursifs, en tenant compte des anciens ou réponses négatives. Envoyez via l'application concernée et inspectez le résultat du destinataire de confiance. Conservez le nom du propriétaire corrigé, la valeur publique reconstruite ou son résumé, la comparaison de la valeur générée et les preuves de test. Une réparation est terminée lorsque la clé récupérée et le signataire réel sont d'accord, et pas seulement lorsque l'éditeur DNS accepte le formulaire.
Vérifier la structure sans vraie clé
Présentation illustrative d'un enregistrement : " v=DKIM1; k=rsa; p=AB" "CD". La concaténation produit v=DKIM1; k=rsa; p=ABCD, sans espace inséré entre AB et CD. ABCD n'est délibérément pas une clé publique RSA utilisable et valide ; cet exemple montre uniquement la structure TXT et ne doit pas être publié. Deux enregistrements distincts se terminant par p=AB et contenant CD ne sont pas équivalents. Après avoir reconstruit la valeur réelle générée, un analyseur compatible DKIM doit encore valider ses balises et le matériel de clé décodé.
Lecture connexe
Publication DKIM TXT et CNAME : suivez le modèle de gestion des clés du fournisseur · Longueur de la clé DKIM et algorithmes : vérifiez la prise en charge actuelle du récepteur.