Qu'est-ce que DKIM ? Protocole d'authentification email

DKIM (DomainKeys Identified Mail) est un protocole d'authentification cryptographique pour l'email. Qu'est-ce que DKIM concrètement : chaque message sortant est signé avec une clé RSA privée par votre serveur d'envoi. Le MTA destinataire récupère votre clé publique dans le DNS via le sélecteur, vérifie la signature, et reporte le résultat en dkim=pass ou dkim=fail. Ce résultat alimente le modèle de réputation de votre domaine et détermine si l'alignement DMARC tient. Sans signature valide, le MTA destinataire n'a aucune confirmation cryptographique que le message provient de votre infrastructure.

DKIM est un protocole de signature, pas un filtre

Le nom induit une erreur fréquente. DKIM ne bloque pas les emails. Il ne met pas en quarantaine les messages et n'applique aucune politique seul. Ce qu'il fait : tamponner chaque message sortant d'une affirmation vérifiable. Ce message a été signé par le domaine dans le champ d=, avec la clé privée correspondant au sélecteur s=.

Le MTA destinataire prend cette affirmation, construit une requête DNS vers <sélecteur>._domainkey.<domaine>, récupère l'enregistrement TXT contenant la clé publique, et lance la vérification cryptographique. Si la vérification réussit, l'en-tête d'authentification indique dkim=pass. En cas d'échec, vous voyez dkim=fail ou dkim=temperror.

Aucun de ces résultats n'entraîne un rejet à lui seul. Le signal alimente le modèle de réputation du serveur destinataire et, de façon critique, l'évaluation DMARC. Le rôle de DKIM est de produire un résultat vérifiable, pas d'agir sur celui-ci.

Ce que DKIM signe et ce que couvre la signature

DKIM signe deux choses : certains en-têtes de message et le corps du message. L'algorithme de signature hache les deux et stocke le résultat dans le champ d'en-tête DKIM-Signature.

La liste des en-têtes est contrôlée par le tag h= dans la signature. Un setup de production typique inclut from:subject:date:message-id:content-type. L'en-tête from est le champ qui compte pour l'alignement DMARC. Le hachage du corps couvre l'intégralité du corps du message, canonicalisé via la canonicalisation simple ou relaxed.

La canonicalisation relaxed est celle qu'utilisent la plupart des stacks de production. Elle normalise les espaces blancs avant le hachage, ce qui permet à la signature de survivre à un reformatage mineur par les MTA de relais. La canonicalisation simple est plus stricte : un simple espace en queue casse la signature. Vous trouverez c=relaxed/relaxed dans l'en-tête DKIM-Signature de pratiquement tout ESP bien configuré.

Ce que DKIM ne signe pas : l'enveloppe SMTP, les en-têtes de routage comme Received, et tout en-tête hors de la liste h=. C'est intentionnel. Signer l'enveloppe briserait les scénarios de renvoi, ce qui est précisément l'avantage de DKIM sur SPF.

Le sélecteur : un handle de contrôle d'accès que la plupart des équipes traitent comme un label

Le sélecteur est la partie de DKIM que la plupart des équipes sous-estiment jusqu'au moment où elles doivent effectuer une rotation de clé sous pression.

Le champ s= dans votre DKIM-Signature pointe vers une clé publique spécifique dans votre DNS. Le format de lookup est <sélecteur>._domainkey.<votredomaine.com>. Si votre sélecteur est mail2026 et votre domaine est example.com, le résolveur cherche un enregistrement TXT à mail2026._domainkey.example.com.

Un seul domaine peut avoir plusieurs sélecteurs actifs simultanément. Chaque service d'envoi, chaque ESP, chaque MTA interne devrait utiliser son propre sélecteur. Cela vous donne trois capacités opérationnelles concrètes :

• Rotation de clé indépendante par service sans toucher aux autres expéditeurs.

• Attribution traçable dans les logs d'authentification : le sélecteur vous indique quelle clé de signature a été utilisée pour chaque message.

