DKIM

01 — DéfinitionQu'est-ce que DKIM ?

DKIM, pour DomainKeys Identified Mail, est un protocole d'authentification email défini par la RFC 6376. Son principe : signer cryptographiquement chaque email au moment de son envoi, de manière à ce que le serveur destinataire puisse ensuite vérifier deux choses à la fois : que le message provient bien d'un serveur autorisé par le domaine expéditeur, et qu'il n'a pas été modifié pendant le transit.

DKIM utilise la cryptographie asymétrique : une paire de clés est générée, la clé privée reste côté serveur expéditeur (qui l'utilise pour signer), la clé publique est publiée dans le DNS de votre domaine (pour que n'importe quel destinataire puisse vérifier la signature).

DKIM est la seconde brique du trio d'authentification email, aux côtés de SPF et DMARC. Chacun répond à un angle différent : SPF liste les serveurs autorisés, DKIM signe les messages, DMARC dit quoi faire si SPF ou DKIM échoue.

DKIM a deux vertus par rapport à SPF : il garantit l'intégrité du message (pas seulement son origine), et il survit aux redirections. C'est pourquoi DMARC préfère généralement DKIM quand les deux sont disponibles.

02 — MécaniqueComment DKIM fonctionne

Côté expéditeur — signature

Au moment d'envoyer un email, le serveur sortant :

1. Sélectionne les en-têtes à signer (typiquement From, To, Subject, Date, Message-ID).
2. Calcule un hash du corps du message.
3. Calcule une signature cryptographique de l'ensemble (en-têtes sélectionnés + hash du corps) à l'aide de la clé privée DKIM.
4. Ajoute un en-tête DKIM-Signature: à l'email, qui contient la signature et des métadonnées (sélecteur, domaine, algorithme).

Côté destinataire — vérification

1. Le serveur destinataire lit l'en-tête DKIM-Signature: et en extrait le domaine signataire et le sélecteur.
2. Il interroge le DNS à l'adresse {selecteur}._domainkey.{domaine} pour récupérer la clé publique.
3. Il recalcule le hash du corps de l'email tel qu'il l'a reçu.
4. Il vérifie la signature à l'aide de la clé publique. Si tout correspond, DKIM passe. Sinon, DKIM échoue.

Ce que ça prouve

Une signature DKIM valide prouve deux choses :

