DKIM (DomainKeys Identified Mail)

Comment fonctionne DKIM

DKIM repose sur la cryptographie asymétrique — le même principe qui sécurise les connexions HTTPS. Un couple de clés est généré : une clé privée, stockée sur le serveur de messagerie, et une clé publique, publiée dans le DNS du domaine. Les deux sont liées mathématiquement, mais il est impossible de déduire la clé privée à partir de la clé publique.

Le processus se déroule en trois temps.

1. Signature par le serveur expéditeur

Quand votre serveur de messagerie envoie un email, il prend un ensemble d’en-têtes (From, To, Subject, Date…) et le corps du message, puis il calcule un hash — une empreinte numérique unique. Ce hash est ensuite chiffré avec la clé privée du domaine. Le résultat est injecté dans un en-tête spécial ajouté au message : DKIM-Signature.

Concrètement, le serveur applique l’algorithme RSA-SHA256 (le plus courant) pour produire une signature binaire encodée en Base64. Cette signature est unique pour chaque email : si un seul caractère du message change, le hash change, et la signature ne correspond plus.

2. Vérification par le serveur destinataire

Le serveur qui reçoit l’email lit l’en-tête DKIM-Signature. Il y trouve deux informations clés : le domaine signataire (d=) et le sélecteur (s=). Il combine les deux pour interroger le DNS : sélecteur._domainkey.domaine.fr. Le DNS renvoie la clé publique.

Le serveur destinataire recalcule le hash du message reçu, puis déchiffre la signature avec la clé publique. Si le hash recalculé correspond au hash signé, le résultat est dkim=pass. Le message est authentique et intact.

3. Résultat : intégrité et origine confirmées

Un résultat dkim=pass prouve deux choses :

• Intégrité : le contenu de l’email n’a pas été modifié entre l’envoi et la réception.
• Origine : le message a bien été signé par un serveur qui possède la clé privée du domaine.

C’est une distinction importante par rapport à SPF. SPF vérifie que le serveur expéditeur est autorisé à envoyer pour un domaine (vérification de l’adresse IP). DKIM vérifie que le message n’a pas été altéré et qu’il a bien été signé par le domaine (vérification du contenu). Les deux sont complémentaires : SPF protège l’autorisation d’envoi, DKIM protège l’intégrité du message.

Anatomie d’une signature DKIM

Chaque email signé par DKIM contient un en-tête DKIM-Signature qui ressemble à ceci :

DKIM-Signature: v=1; a=rsa-sha256; d=exemple.fr; s=selector1;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk2yFUvo...

Chaque paramètre a un rôle précis :

Paramètre	Valeur	Signification
v	1	Version du protocole DKIM
a	rsa-sha256	Algorithme de signature (RSA avec hachage SHA-256)
d	exemple.fr	Domaine signataire — le domaine qui revendique l’email
s	selector1	Sélecteur DNS — identifie quelle clé publique utiliser
h	from:to:subject:date:message-id	Liste des en-têtes inclus dans le calcul de la signature
bh	2jUSOH9N...	Hash du corps du message (body hash)
b	AuUoFEfD...	Signature cryptographique elle-même

Le concept de sélecteur

Le sélecteur est un mécanisme qui permet à un domaine de gérer plusieurs clés DKIM en parallèle. Chaque service d’envoi peut avoir son propre sélecteur :

• selector1._domainkey.exemple.fr — Microsoft 365
• google._domainkey.exemple.fr — Google Workspace
• k1._domainkey.exemple.fr — Mailchimp
• mte1._domainkey.exemple.fr — Brevo (ex-Sendinblue)

Quand le serveur destinataire reçoit un email avec s=selector1; d=exemple.fr, il interroge le DNS à l’adresse selector1._domainkey.exemple.fr pour récupérer la clé publique correspondante. Ce mécanisme permet de faire tourner des clés sans interruption de service : vous publiez la nouvelle clé sous un nouveau sélecteur, vous configurez le serveur pour signer avec le nouveau sélecteur, puis vous supprimez l’ancien enregistrement DNS.

Configurer DKIM étape par étape

La procédure varie selon votre hébergeur email. Voici les configurations les plus courantes en France.

Microsoft 365

1. Connectez-vous au Centre d’administration Microsoft 365 (admin.microsoft.com)
2. Allez dans Paramètres > Domaines > sélectionnez votre domaine
3. Cliquez sur Enregistrements DNS puis sur DKIM
4. Microsoft génère deux enregistrements CNAME à publier :
   • selector1._domainkey.exemple.fr → selector1-exemple-fr._domainkey.exemple.onmicrosoft.com
   • selector2._domainkey.exemple.fr → selector2-exemple-fr._domainkey.exemple.onmicrosoft.com