• Offboarding propre : supprimez l'enregistrement DNS du sélecteur, et cet ESP ne peut plus signer au nom de votre domaine, quoi qu'il fasse de son côté.

À l'usage, voilà ce qu'on observe dans les traces : les équipes qui configurent un sélecteur partagé sur tous leurs services d'envoi ne peuvent pas révoquer l'accès à un expéditeur sans perturber tous les autres. Le sélecteur n'est pas cosmétique. C'est un handle de contrôle d'accès.

DKIM et alignement DMARC : comment fonctionne réellement la couche d'application

Un dkim=pass est un prérequis pour un type spécifique de succès DMARC appelé alignement DKIM.

DMARC exige au moins l'une des deux conditions d'alignement : alignement SPF ou alignement DKIM. L'alignement DKIM signifie que le domaine dans l'en-tête From: correspond à la valeur d= dans la signature DKIM, et que la signature est vérifiée. Quand les deux conditions sont remplies, DMARC considère le message comme authentifié.

C'est pourquoi DKIM est le signal d'authentification le plus durable. L'alignement SPF se casse sur le renvoi : quand un message est renvoyé, l'expéditeur de l'enveloppe SMTP change, et l'évaluation SPF échoue face à la nouvelle IP d'envoi. L'alignement DKIM survit au renvoi parce que la signature et l'en-tête From: voyagent avec le corps du message et ne sont pas réécrits par les MTA de relais, à condition que le corps ne soit pas modifié en transit.

Pour les domaines avec une politique DMARC p=reject, un message qui échoue à la fois l'alignement SPF et DKIM est rejeté par le MTA destinataire. C'est le mécanisme qui empêche les emails usurpés de votre domaine d'atteindre les boîtes de réception à grande échelle. DKIM n'est pas la dernière ligne de défense ici. Mais c'est la ligne qui tient quand le renvoi est dans le chemin.

Depuis 2024, Google, Yahoo et Microsoft exigent DKIM pour les expéditeurs en masse envoyant 5 000 messages par jour ou plus vers leurs MX. Les messages de domaines non signés sont routés vers le spam ou rejetés par défaut.

Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure.

Longueur de clé et rotation : décisions pratiques pour 2026

La plupart des implémentations DKIM utilisent RSA-SHA256. La vraie question est la longueur de clé.

Les clés RSA 1024 bits apparaissent encore dans les configurations héritées. Le NIST a déprécié RSA 1024 bits pour la plupart des usages en 2015. Une clé 2048 bits offre une marge de sécurité nettement supérieure et est supportée par tous les MTA et fournisseurs de réception majeurs. Si vous générez une nouvelle clé aujourd'hui, utilisez 2048 bits.

Certaines équipes ont migré leur clé de signature active vers 2048 bits mais ont laissé d'anciens sélecteurs 1024 bits publiés dans le DNS parce que personne n'a audité l'inventaire. Trois signaux qui changent le comportement du moteur : si vous voyez k=rsa avec une clé 1024 bits dans un ancien sélecteur, ce sélecteur est une vulnérabilité même si votre infrastructure de signature actuelle a déjà évolué. Un sélecteur valide mais déprécié est exploitable.

Planning de rotation des clés : la plupart des équipes infrastructure font une rotation annuelle, certaines trimestrielle pour les domaines à plus haute sensibilité. L'ordre des étapes compte :

1. Générer une nouvelle paire de clés.

2. Publier la nouvelle clé publique sous un nouveau nom de sélecteur dans le DNS.

3. Attendre la propagation TTL, typiquement 24 à 48 heures pour les enregistrements à faible TTL.

4. Basculer la clé de signature dans la configuration de votre MTA vers le nouveau sélecteur.

5. Vérifier dkim=pass sur les messages sortants via un outil de test email ou en inspectant les en-têtes de résultats d'authentification sur un message de test.

6. Après confirmation que la nouvelle clé est active et signe correctement, supprimer l'ancien enregistrement DNS.