• L'email a été signé par quelqu'un qui contrôle le domaine déclaré (parce qu'il faut la clé privée pour produire la signature, et seul le propriétaire du domaine peut publier la clé publique correspondante).
• Les parties signées (en-têtes choisis + corps) n'ont pas été modifiées depuis la signature.

03 — SélecteursLe concept de sélecteur DKIM

Le sélecteur est un identifiant textuel qui permet de publier plusieurs clés DKIM sur un même domaine. Chaque service d'envoi a typiquement son propre sélecteur.

Exemple d'enregistrement DNS DKIM :

selector1._domainkey.votredomaine.fr TXT "v=DKIM1; k=rsa; p=MIIBIj..."

Décomposition :

• selector1 — le sélecteur choisi. Format libre, typiquement s1, google, mailjet, k1, etc.
• _domainkey — sous-domaine imposé par la norme.
• votredomaine.fr — votre domaine.
• v=DKIM1 — version.
• k=rsa — algorithme (aujourd'hui toujours RSA, Ed25519 émerge).
• p=MIIBIj... — la clé publique en base64.

Cas typique d'une entreprise utilisant à la fois Google Workspace pour la messagerie et Mailjet pour les newsletters :

• google._domainkey.votredomaine.fr — clé pour Google Workspace
• mte1._domainkey.votredomaine.fr — clé pour Mailjet
• mte2._domainkey.votredomaine.fr — autre clé Mailjet

Chaque email est signé avec le sélecteur correspondant au service d'envoi. Le serveur destinataire lit le sélecteur dans l'en-tête DKIM-Signature pour savoir quelle clé publique interroger.

04 — ComparaisonDKIM face à SPF

Les deux protocoles font un travail proche mais pas identique. Comprendre leurs forces respectives aide à ne plus les opposer et à les utiliser ensemble.

DKIM survit aux redirections, SPF non

Quand un email est redirigé (liste de diffusion, forward automatique), l'IP finale change — donc SPF échoue. Mais la signature DKIM, elle, reste valide tant que le contenu signé n'a pas été modifié. DKIM est donc le choix privilégié dans les écosystèmes avec redirections fréquentes.

DKIM garantit l'intégrité, SPF non

SPF ne dit rien sur le contenu. Un serveur légitime peut être compromis et envoyer des messages modifiés qui passent SPF. DKIM garantit que le contenu signé est bien celui d'origine.

SPF est plus simple à déployer

Publier un enregistrement TXT avec les IPs autorisées est rapide. DKIM exige de configurer chaque service d'envoi pour qu'il signe avec la bonne clé — parfois techniquement complexe.

SPF impose une limite, DKIM non

Les 10 lookups DNS sont une contrainte forte de SPF. DKIM n'a pas d'équivalent, on peut publier autant de sélecteurs que nécessaire.

Conclusion pratique

SPF et DKIM ne se remplacent pas, ils se complètent. DMARC exige l'un ou l'autre (avec alignement), mais la solidité vient d'avoir les deux. Activer seulement SPF est insuffisant en 2026.

05 — Cycle des clésGénération et rotation

Génération

Dans la plupart des cas, la génération est faite automatiquement par le service d'envoi :

• Google Workspace — activation dans la console admin, qui génère la paire et fournit l'enregistrement DNS à publier.
• Microsoft 365 — deux sélecteurs (selector1 et selector2) à activer dans Exchange Admin Center après avoir publié les CNAME DNS demandés.
• Services d'envoi (Mailjet, SendGrid, Mailchimp, etc.) — chaque outil fournit ses propres valeurs DNS à ajouter.

Pour une génération manuelle, OpenSSL suffit :

• Générer la clé privée en RSA 2048 : openssl genrsa -out dkim.key 2048
• Extraire la clé publique en base64 à publier dans le DNS : openssl rsa -in dkim.key -pubout -outform DER | base64

Rotation

Bonnes pratiques pour la rotation (tous les 6 à 12 mois) :

1. Générer une nouvelle paire de clés avec un nouveau sélecteur (ex. s2 si on utilisait s1).
2. Publier la nouvelle clé publique dans le DNS.
3. Configurer le serveur d'envoi pour signer avec la nouvelle clé.
4. Attendre quelques jours pour que les emails en transit signés avec l'ancienne clé soient tous traités.
5. Retirer l'ancienne clé du DNS.

Les services cloud modernes gèrent cette rotation automatiquement — c'est l'un des arguments en leur faveur.

06 — PiègesLes erreurs fréquentes

• Clé 1024 bits — considérée comme trop faible en 2026. Toujours utiliser 2048 bits minimum. Certains anciens services imposent encore du 1024 : c'est un critère pour en changer.
• Clé privée exposée — sauvegardes, logs, dépôts Git oubliés. Si la clé privée fuite, rotation immédiate avec invalidation de l'ancienne clé.
• Sélecteur inactif laissé dans le DNS — un ancien service d'envoi dont on a gardé le sélecteur peut encore être exploité si les clés privées ont fuité côté prestataire. Nettoyer les sélecteurs obsolètes.
• Signature sur trop peu d'en-têtes — certains outils ne signent que From par défaut. Signer au minimum From, To, Subject, Date, Message-ID, MIME-Version.
• DKIM non aligné pour DMARC — le domaine signataire doit correspondre au domaine du champ From pour que DMARC considère DKIM comme aligné. Signer depuis un domaine tiers (mailjet.com) ne suffit pas, il faut configurer la signature au nom de votredomaine.fr.
• Oublier les sélecteurs secondaires — Microsoft 365 utilise deux sélecteurs en rotation. Ne publier qu'un seul casse la signature la moitié du temps.
• Enregistrement DNS tronqué — les clés DKIM dépassent parfois 255 caractères, limite d'une chaîne TXT classique. Il faut alors la scinder en plusieurs chaînes concaténées ("partie1" "partie2"). La plupart des panneaux DNS modernes gèrent cela automatiquement, mais pas tous.

07 — DéploiementComment mettre en place DKIM

08 — FAQQuestions fréquentes

DKIM est-il obligatoire ?

De facto oui, pour tout expéditeur sérieux. Gmail et Yahoo l'exigent depuis février 2024 pour les émetteurs de plus de 5 000 messages/jour. Microsoft a suivi en 2025. Sans DKIM, votre délivrabilité se dégrade rapidement et DMARC ne peut pas fonctionner correctement.

Peut-on avoir DKIM sans SPF ?

Techniquement oui, mais c'est déconseillé. DMARC fonctionne tant que SPF ou DKIM passe avec alignement. Si DKIM est le seul actif, un échec ponctuel (clé mal configurée, service qui a perdu la signature) bloque tout. SPF sert de filet de sécurité.

Qu'est-ce que ARC ?

ARC (Authenticated Received Chain) est un protocole complémentaire à DKIM, utilisé par les serveurs intermédiaires (listes de diffusion, proxies de sécurité email) pour préserver la chaîne d'authentification quand ils modifient le message. Sans ARC, une liste de diffusion qui ajoute un footer casse la signature DKIM et fait échouer DMARC pour l'émetteur.

Qu'est-ce que Ed25519 DKIM ?

Ed25519 est un algorithme cryptographique plus moderne que RSA, avec des clés plus petites (32 octets) pour une sécurité équivalente. Il est supporté par la RFC 8463 depuis 2018, mais son adoption reste faible : beaucoup de serveurs destinataires n'en savent rien et échouent. En 2026, rester sur RSA 2048 reste la recommandation pragmatique.

Pourquoi mes emails échouent-ils à DKIM sur des listes de diffusion ?

Parce que la liste modifie typiquement le sujet ([Liste] Mon message) ou ajoute un footer, ce qui invalide la signature DKIM originale. Solutions : ARC côté liste, désactiver les modifications sur la liste, ou s'appuyer sur la configuration DMARC du domaine expéditeur.