5. Ajoutez ces deux CNAME dans la zone DNS de votre domaine
6. Revenez dans le Centre d’administration et activez la signature DKIM

Microsoft utilise deux sélecteurs pour faciliter la rotation de clés. Le sélecteur actif signe les emails ; le second est prêt à prendre le relais. Microsoft gère la rotation automatiquement.

Google Workspace

1. Connectez-vous à la Console d’administration Google (admin.google.com)
2. Allez dans Applications > Google Workspace > Gmail > Authentifier les emails
3. Sélectionnez votre domaine et cliquez sur Générer un nouvel enregistrement
4. Choisissez la longueur de clé (2048 bits recommandé) et le préfixe de sélecteur (par défaut : google)
5. Google affiche un enregistrement TXT à ajouter dans votre DNS :
   • Nom : google._domainkey.exemple.fr
   • Valeur : v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (clé publique)
6. Publiez l’enregistrement TXT, attendez la propagation DNS (quelques minutes à 48 heures)
7. Revenez dans la Console d’administration et cliquez sur Commencer l’authentification

OVH (MX Plan, Email Pro, Exchange)

OVH simplifie la procédure pour ses offres email intégrées :

1. Connectez-vous à l’espace client OVH (ovh.com/manager)
2. Allez dans Emails > sélectionnez votre domaine > DKIM
3. Pour les offres MX Plan récentes, Email Pro et Exchange : OVH génère automatiquement les clés DKIM
4. Activez DKIM dans les paramètres — OVH publie automatiquement les enregistrements CNAME ou TXT dans votre zone DNS (si elle est gérée chez OVH)
5. Si votre DNS est géré ailleurs (Cloudflare, Gandi, etc.), OVH affiche les enregistrements à ajouter manuellement

Attention : les offres MX Plan anciennes (avant 2020) ne supportent pas toujours DKIM. Vérifiez dans votre espace client si l’option est disponible.

Configuration générique (serveur dédié ou VPS)

Si vous gérez votre propre serveur de messagerie (Postfix, Exim, etc.) :

1. Générez une paire de clés avec OpenSSL :

   openssl genrsa -out dkim-private.pem 2048
   openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

2. Configurez votre serveur pour signer les emails sortants avec la clé privée (via OpenDKIM, rspamd ou Amavis)
3. Publiez la clé publique dans votre DNS sous forme d’enregistrement TXT :
   • Nom : selecteur._domainkey.exemple.fr
   • Valeur : v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (contenu du fichier public, sans les lignes BEGIN/END)
4. Testez en envoyant un email à une adresse Gmail et en vérifiant les en-têtes

Clé 1024 bits vs 2048 bits

Le choix de la longueur de clé DKIM est un arbitrage entre compatibilité et sécurité. Voici la situation actuelle.

1024 bits : encore fonctionnel, mais en sursis

Les clés RSA de 1024 bits étaient le standard lors de la publication du RFC 6376 en 2011. Elles sont encore acceptées par la quasi-totalité des serveurs email. Mais la puissance de calcul nécessaire pour casser une clé 1024 bits a considérablement baissé. En 2023, des chercheurs ont montré qu’une clé RSA de 829 bits pouvait être factorisée avec du matériel accessible. Les clés de 1024 bits sont dans la zone grise : pas encore cassées en pratique, mais la marge de sécurité diminue chaque année.

2048 bits : le standard actuel

Google exige 2048 bits minimum depuis 2016. Microsoft 365 génère des clés de 2048 bits par défaut. L’ANSSI recommande 2048 bits dans ses guides de sécurité email. Si votre hébergeur le permet, il n’y a aucune raison de rester en 1024 bits.

Le problème DNS : la limite des 255 caractères

Un enregistrement TXT DNS est limité à 255 caractères par chaîne. Une clé RSA de 2048 bits, encodée en Base64, fait environ 400 caractères. Elle ne tient pas dans une seule chaîne TXT.

La solution : découper la clé en plusieurs chaînes dans le même enregistrement TXT. Le format est le suivant :

v=DKIM1; k=rsa; p="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "suite-de-la-cle-publique..."

La majorité des fournisseurs DNS gèrent ce découpage correctement. Certains anciens panneaux de gestion DNS posent problème — c’est la seule raison technique valable pour utiliser encore une clé de 1024 bits.

Rotation de clés : une pratique négligée

