Chaque jour, des milliards d’emails circulent entre entreprises, administrations, plateformes en ligne et particuliers. Pourtant, un message peut facilement être falsifié en apparence : un expéditeur peut être imité, un domaine usurpé, un contenu modifié. C’est précisément pour réduire ce risque que l’authentification DKIM s’est imposée comme l’un des piliers de la sécurité email.
DKIM, pour DomainKeys Identified Mail, est un mécanisme qui permet à un serveur de messagerie de signer cryptographiquement un email au nom d’un domaine. L’objectif n’est pas de chiffrer le message ni de masquer son contenu, mais de prouver que certaines parties de l’email n’ont pas été altérées depuis son envoi.
Concrètement, lorsqu’une entreprise envoie un email depuis une adresse comme contact@example.com, son serveur ajoute une signature dans l’en-tête du message. Le serveur du destinataire peut ensuite vérifier cette signature grâce à une clé publique publiée dans le DNS du domaine example.com. Si la vérification réussit, l’email gagne en crédibilité.
L’email a été conçu à une époque où la confiance entre serveurs était beaucoup plus implicite qu’aujourd’hui. Le protocole SMTP, encore utilisé pour transporter les messages, ne vérifie pas à lui seul qu’un expéditeur est bien autorisé à envoyer depuis un domaine donné. Cette faiblesse a ouvert la voie au phishing, à l’usurpation d’identité et aux campagnes de spam.
DKIM répond à ce problème en ajoutant une preuve technique. Il ne dit pas qu’un message est légitime sur le fond, mais il confirme qu’il a bien été signé par un système autorisé à utiliser le domaine. Pour une banque, un site e-commerce ou un service SaaS, cette validation est essentielle : elle contribue à protéger la réputation du domaine et à améliorer la délivrabilité des emails.
Le fonctionnement de DKIM repose sur un principe classique de cryptographie asymétrique : une paire de clés. La clé privée reste sur le serveur d’envoi et sert à générer la signature. La clé publique, elle, est publiée dans le DNS afin que les serveurs destinataires puissent vérifier cette signature sans connaître le secret.
Cette logique est différente du chiffrement de bout en bout. Le contenu de l’email reste lisible par les systèmes qui le traitent, mais son intégrité peut être contrôlée. La distinction est importante, car de nombreux protocoles historiques n’ont pas été pensés avec la sécurité comme priorité initiale, comme l’illustre l’explication sur les limites de certains échanges non chiffrés par défaut.
Quand un email est prêt à partir, le serveur d’envoi sélectionne plusieurs éléments du message : certains en-têtes, parfois une partie du corps, puis applique une fonction de hachage. Le résultat obtenu est ensuite signé avec la clé privée du domaine. Cette signature est ajoutée dans un en-tête spécifique appelé DKIM-Signature.
Cet en-tête contient plusieurs informations utiles. On y trouve notamment le domaine signataire, le sélecteur DKIM, l’algorithme utilisé, la liste des champs signés et la signature elle-même. Par exemple, un domaine peut utiliser un sélecteur nommé “mail2024” pour indiquer au serveur destinataire où chercher la clé publique correspondante dans le DNS.
À la réception, le serveur de messagerie lit l’en-tête DKIM-Signature. Il identifie le domaine signataire et le sélecteur, puis effectue une requête DNS pour récupérer la clé publique. Cette clé est généralement publiée sous forme d’enregistrement TXT, à une adresse du type selector._domainkey.example.com.
Le DNS joue donc un rôle central dans l’authentification DKIM. Sans enregistrement correct, la vérification échoue, même si le message a été signé au départ. Les questions de confidentialité et de résolution DNS sont d’ailleurs devenues plus visibles avec des technologies comme la résolution DNS chiffrée via HTTPS, même si DKIM repose avant tout sur la disponibilité publique des clés.
Une signature DKIM n’est pas une simple marque ajoutée à la fin d’un message. Elle est structurée et normalisée. Le champ “d=” indique le domaine signataire, “s=” le sélecteur, “h=” les en-têtes inclus dans la signature, “bh=” le hachage du corps du message et “b=” la signature cryptographique.
Un autre élément souvent méconnu est la canonicalisation. Elle définit la manière dont le message est normalisé avant vérification. Deux modes existent principalement : “simple” et “relaxed”. Le mode relaxed tolère certaines variations mineures, comme des espaces modifiés, ce qui évite des échecs injustifiés lorsque des relais intermédiaires ajustent légèrement le format du message.
DKIM n’agit pas seul. Il est souvent associé à SPF et DMARC. SPF vérifie si l’adresse IP du serveur d’envoi est autorisée à envoyer des emails pour un domaine. DKIM vérifie l’intégrité et la signature du message. DMARC, enfin, indique aux serveurs destinataires quoi faire lorsque SPF ou DKIM échouent, par exemple accepter, mettre en quarantaine ou rejeter l’email.
Cette combinaison crée une politique plus robuste. Un domaine peut par exemple publier une règle DMARC demandant le rejet des emails qui échouent aux contrôles d’authentification. Comme dans d’autres domaines du Web, la sécurité repose rarement sur une seule barrière ; elle s’inscrit dans un ensemble de mécanismes, à l’image des contrôles décrits pour la gestion des échanges entre origines dans les navigateurs.
DKIM peut échouer pour des raisons très pratiques. Une clé publique mal copiée dans le DNS, un sélecteur incorrect, une clé trop ancienne ou un prestataire d’envoi mal configuré suffisent à invalider la signature. Les transferts d’emails peuvent aussi poser problème si un service modifie le contenu du message ou certains en-têtes signés.
Il faut également rappeler que DKIM ne garantit pas la vérité du contenu. Un email frauduleux peut être correctement signé s’il provient d’un domaine compromis ou d’un service légitime mal utilisé. La signature prouve une origine technique, pas une intention honnête. C’est pourquoi les signaux d’authentification doivent être croisés avec la réputation du domaine, les filtres antispam et l’analyse comportementale.
Les systèmes modernes doivent aussi gérer les échecs de manière claire. Dans l’écosystème Web, les codes d’erreur aident à diagnostiquer les blocages, comme le montre l’analyse du code HTTP 451 et de ses causes possibles. Pour l’email, les rapports DMARC jouent un rôle comparable : ils permettent d’identifier les sources autorisées, les erreurs de configuration et les tentatives d’usurpation.
Pour mettre en place DKIM correctement, il faut d’abord générer une paire de clés auprès du service d’envoi ou du serveur de messagerie utilisé. La clé publique doit ensuite être publiée dans le DNS, avec le bon sélecteur. Une fois la propagation DNS effectuée, des tests d’envoi permettent de vérifier que la signature apparaît bien et qu’elle est validée par les principaux fournisseurs de messagerie.
Il est recommandé de faire tourner les clés régulièrement, surtout pour les organisations exposées ou utilisant plusieurs prestataires d’emailing. Une clé de 2048 bits est généralement préférable à une clé de 1024 bits, lorsque le fournisseur DNS l’accepte correctement. Les entreprises doivent aussi tenir un inventaire précis des services autorisés à envoyer des emails en leur nom.
Enfin, DKIM doit être pensé comme une composante d’une stratégie plus large. Les protocoles évoluent, les infrastructures aussi, et les mécanismes de confiance doivent s’adapter. Les transformations observées dans le transport Web, par exemple avec le protocole QUIC utilisé par HTTP/3, rappellent que performance, sécurité et fiabilité progressent souvent ensemble. Pour l’email, DKIM reste aujourd’hui un outil discret mais essentiel pour restaurer une part de confiance dans un canal historiquement fragile.
