Validation DKIM : une meilleure pratique d'authentification des emails
Oiseau
8 avr. 2017
1 min read
Points Clés
DKIM (DomainKeys Identified Mail) est une méthode d'authentification de courrier électronique basée sur le contenu qui vérifie si un message a été altéré après avoir été signé.
Contrairement à SPF, qui valide le chemin d'envoi, DKIM valide le contenu du message lui-même en utilisant des signatures cryptographiques.
DKIM utilise deux clés : une clé privée pour signer les messages sortants et une clé publique publiée dans DNS pour que les récepteurs puissent valider les signatures.
Une signature DKIM inclut des hachages à la fois des en-têtes et du corps, des sélecteurs, des horodatages et des champs d'identité — que le récepteur doit reproduire et vérifier.
La validation DKIM repose sur la réception de l'intégralité du message en premier, ce qui signifie que des échecs peuvent survenir tard dans le processus.
Le dépannage des validations DKIM échouées est souvent difficile car les expéditeurs et les récepteurs ne peuvent pas reproduire les environnements de signature/vérification des uns et des autres.
Même lorsque DKIM échoue, cela ne cause généralement pas directement de problèmes d'acheminement vers la boîte de réception à moins d'être combiné avec d'autres signaux de mauvaise réputation.
Points forts des Q&A
Que fait réellement DKIM ?
DKIM ajoute une signature cryptographique à un e-mail, permettant au serveur destinataire de confirmer si le contenu du message a été modifié après son envoi.
Comment DKIM est-il différent de SPF ?
SPF valide qui est autorisé à envoyer du courrier pour un domaine (basé sur le chemin).
DKIM valide si le contenu est intact (basé sur le contenu).
Les deux ont des objectifs différents et se complètent mutuellement.
Qu'est-ce qui se trouve dans un en-tête DKIM-Signature ?
Les champs clés incluent :
v= version
a= algorithme
c= règles de canonicalisation
d= domaine de signature
s= sélecteur
h= en-têtes inclus dans la signature
bh= hachage du corps
b= données de signature réelles
Chaque partie contribue à la façon dont la signature est validée.
Comment un serveur récepteur valide-t-il DKIM ?
Extrait les valeurs d= et s=.
Recherche la clé publique à :
selector._domainkey.domain
Régénère les hachages de l'en-tête et du corps.
Les compare aux valeurs bh= et b= dans l'e-mail.
S'ils correspondent, le message passe DKIM.
Quelles sont les causes de l'échec du DKIM ?
Message modifié en transit (même les changements d'espacement si vous utilisez une canonisation stricte)
Clé publique incorrecte ou manquante dans le DNS
Erreurs de formatage DNS
Sélecteur supprimé ou tourné incorrectement
Identités incompatibles (i= doit être le même domaine ou sous-domaine de d=)
Pourquoi les échecs DKIM peuvent-ils être difficiles à résoudre ?
Parce que le signataire et le validateur opèrent dans des environnements complètement différents — aucune des deux parties ne peut reconstruire les conditions de hachage ou l'état de signature de l'autre.
Cela rend les échecs opaques de "défaut de correspondance de hachage" les plus frustrants à diagnostiquer.
Un échec DKIM signifie-t-il que l'email ira dans les spams ?
Pas nécessairement.
DKIM est juste un signal. Si le domaine a une bonne réputation et passe d'autres vérifications (SPF, alignement DMARC, faibles taux de plaintes), les échecs de DKIM isolés n'ont généralement pas d'impact sur l'inboxing par eux-mêmes.
Pourquoi utiliser DKIM du tout?
Protège l'intégrité des messages
Construit la réputation de domaine
Permet l'alignement DMARC
Aide les fournisseurs de boîtes à distinguer les expéditeurs légitimes des usurpateurs
DKIM est considéré une bonne pratique pour tous les expéditeurs d'email sérieux.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Lorsque nous parlons d'« Email Authentication », nous faisons référence à une technique qui offre au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée derrière de telles techniques est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation, des courriels qui pourraient éroder la confiance du destinataire dans la réception des emails. Cela dit, l'envoi d'un email authentifié n'affirme pas que l'email est bon ou souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe aujourd'hui deux formes d'authentification des emails :
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dans l'article d'aujourd'hui, je vais couvrir ce qu'est DKIM et comment cela fonctionne.
Présentation de DKIM
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité expéditrice soient les mêmes, ou du moins étroitement liées, avec DKIM, il n'y a aucune obligation que ce soit ainsi.
Mes objectifs pour vous avec ce post sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut être complétée dans de nombreux cas que lorsque le message complet a été transmis par le serveur expéditeur.
Les échecs de validation peuvent être difficiles à dépanner.
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité expéditrice soient les mêmes, ou du moins étroitement liées, avec DKIM, il n'y a aucune obligation que ce soit ainsi.
Mes objectifs pour vous avec ce post sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut être complétée dans de nombreux cas que lorsque le message complet a été transmis par le serveur expéditeur.
Les échecs de validation peuvent être difficiles à dépanner.
Contrairement à son homologue d'authentification SPF, qui fournit un moyen pour un domaine d'autoriser un hôte à envoyer du courrier en son nom, DKIM offre un moyen pour une entité (domaine, organisation, personne, etc.) de prendre la responsabilité d'un message, indépendamment de l'entité qui a effectivement envoyé le message. Bien que dans de nombreux cas l'entité responsable et l'entité expéditrice soient les mêmes, ou du moins étroitement liées, avec DKIM, il n'y a aucune obligation que ce soit ainsi.
Mes objectifs pour vous avec ce post sont que vous appreniez et compreniez les concepts suivants concernant DKIM :
DKIM est une authentification « basée sur le contenu », contrairement à SPF qui est « basé sur le chemin ».
L'entité responsable affirme sa responsabilité en « signant » le message avec une paire de hachages cryptographiques insérés dans un en-tête de message.
La validation DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hachages.
La validation DKIM ne peut être complétée dans de nombreux cas que lorsque le message complet a été transmis par le serveur expéditeur.
Les échecs de validation peuvent être difficiles à dépanner.
“Content-Based” Authentication
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non de la validation DKIM dépend uniquement de savoir si le contenu a changé entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non de la validation DKIM dépend uniquement de savoir si le contenu a changé entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM est considéré comme une authentification « basée sur le contenu », plutôt que « basée sur le chemin », car le passage ou non de la validation DKIM dépend uniquement de savoir si le contenu a changé entre le moment où il a été signé et le moment où la validation a été tentée.
DKIM Signing et Validation
Les organisations souhaitant signer les mails avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est gardée privée et disponible pour le serveur d'envoi afin de signer les mails, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs dans les tentatives de validation de la signature. Les méthodes de génération de ces clés et de leur installation dépendent de la plateforme et ne sont pas couvertes par cet article, bien que plus tard, je décrirai la publication de la clé DKIM publique dans le DNS.
Les organisations souhaitant signer les mails avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est gardée privée et disponible pour le serveur d'envoi afin de signer les mails, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs dans les tentatives de validation de la signature. Les méthodes de génération de ces clés et de leur installation dépendent de la plateforme et ne sont pas couvertes par cet article, bien que plus tard, je décrirai la publication de la clé DKIM publique dans le DNS.
Les organisations souhaitant signer les mails avec DKIM généreront d'abord deux clés cryptographiques. L'une des clés est gardée privée et disponible pour le serveur d'envoi afin de signer les mails, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines récepteurs dans les tentatives de validation de la signature. Les méthodes de génération de ces clés et de leur installation dépendent de la plateforme et ne sont pas couvertes par cet article, bien que plus tard, je décrirai la publication de la clé DKIM publique dans le DNS.
L'en-tête DKIM-Signature
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête DKIM-Signature :
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
L'en-tête DKIM-Signature est une série de paires clé-valeur, certaines plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous examinerons celles qui sont principalement d'intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces blancs dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM; ces règles sont appelées « règles de canonisation » (d'où la clé de c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de la création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – C'est le hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – C'est une liste des en-têtes qui ont été utilisés pour créer les données de signature indiquées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ce sont les données réelles de la signature DKIM
Ces trois parties sont d'un plus grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – C'est l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être identique ou un sous-domaine du domaine de la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
Champ | Signification | Comment les récepteurs l'utilisent |
|---|---|---|
v= | Version DKIM (toujours 1) | Confirme le format de la signature |
a= | Algorithme de hachage + signature (par ex., rsa-sha256) | Assure que le validateur reproduise correctement la signature |
c= | Règles de canonisation (en-tête/corps) | Normalise les espaces blancs avant le hachage |
t= | Horodatage de la création de la signature | Utilisé pour les vérifications de fraîcheur et la prévention de la relecture |
bh= | Hachage du corps | Le receveur régénère cela pour confirmer l'intégrité du corps du message |
h= | Liste des champs d'en-tête signés | Assure que les en-têtes utilisés lors de la signature sont disponibles et non modifiés |
b= | Signature DKIM réelle | Le receveur vérifie cette signature par rapport à la clé publique |
d= | Domaine signataire | Utilisé pour localiser la clé publique DNS du signataire |
s= | Sélecteur | Combiné avec le domaine pour former : selector._domainkey.domain |
i= | Identité de signature | Doit être identique ou un sous-domaine de d=, identifie l'entité signataire |
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête DKIM-Signature :
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
L'en-tête DKIM-Signature est une série de paires clé-valeur, certaines plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous examinerons celles qui sont principalement d'intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces blancs dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM; ces règles sont appelées « règles de canonisation » (d'où la clé de c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de la création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – C'est le hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – C'est une liste des en-têtes qui ont été utilisés pour créer les données de signature indiquées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ce sont les données réelles de la signature DKIM
Ces trois parties sont d'un plus grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – C'est l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être identique ou un sous-domaine du domaine de la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
Champ | Signification | Comment les récepteurs l'utilisent |
|---|---|---|
v= | Version DKIM (toujours 1) | Confirme le format de la signature |
a= | Algorithme de hachage + signature (par ex., rsa-sha256) | Assure que le validateur reproduise correctement la signature |
c= | Règles de canonisation (en-tête/corps) | Normalise les espaces blancs avant le hachage |
t= | Horodatage de la création de la signature | Utilisé pour les vérifications de fraîcheur et la prévention de la relecture |
bh= | Hachage du corps | Le receveur régénère cela pour confirmer l'intégrité du corps du message |
h= | Liste des champs d'en-tête signés | Assure que les en-têtes utilisés lors de la signature sont disponibles et non modifiés |
b= | Signature DKIM réelle | Le receveur vérifie cette signature par rapport à la clé publique |
d= | Domaine signataire | Utilisé pour localiser la clé publique DNS du signataire |
s= | Sélecteur | Combiné avec le domaine pour former : selector._domainkey.domain |
i= | Identité de signature | Doit être identique ou un sous-domaine de d=, identifie l'entité signataire |
Pour commencer notre compréhension de DKIM, examinons d'abord un en-tête DKIM-Signature :
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
L'en-tête DKIM-Signature est une série de paires clé-valeur, certaines plus intéressantes pour le lecteur que d'autres, mais je vais toutes les décrire ici.
Tout d'abord, nous examinerons celles qui sont principalement d'intérêt passager pour le lecteur :
v=1; – Spécifie la version DKIM (1 est la seule valeur valide)
a=rsa-sha256; – L'algorithme utilisé pour construire les hachages cryptographiques
c=relaxed/relaxed; – Il existe deux ensembles de règles concernant la suppression des espaces blancs dans les en-têtes et le corps qui peuvent être appliqués lors de la création des hachages dans une signature DKIM; ces règles sont appelées « règles de canonisation » (d'où la clé de c) et les ensembles de règles sont soit « relaxés » soit « stricts ».
t=1454417737; – L'horodatage de la création de la signature.
Ces trois parties de l'en-tête contiennent les informations de signature réelles :
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – C'est le hachage du corps du message.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – C'est une liste des en-têtes qui ont été utilisés pour créer les données de signature indiquées ci-dessous.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ce sont les données réelles de la signature DKIM
Ces trois parties sont d'un plus grand intérêt pour le serveur récepteur qui validera la signature :
d=welcome.foo.com; – Cela identifie le domaine qui a signé le message
s=notices; – Le sélecteur; les domaines peuvent avoir plusieurs sélecteurs qu'ils utilisent pour signer des messages.
i=@welcome.foo.com; – C'est l'identité pour le compte de laquelle le message a été signé. Syntaxiquement, cela ressemblera à une adresse e-mail, et pourrait même en être une; la partie locale de l'adresse e-mail peut être vide, comme dans cet exemple, et la partie domaine doit être identique ou un sous-domaine du domaine de la partie d= de la signature.
La raison pour laquelle ces parties intéressent le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.
Champ | Signification | Comment les récepteurs l'utilisent |
|---|---|---|
v= | Version DKIM (toujours 1) | Confirme le format de la signature |
a= | Algorithme de hachage + signature (par ex., rsa-sha256) | Assure que le validateur reproduise correctement la signature |
c= | Règles de canonisation (en-tête/corps) | Normalise les espaces blancs avant le hachage |
t= | Horodatage de la création de la signature | Utilisé pour les vérifications de fraîcheur et la prévention de la relecture |
bh= | Hachage du corps | Le receveur régénère cela pour confirmer l'intégrité du corps du message |
h= | Liste des champs d'en-tête signés | Assure que les en-têtes utilisés lors de la signature sont disponibles et non modifiés |
b= | Signature DKIM réelle | Le receveur vérifie cette signature par rapport à la clé publique |
d= | Domaine signataire | Utilisé pour localiser la clé publique DNS du signataire |
s= | Sélecteur | Combiné avec le domaine pour former : selector._domainkey.domain |
i= | Identité de signature | Doit être identique ou un sous-domaine de d=, identifie l'entité signataire |
DKIM Validation
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être le même ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle est toujours trouvée à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire sa propre série de hachages du message ; si ces hachages correspondent, alors le message n'a pas été altéré en transit, et ainsi, le message peut contribuer à, et peut-être bénéficier de, la réputation établie pour le signataire du message.
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être le même ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle est toujours trouvée à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire sa propre série de hachages du message ; si ces hachages correspondent, alors le message n'a pas été altéré en transit, et ainsi, le message peut contribuer à, et peut-être bénéficier de, la réputation établie pour le signataire du message.
En plus de l'exigence mentionnée selon laquelle le domaine i= doit être le même ou un sous-domaine du domaine d=, les bits d= et s= sont utilisés par le validateur pour rechercher la clé DKIM publique du signataire dans le DNS. La clé est un enregistrement TXT dans le DNS, et elle est toujours trouvée à l'emplacement selector._domainkey.domain. Donc, dans notre exemple ici, avec s=notices et d=welcome.foo.com, la clé DKIM publique serait trouvée dans le DNS à notices._domainkey.welcome.foo.com, et elle pourrait ressembler à ceci :
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Le validateur utilise cette clé (les bits p=) pour produire sa propre série de hachages du message ; si ces hachages correspondent, alors le message n'a pas été altéré en transit, et ainsi, le message peut contribuer à, et peut-être bénéficier de, la réputation établie pour le signataire du message.
Échec de validation et dépannage
J'ai mentionné plus haut que les échecs DKIM peuvent être difficiles à résoudre, et je vais expliquer pourquoi ici.
Certains échecs de validation DKIM ont des causes évidentes, comme le fait que le message n'est pas signé, ou que la clé publique du domaine de signature n'est pas trouvée dans le DNS ou n'est pas syntaxiquement correcte, ou peut-être que le message a été manifestement altéré en transit. Lorsque ces types d'échecs se produisent, il est facile de comprendre le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été manifestement altéré, mais le validateur rapporte que la signature n'a pas réussi à valider.
La raison pour laquelle ils sont difficiles à résoudre tient au fait qu'il n'existe pas de moyen réel pour les deux parties de reproduire les conditions dans lesquelles le message a été signé et validé. Le message a, dans son en-tête DKIM-Signature, les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen de tenter de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont rares, et les échecs de validation DKIM en eux-mêmes n'ont généralement pas d'impact sur le placement de livraison. Bien que DKIM gère l'authentification des messages, mettre en œuvre des techniques de validation complète des emails garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Cela a été mon expérience que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
J'ai mentionné plus haut que les échecs DKIM peuvent être difficiles à résoudre, et je vais expliquer pourquoi ici.
Certains échecs de validation DKIM ont des causes évidentes, comme le fait que le message n'est pas signé, ou que la clé publique du domaine de signature n'est pas trouvée dans le DNS ou n'est pas syntaxiquement correcte, ou peut-être que le message a été manifestement altéré en transit. Lorsque ces types d'échecs se produisent, il est facile de comprendre le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été manifestement altéré, mais le validateur rapporte que la signature n'a pas réussi à valider.
La raison pour laquelle ils sont difficiles à résoudre tient au fait qu'il n'existe pas de moyen réel pour les deux parties de reproduire les conditions dans lesquelles le message a été signé et validé. Le message a, dans son en-tête DKIM-Signature, les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen de tenter de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont rares, et les échecs de validation DKIM en eux-mêmes n'ont généralement pas d'impact sur le placement de livraison. Bien que DKIM gère l'authentification des messages, mettre en œuvre des techniques de validation complète des emails garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Cela a été mon expérience que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
J'ai mentionné plus haut que les échecs DKIM peuvent être difficiles à résoudre, et je vais expliquer pourquoi ici.
Certains échecs de validation DKIM ont des causes évidentes, comme le fait que le message n'est pas signé, ou que la clé publique du domaine de signature n'est pas trouvée dans le DNS ou n'est pas syntaxiquement correcte, ou peut-être que le message a été manifestement altéré en transit. Lorsque ces types d'échecs se produisent, il est facile de comprendre le problème et de recommander une solution. Les plus difficiles, cependant, et ceux qui conduisent à l'expérience de support la plus frustrante, sont les cas où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été manifestement altéré, mais le validateur rapporte que la signature n'a pas réussi à valider.
La raison pour laquelle ils sont difficiles à résoudre tient au fait qu'il n'existe pas de moyen réel pour les deux parties de reproduire les conditions dans lesquelles le message a été signé et validé. Le message a, dans son en-tête DKIM-Signature, les hachages qui ont été générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen de tenter de valider le message de la manière dont le validateur l'a fait.
Les échecs comme ceux que je décris ici sont rares, et les échecs de validation DKIM en eux-mêmes n'ont généralement pas d'impact sur le placement de livraison. Bien que DKIM gère l'authentification des messages, mettre en œuvre des techniques de validation complète des emails garantit que vous envoyez à des adresses légitimes qui peuvent réellement recevoir et authentifier vos messages. Cela a été mon expérience que ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.