La rotation de clés DKIM consiste à remplacer régulièrement la paire de clés (privée + publique). L’objectif : limiter l’impact d’une éventuelle compromission de la clé privée.

Le rythme recommandé est de tous les 6 à 12 mois. La procédure utilise le mécanisme de sélecteur :

1. Générez une nouvelle paire de clés
2. Publiez la nouvelle clé publique sous un nouveau sélecteur (ex. : s202604)
3. Configurez le serveur pour signer avec le nouveau sélecteur
4. Vérifiez que les emails signés avec le nouveau sélecteur passent dkim=pass
5. Supprimez l’ancien enregistrement DNS après quelques jours (le temps que les emails en transit soient délivrés)

Microsoft 365 gère la rotation automatiquement via ses deux sélecteurs (selector1, selector2). Google Workspace ne le fait pas — la rotation doit être déclenchée manuellement par l’administrateur.

DKIM et le transfert d’email

Le transfert d’email est le talon d’Achille de DKIM. Quand un email est redirigé (forwarding) par un serveur intermédiaire, plusieurs choses peuvent se produire :

• Le serveur de redirection ajoute un pied de page (“Ce message a été transféré par…”)
• Il modifie l’encodage du message (conversion MIME, ajout d’en-têtes)
• Il réécrit certains en-têtes (ajout de Received, modification de Message-ID)

Or, la signature DKIM a été calculée sur le message original. Toute modification, même mineure, invalide la signature. Le serveur final reçoit un email dont la signature DKIM échoue — le résultat est dkim=fail.

Les listes de diffusion : même problème

Les listes de diffusion (mailing lists) modifient systématiquement les emails qu’elles redistribuent. Elles ajoutent des préfixes au sujet ([Liste]), des pieds de page avec un lien de désinscription, et parfois réécrivent l’adresse From. Toutes ces modifications cassent la signature DKIM.

C’est un problème connu depuis la publication du RFC 6376 en 2011 et l’une des raisons pour lesquelles DKIM seul ne suffit pas comme mécanisme d’authentification.

ARC : la solution au transfert

Le protocole ARC (Authenticated Received Chain) a été créé en 2019 (RFC 8617) pour répondre à ce problème précis. Quand un serveur intermédiaire reçoit un email avec dkim=pass et spf=pass, ARC lui permet de sceller ces résultats avant de modifier et retransmettre le message. Le serveur final peut ainsi consulter la chaîne ARC pour vérifier que l’email était authentique avant le transfert, même si la signature DKIM originale est désormais invalide.

Gmail, Microsoft 365 et Yahoo prennent en compte les résultats ARC dans leurs décisions de filtrage. Si votre domaine reçoit beaucoup d’emails transférés, l’adoption d’ARC par vos serveurs intermédiaires améliore la délivrabilité.

DKIM seul ne suffit pas

DKIM prouve l’intégrité d’un message et confirme qu’il a été signé par un domaine donné. Mais il y a un angle mort.

Le problème de l’alignement

Rien n’empêche un attaquant de configurer DKIM sur son propre domaine. L’attaquant enregistre domaine-malveillant.fr, configure une clé DKIM, et envoie un email de phishing signé avec d=domaine-malveillant.fr. L’email passe dkim=pass — la signature est valide, le message n’a pas été altéré. Mais le champ From visible peut afficher direction@votre-entreprise.fr.

DKIM ne vérifie pas que le domaine de la signature (d=) correspond au domaine que l’utilisateur voit dans le champ From. C’est exactement le même type de faille que SPF : les vérifications techniques portent sur des éléments invisibles pour l’utilisateur, pas sur l’adresse From affichée.

DMARC comble cette faille

DMARC (Domain-based Message Authentication, Reporting and Conformance) vérifie l’alignement entre le domaine From visible et le domaine authentifié par SPF ou DKIM (RFC 7489). Concrètement :

• DMARC vérifie que le domaine d= de la signature DKIM correspond au domaine de l’adresse From (alignement DKIM)
• Ou que le domaine du Return-Path vérifié par SPF correspond au domaine From (alignement SPF)
• Il suffit que l’un des deux soit aligné pour que DMARC passe

Si un attaquant signe avec d=domaine-malveillant.fr mais affiche From: direction@votre-entreprise.fr, l’alignement DMARC échoue. Si votre domaine votre-entreprise.fr publie un DMARC p=reject, le serveur destinataire rejette l’email.

Le trio SPF + DKIM + DMARC

La protection complète contre le spoofing repose sur la combinaison des trois protocoles :

