La norme d’authentification des e-mails DomainKeys Identified Mail (DKIM) permet aux serveurs de messagerie de vérifier les e-mails entrants afin de confirmer l’identité de l’expéditeur et de détecter toute modification des messages. Cette norme permet de déterminer si des e-mails ont été interceptés et modifiés pendant leur acheminement, et contribue à détecter les courriers indésirables et les e-mails usurpés.
En mettant en œuvre le DKIM, une organisation améliore la réputation de ses propres e-mails et permet aux serveurs de messagerie destinataires de renforcer leur propre sécurité.
Cet article vous aide à comprendre :
- Comment fonctionne le DKIM ?
- Comment configurer le DKIM
- Tester le fonctionnement du DKIM
- Avantages du DKIM
- Inconvénients du DKIM
- FAQ sur le DKIM
- En résumé
Comment fonctionne le DKIM ?
À un niveau général, le DKIM permet à une organisation de fournir des valeurs de hachage chiffrées pour les principaux éléments d’un e-mail. Grâce à des paires de clés de chiffrement publique et privée, les serveurs de messagerie destinataires peuvent comparer la valeur de hachage de l’e-mail reçu à la valeur de hachage reçue afin de vérifier si des modifications ont été effectuées pendant l’acheminement.
Une vérification DKIM réussie confirme également la propriété de l’e-mail en comparant l’organisation indiquée dans les champs « from » de l’e-mail avec le DNS associé à cette organisation. Les e-mails dont les valeurs de hachage DKIM ne correspondent pas peuvent avoir été modifiés et être rejetés, placés en quarantaine ou marqués comme courrier indésirable afin d’alerter le destinataire.
Principes fondamentaux du DKIM
L’Internet Engineering Task Force (IETF) publie des informations complètes sur le DKIM et ses normes, dont la dernière mise à jour date de 2011. Le DKIM est déployé sous forme de fichiers texte dans l’enregistrement DNS (Domain Name Service) hébergé d’une organisation, mais la norme peut être complexe à déployer et à maintenir correctement. Heureusement, cette complexité peut être facilement maîtrisée en comprenant les différents composants et leur fonctionnement.
Structure de base d’un enregistrement DNS DKIM
L’enregistrement DNS DKIM est très simple et transmet des informations à la fois par son contenu et par son nom de fichier. Le contenu ressemble souvent à ceci :
v=DKIM1; p=76E679F05F709AF665853833EEC3F5ADE69A2392BEBE40658267AB3BD3CB6CBE« v » désigne la version et est toujours égal à DKIM1. Le champ « p » contient la valeur de la clé de chiffrement publique.
Le nom de fichier suit le format <selector>._domainkey.<domain>. Selector indique la version du fichier, et l’organisation dispose d’un selector différent pour chaque serveur de messagerie. Domain est le domaine de l’organisation. Par exemple, le nom de fichier nashville._domainkey.exampledomain.com correspond au selector nashville de l’organisation qui utilise exampledomain.com.
Processus DKIM de base
Le processus DKIM se déroule en plusieurs étapes :
- L’organisation publie le fichier DKIM avec son DNS
- L’organisation détermine quels champs d’en-tête inclure dans le processus de hachage et s’il faut hacher l’intégralité du corps du message ou seulement une partie
- Le serveur de messagerie expéditeur calcule la valeur de hachage des champs sélectionnés et inclut les informations DKIM dans l’e-mail sous forme de signature DKIM (voir ci-dessous) lors de son envoi
- Le serveur de messagerie ou la passerelle de messagerie destinataire utilise la signature DKIM incluse et la clé de chiffrement publique de l’organisation (stockée dans l’enregistrement DKIM associé au DNS) pour recalculer et vérifier la signature DKIM
À titre de précaution, lors de la détermination des éléments à hacher, l’organisation doit trouver un équilibre entre précision et facilité d’utilisation. Un plus grand nombre de champs et de caractères offre davantage de sécurité, mais les e-mails subissent souvent de légères modifications lors de leur envoi et de leur transfert, ce qui peut faire échouer le calcul de la valeur de hachage d’un e-mail manifestement identique et intact, à cause d’espaces ou de sauts de ligne supplémentaires.
Voir les principales solutions de passerelle de messagerie sécurisée
Signature e-mail DKIM
L’organisation expéditrice détermine quels champs de l’e-mail seront chiffrés afin de créer la chaîne de hachage DKIM à inclure dans l’e-mail envoyé sous forme de signature numérique. Le serveur de messagerie expéditeur prend les valeurs textuelles des champs sélectionnés et crée une chaîne de hachage à l’aide d’un algorithme de hachage, généralement SHA-256. Une fois la chaîne de hachage générée, le serveur de messagerie utilise une clé de chiffrement privée pour la chiffrer et inclut la chaîne chiffrée dans l’en-tête de l’e-mail sous forme de signature e-mail DKIM.
Généralement, l’organisation sélectionne le domaine expéditeur et certaines parties du corps du message pour générer la valeur de hachage.
Exemple :
DKIM-Signature: v=1; a=rsa-sha256; d=sampledomain.com; s=nashville;
c=relaxed; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzRLes éléments constitutifs de ce fichier sont les suivants :
| Élément et valeur | Signification | Élément obligatoire ? |
|---|---|---|
| v=1 | v=Version, toujours égal à 1 | Obligatoire |
| a=rsa-sha256 | a=Algorithme de signature. Bien que de nombreux algorithmes puissent être utilisés, les serveurs de messagerie peuvent ne prendre en charge que rsa-sha ou rsa-sha256 | Obligatoire |
| d= sampledomain.com | d=Identifiant du domaine de signature (SDID), ou domaine de l’organisation qui envoie l’e-mail et domaine où se trouvent le DNS et l’enregistrement DKIM | Obligatoire |
| s=nashville | s=Selector – nom unique de ce fichier DKIM ; lorsque plusieurs fichiers DKIM sont utilisés, le serveur de messagerie destinataire recherche la clé publique correcte en fonction du nom du selector | Obligatoire |
| c=relaxed | c=Algorithme de canonicalisation ; les valeurs peuvent être « relaxed » ou « simple » ; lors du calcul de la valeur de hachage, faut-il effectuer un calcul simple et ne tolérer aucune modification de l’en-tête ou du corps de l’e-mail, ou effectuer un calcul relaxed et autoriser de petites modifications de la mise en forme de l’en-tête ou du traitement des espaces blancs dans le corps de l’e-mail | Non, mais recommandé |
| q=dns/txt | q=Méthode de requête utilisée pour récupérer la clé publique ; par défaut, « dns/txt », ce qui signifie qu’une requête DNS doit être utilisée et qu’un fichier texte (TXT) sera renvoyé | Obligatoire |
| t=1127574938 | t=Horodatage, ou moment où le message a été signé | Obligatoire |
| x=1168006938 | x=Expiration du DKIM ; après cette date d’expiration, le DKIM échouera même si toutes les autres vérifications correspondent | Non, mais recommandé |
| h=from:to:subject: Date:keywords: keywords; | h=En-têtes, liste d’en-têtes séparés par des deux-points dans l’en-tête de l’e-mail et inclus dans le calcul DKIM ; il est préférable d’éviter les champs d’en-tête susceptibles d’être modifiés pendant l’acheminement | Obligatoire |
| bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=Corps du message haché après canonicalisation à l’aide de la fonction de hachage indiquée par a (ci-dessus) | Obligatoire |
| b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR | b=Signature numérique des en-têtes et du corps hachés à l’aide de la fonction de hachage indiquée par a (ci-dessus) ; bien qu’il s’agisse de la signature, toutes les autres informations DKIM contenues dans l’e-mail indiquent comment calculer correctement le hachage de la signature | Obligatoire |
| i (non inclus ci-dessus) | i = Balise d’identifiant de l’agent ou de l’utilisateur (AUID), utilisée lorsque la valeur par défaut du domaine SDID est précédée du caractère @ | Non |
| l (non inclus ci-dessus) | l = longueur du corps du message ; valeur limitée à 76 chiffres décimaux au maximum et indiquant le nombre d’octets du corps du message | Non |
| z (non inclus ci-dessus) | z = Champs d’en-tête copiés qui afficheraient tous les champs d’en-tête et leur contenu, séparés par une barre verticale (|) |
Selector DKIM
Le serveur DNS d’une organisation héberge une entrée DKIM, ou selector, pour chaque serveur de messagerie de l’organisation. Le nom unique du selector est inclus dans le nom du fichier DKIM ainsi que dans la balise « s » de la signature de l’e-mail envoyé, afin que le serveur de messagerie destinataire sache quelle entrée DKIM utiliser lors du processus de vérification DKIM.
Rotation des clés DKIM
Comme pour toute utilisation du chiffrement, plus une clé reste en service longtemps, plus elle risque d’être volée ou compromise. Pour réduire ce risque, il est recommandé de renouveler les clés (en remplaçant les clés actuelles par de nouvelles) tous les 4 à 6 mois.
Comment les serveurs de messagerie vérifient-ils le DKIM ?
Lorsqu’un e-mail arrive sur le serveur de messagerie destinataire avec une signature DKIM chiffrée, l’en-tête est examiné afin d’identifier les informations relatives aux champs utilisés pour le chiffrement, au type d’algorithme de hachage utilisé et au selector DKIM permettant de rechercher la clé de chiffrement publique. Le serveur de messagerie destinataire chiffre ensuite lui-même les champs indiqués de l’e-mail, utilise la clé publique pour déchiffrer le code de hachage de la signature chiffrée et recherche une correspondance.
La correspondance des codes de hachage DKIM confirme l’intégrité de l’e-mail, et les e-mails qui passent ce processus sont remis au destinataire. Les codes de hachage qui ne correspondent pas sont supprimés, placés dans un dossier de courrier indésirable ou signalés comme suspects, selon les paramètres du serveur de messagerie.
Normes d’authentification des e-mails associées
Le DKIM authentifie l’intégrité des e-mails envoyés, mais dans un cadre limité. Une solution plus robuste mettra également en œuvre les frameworks d’autorisation SPF et DMARC.
SPF : La Sender Policy Framework (SPF) désigne les serveurs de messagerie autorisés à envoyer des e-mails depuis le domaine d’une organisation.
DMARC :Domain-based Message Authentication Reporting and Conformance (DMARC) permet de contrôler plus directement les e-mails qui échouent aux vérifications SPF et DKIM et d’établir des rapports sur les e-mails légitimes et les e-mails usurpés.
Comment configurer Domain Keys Identified Email (DKIM)
Domain Keys Identified Email (DKIM) nécessite l’ajout de fichiers au serveur DNS du domaine, la génération de clés de chiffrement ainsi que des modifications des serveurs de messagerie sortants.
Installer un enregistrement DKIM avec le DNS du domaine
L’ajout d’une entrée DKIM au DNS d’un domaine comprend les étapes suivantes :
- Connectez-vous au bureau d’enregistrement du domaine et cliquez sur l’option permettant de gérer ou de configurer les paramètres DNS
- Recherchez et cliquez sur l’option « Add a New Record », puis choisissez un enregistrement « TXT »
- Pour l’option de nom d’hôte, le DKIM exige un « selector » unique dans le nom du fichier DKIM pour chaque serveur de messagerie émetteur
- Chaque fichier nécessite la publication d’une clé cryptographique publique ; cette clé doit être unique pour chaque selector
Générer les clés de chiffrement DKIM
Il existe plusieurs façons de générer une clé publique pouvant être utilisée pour un enregistrement DKIM. Dans de nombreux cas, une organisation constatera que sa signature DKIM est générée par l’application Mail Transfer Agent (MTA). Pour d’autres, des clés générées manuellement peuvent être nécessaires.
Sur les systèmes Linux, une approche courante consiste à utiliser l’outil ssh-keygen, tandis que sous Windows, PuTTYgen constitue une option raisonnable. Il existe également plusieurs outils en ligne capables de générer la paire de clés publique/privée ; l’un des plus simples est DKIM Core Tools.
Configurer le signataire DKIM sur un serveur de messagerie
L’entrée DNS du DKIM ne constitue que la moitié des exigences. L’autre moitié consiste à configurer un signataire DKIM sur un serveur de messagerie, ce qui peut s’avérer complexe ou difficile pour de nombreux systèmes de messagerie.
Cependant, de nombreux fournisseurs de messagerie publient des guides pour configurer le DKIM et certains proposent des services pour aider leurs clients. Parmi les guides publiés, on peut citer :
Les entreprises qui préfèrent externaliser ces opérations peuvent faire appel à des fournisseurs de services et à des consultants DKIM proposant une variété de services, depuis la configuration initiale de base jusqu’à la gestion continue et au renouvellement des clés de chiffrement.
En savoir plus : Guide étape par étape de la configuration et du paramétrage de DMARC.
Tester le fonctionnement du DKIM
Une fois le DKIM publié, des analyseurs tels que MXToolbox ou Mail-tester.com peuvent être utilisés pour rechercher d’éventuelles erreurs. Des e-mails de test peuvent ensuite être envoyés afin de vérifier les fichiers de signature DKIM.
Une fois le message de test reçu, développez l’en-tête de l’e-mail. Si le domaine de l’expéditeur apparaît à la fois dans « mailed-by » et dans « signed-by », le message a été vérifié avec succès par le DKIM.
Les options « Show Original » peuvent également servir à inspecter l’en-tête de l’e-mail et à observer le résultat de l’authentification DKIM. Si la mention « PASS » et l’adresse du domaine apparaissent, tout fonctionne correctement.
Avantages du DKIM
Les organisations qui adoptent le DKIM peuvent bénéficier des avantages importants suivants.
Signale les contenus malveillants
Les e-mails qui n’aboutissent pas à une vérification DKIM éveillent les soupçons des serveurs de messagerie destinataires : l’e-mail reçu peut avoir été intercepté et son contenu peut contenir du spam, voire du contenu malveillant.
Réduit les risques d’usurpation d’identité
Les attaques de phishing connues sous le nom de tentatives d’usurpation d’adresse e-mail cherchent à se faire passer pour des organisations légitimes et à transmettre aux victimes du contenu malveillant sous couvert de l’autorité de l’organisation usurpée. Lorsqu’un DKIM correctement configuré est déployé, il devient plus difficile d’usurper l’identité de l’organisation.
Lorsqu’un serveur de messagerie reçoit un e-mail usurpé, il recherche les signatures DKIM et rejette l’e-mail usurpé qui échoue à la vérification DKIM. Cela contribue à protéger la réputation de l’entreprise en bloquant les e-mails indésirables qui tentent d’utiliser la marque de l’organisation. En outre, cela contribue à bloquer les attaques de phishing cherchant à usurper l’identité des propres employés de l’organisation, par exemple lorsqu’une attaque de phishing tente de se faire passer pour le directeur général.
Améliore la réputation du domaine
Lorsqu’une organisation ne met pas en place le DKIM, les serveurs de messagerie qui reçoivent ses e-mails peuvent les signaler ou les rejeter, car l’authenticité du domaine de l’organisation ne peut pas être vérifiée. La mise en place du DKIM améliore la réputation du domaine de l’organisation et le taux de délivrabilité des e-mails légitimes. L’entreprise de services de messagerie Postmark a publié un processus de résolution des problèmes qui démontre concrètement comment les signatures DKIM permettent de remettre correctement des e-mails contenant des documents PDF, au lieu de les acheminer vers les dossiers de courrier indésirable.
Résiste au transfert des e-mails
La norme Sender Policy Framework (SPF) peut valider les serveurs de messagerie autorisés à envoyer des e-mails pour l’organisation, mais les e-mails transférés ne correspondent pas aux adresses IP du serveur de messagerie émetteur et échouent à la vérification SPF. En revanche, les algorithmes de chiffrement DKIM résistent au transfert des e-mails et peuvent valider les e-mails transférés afin d’éviter que leur contenu soit signalé comme du spam ou comme une usurpation.
Inconvénients du DKIM
Bien qu’il s’agisse d’une norme importante et utile à adopter, le DKIM présente certaines difficultés qu’il convient de reconnaître.
Difficile à maintenir
Les organisations doivent régulièrement mettre à jour leurs fichiers DKIM pour tenir compte de l’évolution des informations relatives aux serveurs de messagerie ou pour renouveler les clés de chiffrement. Les fournisseurs de services peuvent simplifier le processus, mais ils ajouteront des coûts supplémentaires à l’adoption du DKIM.
Les propriétaires de domaines devraient idéalement suivre et renouveler régulièrement leurs clés, mais certains tentent d’utiliser la même clé pour tous les services, ce qui rend le suivi impossible et le renouvellement des clés plus difficile.
Une solution incomplète
Le DKIM vérifie uniquement l’intégrité de l’en-tête de l’e-mail et ne la compare pas à l’adresse e-mail « from » présentée à l’utilisateur. Si un attaquant pratiquant le phishing crée ses propres clés de chiffrement DKIM, une vérification DKIM peut tout de même être considérée comme valide. Pour une protection plus robuste, SPF, DKIM et DMARC doivent être utilisés conjointement afin de protéger la réputation d’une organisation et de valider les e-mails.
Vol des clés de chiffrement
Les clés de chiffrement peuvent être volées ; un attaquant qui obtient la clé de chiffrement d’une organisation peut signer des e-mails comme s’il représentait lui-même l’organisation.
Mesure difficile du retour sur investissement
Même si une organisation peut constater une amélioration de sa réputation et une délivrabilité plus fiable de ses e-mails, ces avantages seront difficiles à quantifier dans le cadre de la mesure du retour sur investissement. En outre, le principal avantage lié au signalement des contenus malveillants ne s’applique généralement qu’aux autres organisations. Les serveurs de messagerie destinataires et les outils de sécurité de la messagerie utilisent l’enregistrement DKIM pour bloquer le spam et les e-mails de phishing, mais ce sont les organisations externes qui bénéficient principalement des e-mails vérifiés. Bien que l’investissement nécessaire à la mise en œuvre du DKIM soit faible, le retour sur investissement intangible et les autres inconvénients expliquent pourquoi l’adoption ne dépasse pas 13 %.
Susceptible d’être usurpé
Le DKIM peut être adopté par n’importe quelle organisation, y compris des acteurs malveillants et des spammeurs. Comme une vérification DKIM n’inclut pas toujours les informations « From » dans le corps de l’e-mail, les acteurs malveillants peuvent publier leurs propres fichiers DKIM pour authentifier leurs e-mails usurpés ou leurs spams.
Nécessite des paramètres appropriés du serveur de messagerie
Le DKIM ne fonctionne que sur les serveurs de messagerie configurés pour vérifier le DKIM ou qui utilisent des outils de sécurité de la messagerie effectuant la même tâche. Les serveurs peuvent facilement ignorer les vérifications DKIM et permettre la prolifération des e-mails indésirables et usurpés.
Surcharge du serveur
Le calcul des valeurs de hachage et la recherche d’enregistrements DNS ralentissent la remise des e-mails et consomment des ressources du serveur. Bien que la demande ne soit pas très importante pour un e-mail donné, un grand nombre d’e-mails peut entraîner une charge considérable sur les serveurs.
FAQ sur le DKIM
Comment fonctionne le chiffrement DKIM ?
Le serveur de messagerie émetteur détermine quels champs de l’e-mail seront chiffrés. La clé privée du domaine de l’expéditeur est encodée dans la signature numérique de chaque e-mail envoyé. Une clé publique est stockée dans le Domain Name System (DNS) afin que tout serveur de messagerie recevant des e-mails dotés de la signature numérique chiffrée puisse la télécharger. La signature DKIM chiffre la valeur de hachage de l’e-mail, mais ne chiffre aucun élément de l’e-mail lui-même.
Une signature DKIM peut-elle être falsifiée ?
Bien que la clé de chiffrement publique soit disponible, une signature DKIM ne peut pas être falsifiée. Le DKIM repose sur une infrastructure à clés publiques (PKI), ce qui signifie qu’une paire de clés, l’une publique et l’autre privée, est utilisée. Alors que la clé publique est publiée dans l’enregistrement DNS, la clé privée reste exclusivement sur le serveur du fournisseur de services de messagerie. La clé privée secrète sert à signer les messages, tandis que la clé publique sert uniquement à la vérification.
Le DKIM fournit-il un chiffrement de bout en bout ou un chiffrement complet des e-mails ?
Non. Le DKIM fournit une valeur de hachage chiffrée dans la signature DKIM, mais n’offre aucun autre avantage en matière de chiffrement. Les organisations doivent adopter d’autres solutions de chiffrement si nécessaire.
Le DKIM est-il similaire à d’autres protocoles de signature des messages ?
Les protocoles de signature des messages tels que Pretty Good Privacy (PGP) et Secure/Multipurpose Internet Mail Extensions (S/MIME) permettent aux utilisateurs d’authentifier le corps du message d’un e-mail. Cependant, ces protocoles ne permettent pas d’authentifier l’expéditeur. Le DKIM authentifie à la fois l’expéditeur, le contenu et les champs de l’e-mail.
En résumé : mettez en œuvre le DKIM pour améliorer la délivrabilité des e-mails
L’authentification des e-mails par DKIM donne aux serveurs de messagerie destinataires une confiance accrue dans la validité du message et augmente la probabilité que celui-ci soit remis comme prévu. Bien que la maintenance de cette norme puisse prendre du temps, cette confiance accrue devrait à elle seule suffire à convaincre la plupart des organisations de mettre en œuvre le DKIM ; les autres avantages, liés à la réduction des e-mails usurpés, à l’amélioration du transfert des e-mails et à la réduction des risques d’usurpation d’identité, contribuent simplement à justifier cet effort.
À lire ensuite : Qu’est-ce que la sécurité réseau ? Définition, menaces et protections
Cet article a été initialement rédigé et publié par Sean Michael Kerner le 12 janvier 2018 et mis à jour par Chad Kime le 24 mai 2023.