A DKIM-Signature est un ensemble de balises séparées par des points-virgules décrivant comment un domaine a signé un message. La lecture de ces champs vous aide à choisir le bon chemin de recherche DNS et d’enquête. Il ne vous permet pas de valider la cryptographie à l'œil nu. Conservez le message original avant de copier ou de reformater une signature pour inspection.
Commencez par les champs de recherche et d'algorithme
La valeur d= requise est le domaine de signature ; requis s= est le sélecteur. Avec la méthode de requête DNS TXT normale, celles-ci conduisent à s. _domainkey.d. La balise a= identifie l'algorithme de signature et de hachage. La balise v= requise doit avoir la valeur 1 pour la syntaxe de signature RFC 6376 . Cela diffère de la balise de version dans un enregistrement de clé DNS . Ces valeurs décrivent la signature, et non le résultat de sa vérification. RFC 6376 §3.5, RFC 6376 §3.6.2.
Fragment illustratif, volontairement incomplet et non valable : d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date. Son nom de recherche est outbound2026._domainkey.example.com . C'est canonisation utilise un traitement détendu pour les en-têtes et le corps. Sa liste d'en-têtes signés nomme les champs d'en-tête sélectionnés. Le fragment omet les valeurs cryptographiques requises et ne doit jamais être utilisé comme enregistrement de production.
Distinguer la couverture du contenu des données de signature
La balise h= répertorie les champs d'en-tête fournis à l'opération de signature, dans leur ordre défini. Ce n'est pas un algorithme de hachage. From doit être inclus dans une signature DKIM valide. Les noms d'en-tête répétés et les champs de message en double nécessitent les règles de sélection de la spécification ; un simple coup d’œil à la liste ne peut pas résoudre toutes les questions de couverture.
La balise bh= contient le hachage du corps. La balise b= contient la valeur de signature. Les codages correspondants ou apparemment plausibles ne prouvent pas la validité. La balise c= décrit la canonisation, qui permet une normalisation spécifique de la représentation signée. Il ne permet pas la réécriture arbitraire d'un message. Si c= est omis, la valeur par défaut est simple/simple ; si un seul algorithme est nommé, il s'applique aux en-têtes et le corps est par défaut simple. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
La balise facultative l= limite le nombre d’octets de corps canonisés inclus. Sa présence nécessite de la prudence : une signature valide ne peut pas couvrir le contenu ajouté au-delà de cette longueur. Ne décrivez pas chaque DKIM passer comme preuve que chaque octet visible est inchangé. RFC 6376 §3.5, RFC 6376 §8.2.
Interpréter soigneusement l’identité et le temps
La valeur facultative i= est un identifiant d'agent ou d'utilisateur revendiqué selon les règles du domaine signataire ; ce n'est pas nécessairement une boîte aux lettres qui fonctionne. DMARC utilise d=, et non i=, pour DKIM alignement. Les balises t= et x= décrivent l'heure de signature et l'expiration de la signature. RFC 6376 §3.5 marque formellement les deux RECOMMANDÉS, bien qu'ils puissent être absents. Il s'agit de métadonnées de signature et non de preuves de l'heure d'arrivée réelle SMTP . Conservez les en-têtes reçus et les journaux système pour l’analyse du transit.
Une signature utilisant une cryptographie obsolète ne doit pas être acceptée simplement parce que ses champs sont analysés. RFC 8301 §3.1 interdit rsa-sha1 ; RFC 8301 §3.2 met à jour les exigences clés RSA. Utilisez un logiciel de vérification pris en charge et les conseils actuels du fournisseur plutôt que de mettre en œuvre manuellement ces vérifications à partir de ce guide de terrain.
Terminez avec le résultat du récepteur
Collectez la paire d/s, l'algorithme, les champs de couverture pertinents, le résultat DKIM fiable et la raison de l'échec. Si DNS est manquant, recherchez le nom exact du propriétaire et le cycle de vie de la clé. Si la clé est disponible mais que la vérification échoue, comparez les chemins de signature et de livraison sans modifier la preuve originale. Confirmez toute correction avec un message nouvellement envoyé et un résultat de destinataire fiable. L’objectif est une explication défendable d’une signature, et non une supposition visuelle de réussite ou d’échec.
Appliquer la distinction
Lisez le fragment illustratif en quatre groupes : d/s sélectionne l'identité et la recherche ; a/c spécifie l'algorithme et la canonisation ; h et tout l définissent la couverture ; b/bh portent des valeurs que le logiciel vérifie. Le v/b/bh requis manquant signifie que le fragment n’est pas une signature valide. Si l=0 apparaît dans une signature réelle, aucun octet de corps n'est haché, donc l'intégrité du corps n'est pas protégée ; RFC 6376 §3.5 définit ce mécanisme de longueur. Aucune de ces observations n’est une passe cryptographique.