Protocole	Ce qu’il vérifie	Ce qu’il ne vérifie pas
SPF	Le serveur expéditeur est autorisé à envoyer pour le domaine	Le contenu n’a pas été modifié
DKIM	Le message n’a pas été altéré et a été signé par un domaine	Le domaine de signature correspond au From visible
DMARC	Le domaine authentifié (SPF ou DKIM) correspond au domaine From visible	Rien de plus — il relie SPF et DKIM au From

Les trois ensemble, avec DMARC en mode p=reject, bloquent le spoofing de votre domaine exact. L’étape suivante est BIMI, qui affiche votre logo dans les clients email compatibles — mais BIMI exige un DMARC p=quarantine ou p=reject comme prérequis.

Pour un guide complet sur la mise en place des trois protocoles, consultez notre guide configurer SPF, DKIM, DMARC.

Erreurs courantes de configuration DKIM

1. Mauvais type d’enregistrement DNS

Certains hébergeurs demandent un enregistrement CNAME (Microsoft 365), d’autres un enregistrement TXT (Google Workspace, configuration manuelle). Publier un TXT là où un CNAME est attendu — ou l’inverse — fait échouer la vérification DKIM silencieusement. Vérifiez la documentation de votre fournisseur avant de créer l’enregistrement.

2. Propagation DNS incomplète

Après publication d’un enregistrement DNS, la propagation peut prendre de quelques minutes à 48 heures selon les serveurs DNS intermédiaires. Tester DKIM immédiatement après avoir ajouté l’enregistrement donne souvent un faux négatif. Attendez au moins 2 heures avant de tester, et utilisez un outil comme dig pour vérifier que l’enregistrement est visible :

dig TXT selector1._domainkey.exemple.fr +short

3. Sélecteur mal configuré

Le sélecteur configuré sur le serveur de messagerie doit correspondre exactement au sélecteur publié dans le DNS. Une erreur courante : configurer selector1 sur le serveur mais publier la clé sous selecteur1._domainkey.exemple.fr (avec le “e” en trop). La moindre différence fait échouer la résolution DNS.

4. Clé trop courte

Une clé de 512 bits sera rejetée par la plupart des serveurs modernes. Une clé de 1024 bits fonctionne encore mais produit des avertissements dans les rapports DMARC de Google. Privilégiez systématiquement 2048 bits.

5. Pas de rotation de clés

Une clé DKIM qui n’a jamais changé depuis 3 ans est un risque. Si la clé privée est compromise (fuite de serveur, ancien employé, migration mal gérée), l’attaquant peut signer des emails au nom de votre domaine. La rotation tous les 6 à 12 mois limite cette fenêtre d’exposition.

6. Services tiers non configurés

Votre domaine envoie des emails depuis plusieurs sources : votre serveur principal, mais aussi Mailchimp, HubSpot, Brevo, votre CRM, votre outil de support… Chaque service doit avoir sa propre configuration DKIM avec un sélecteur dédié. Les emails envoyés par un service tiers non configuré partent soit sans signature DKIM, soit avec la signature du domaine du service (ex. : d=mailchimp.com) — dans les deux cas, l’alignement DMARC échoue pour votre domaine.

7. En-têtes signés insuffisants

La signature DKIM doit inclure les en-têtes les plus importants : From, To, Subject, Date, Message-ID. Si seul le From est signé, un attaquant qui intercepte l’email peut modifier le sujet ou le corps sans invalider la signature. La configuration par défaut de la plupart des serveurs signe un ensemble suffisant d’en-têtes, mais vérifiez le paramètre h= dans vos signatures sortantes.

Comment nophi.sh vérifie votre DKIM

Notre test de sécurité email analyse automatiquement la configuration DKIM de votre domaine. L’outil interroge les sélecteurs DKIM les plus courants (10 sélecteurs testés, incluant ceux de Microsoft 365, Google Workspace, OVH, Brevo et Mailchimp) et vérifie :

• La présence d’au moins un enregistrement DKIM publié dans votre DNS
• La longueur de la clé (1024, 2048 bits ou plus)
• L’algorithme utilisé (RSA-SHA256 recommandé, RSA-SHA1 déprécié)
• La validité syntaxique de l’enregistrement

Le test vérifie aussi vos enregistrements SPF et DMARC en une seule analyse, avec un score global de sécurité email de votre domaine et des recommandations concrètes pour corriger les problèmes détectés.

Testez votre domaine maintenant avec notre vérificateur de sécurité email. C’est gratuit, sans inscription, et prend moins de 30 secondes.