La rotation n'est pas perturbatrice si vous respectez l'ordre : DNS d'abord, bascule de clé ensuite, suppression de l'ancien enregistrement en dernier. Inverser les étapes 4 et 6 crée une fenêtre dkim=fail.

Signaux opérationnels à surveiller après la mise en place de DKIM

DKIM n'est pas une tâche de configuration ponctuelle. Les signaux suivants indiquent qu'une dérive ou une panne s'est produite.

dkim=temperror dans les en-têtes reçus. Les échecs temporaires indiquent généralement des problèmes de résolution DNS côté destinataire, ou un décalage TTL pendant la rotation des clés. Si vous observez cela sur les messages sortants peu après une rotation de clé, attendez la propagation complète avant de conclure que la clé elle-même est mal configurée.

dkim=fail sur les messages que vous avez envoyés. La modification du corps par un relais intermédiaire est la cause la plus fréquente. Vérifiez si un saut de renvoi, un processeur de liste de diffusion ou un relais qui injecte des pieds de page est dans le chemin de livraison. Si l'échec est constant sur un seul flux, cartographiez la chaîne de relais saut par saut.

En-tête DKIM-Signature manquant. Le démon de signature sur votre MTA ne fonctionne pas, le chemin de la clé de signature est incorrect, ou le mapping domaine-sélecteur est mal configuré dans votre configuration MTA. C'est une panne DKIM complète pour les flux de messages concernés.

Enregistrement TXT du sélecteur absent du DNS. La zone DNS a été modifiée ou migrée sans conserver l'enregistrement du sélecteur DKIM. Vérifiez avec dig TXT <sélecteur>._domainkey.<domaine> depuis un résolveur externe.

Sur un setup d'envoi multi-région, des résultats DKIM incohérents entre les nœuds sont fréquemment causés par des nœuds utilisant des configurations de sélecteur différentes. Confirmez que la configuration de la clé de signature est synchronisée sur tous les nœuds d'envoi avant de déployer une rotation.

Ce que DKIM ne protège pas

DKIM n'est pas un filtre anti-spam. Un expéditeur peut enregistrer un nouveau domaine, configurer DKIM valide, et envoyer du spam pleinement authentifié. La signature est vérifiée proprement. L'authentification confirme l'origine, pas l'intention ou la qualité du contenu.

DKIM ne traite pas non plus l'usurpation de nom d'affichage, où l'en-tête From: affiche un nom de confiance comme "Équipe Paie" associé à un domaine contrôlé par un attaquant. La vérification cryptographique opère sur le domaine, pas sur la présentation visuelle dans le MUA. La plupart des tentatives de phishing au niveau MUA reposent sur la tromperie de nom d'affichage plutôt que sur l'usurpation du domaine exact.

Ce que DKIM protège : l'usurpation de domaine exact, où un attaquant tente d'envoyer depuis votre domaine sans posséder votre clé privée. Combiné à une politique DMARC p=reject appliquant l'alignement DKIM, cela empêche cette classe de message usurpé d'atteindre les boîtes de réception chez les fournisseurs qui appliquent DMARC.

En pratique : DKIM seul ne suffit pas. Le modèle de protection nécessite l'application de la politique DMARC par le MTA destinataire. DKIM est la couche d'authentification qui rend DMARC signifiant. SPF est l'autre couche d'authentification, et il gère la vérification de l'expéditeur de l'enveloppe. Les trois fonctionnent ensemble. L'absence de l'un d'eux laisse une brèche dans la chaîne d'application.

Si vous avez déjà configuré DKIM et SPF mais n'avez pas encore publié d'enregistrement DMARC, les signatures existent mais aucune politique d'application n'est active. Le mode surveillance (p=none avec rapports rua) est une première étape raisonnable : vous obtenez des rapports agrégés indiquant les taux de réussite d'authentification sur votre domaine d'envoi avant de vous engager vers p=quarantine ou p=reject.