DKIM : le guide complet de la signature DKIM

L'en-tête DKIM-Signature décodé

Toute la mécanique DKIM tient dans un en-tête ajouté au message. En voici un, tel qu'on le trouve dans le code source d'un email :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=exemple.fr; s=s2026; t=1753344000;
  h=from:to:subject:date:mime-version;
  bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

Les balises (tags) qui le composent sont normalisées. Les sept principales :

Balise	Nom	Rôle
v=	Version	Toujours 1 : la version du standard DKIM utilisée.
a=	Algorithme	L'algorithme de signature et de hachage, rsa-sha256 dans l'immense majorité des cas (ed25519-sha256 pour les clés modernes).
d=	Domaine	Le domaine signataire, celui qui revendique le message. C'est lui que DMARC comparera au From: visible.
s=	Sélecteur	Le nom de la clé utilisée, qui indique au destinataire où chercher la clé publique dans le DNS.
h=	En-têtes signés	La liste des en-têtes couverts par la signature ; tout en-tête absent de cette liste peut changer sans la casser.
bh=	Hash du corps	L'empreinte du corps du message au moment de la signature.
b=	Signature	La signature cryptographique elle-même, encodée en base64.

D'autres balises apparaissent selon les configurations : c= (le mode de canonicalisation évoqué plus haut), t= (horodatage de la signature), x= (date d'expiration au-delà de laquelle la signature ne doit plus être acceptée), i= (identité de l'agent signataire, parfois un sous-domaine ou une adresse), ou l= (longueur de corps signée — une option risquée, car elle autorise l'ajout de contenu après la partie signée, et que les bonnes pratiques déconseillent).

Deux balises méritent une attention particulière. d= d'abord : c'est la revendication d'identité de la signature, et le pivot de tout l'édifice DMARC. h= ensuite : la liste des en-têtes signés détermine ce que la signature protège réellement. Signer From est obligatoire ; signer aussi Subject, Date, To et Reply-To est fortement recommandé pour empêcher leur falsification a posteriori.

Les sélecteurs : plusieurs clés pour un même domaine

Un domaine n'a presque jamais une seule clé DKIM. Le courrier professionnel part typiquement de plusieurs endroits — la messagerie principale, un outil marketing, un CRM, un service de facturation — et chacun signe avec sa propre paire de clés. Le sélecteur est le mécanisme qui rend cette coexistence possible : c'est un nom arbitraire, choisi par le signataire, qui identifie chaque clé publiée.

La découverte de la clé publique suit une convention fixe. Le destinataire lit s= et d= dans la signature, puis interroge le DNS à l'adresse :

<sélecteur>._domainkey.<domaine>

Pour s=s2026 et d=exemple.fr, la requête TXT porte donc sur s2026._domainkey.exemple.fr. Chaque fournisseur d'envoi utilise ses conventions de nommage : google pour Google Workspace, selector1/selector2 pour Microsoft 365, des noms propres à chaque plateforme ailleurs. C'est d'ailleurs un réflexe d'audit utile : énumérer les sélecteurs publiés sous _domainkey révèle la liste des services autorisés à signer pour le domaine — y compris ceux que l'on avait oubliés.

Cette architecture multi-clés apporte deux bénéfices opérationnels majeurs. L'isolation : si un prestataire est compromis ou abandonné, on révoque son sélecteur sans toucher aux autres flux, qui continuent de signer normalement. La souplesse : on peut introduire une nouvelle clé à côté de l'ancienne, ce qui est le fondement de la rotation sans coupure décrite plus bas. Le rôle exact du sélecteur, ses conventions et ses pièges sont détaillés dans notre guide dédié au sélecteur.

Générer et publier une clé DKIM

En pratique, la paire de clés naît de deux façons. Soit la plateforme d'envoi la génère pour vous — c'est le cas des suites bureautiques et de la plupart des routeurs d'emailing, qui fournissent directement l'enregistrement DNS à publier. Soit vous la générez vous-même (serveur de messagerie auto-hébergé, exigence de maîtrise des clés), avec un outil standard comme OpenSSL. Les commandes exactes, étape par étape, sont dans notre guide de génération pas à pas.

La clé publique se publie ensuite dans le DNS, et deux modèles coexistent :

Le TXT direct. Vous créez l'enregistrement TXT vous-même sous <sélecteur>._domainkey.<domaine>, avec la clé en clair :

s2026._domainkey.exemple.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Vous gardez la maîtrise complète de la clé — c'est vous qui la faites tourner, vous qui la révoquez. Point de vigilance : une clé RSA 2048 bits dépasse la limite des 255 caractères par chaîne DNS ; l'enregistrement est alors découpé en plusieurs chaînes entre guillemets que les résolveurs recollent automatiquement. Ce découpage est normal, mais certaines interfaces DNS le gèrent mal.

Le CNAME délégué. Vous publiez un simple alias qui pointe vers un enregistrement hébergé chez le fournisseur d'envoi :

s1._domainkey.exemple.fr.  IN CNAME  s1.domainkey.fournisseur-envoi.example.

Le fournisseur héberge la clé réelle et peut la faire tourner sans que vous touchiez à votre zone DNS. C'est le modèle dominant chez les plateformes d'emailing, et il a un vrai mérite opérationnel : la rotation devient leur problème, pas le vôtre. Sa contrepartie est une délégation de confiance — le fournisseur contrôle une identité cryptographique de votre domaine. Dans les deux modèles, la balise t=y (mode test) peut accompagner un déploiement initial, et la révocation s'effectue en vidant la valeur p= de l'enregistrement.

La rotation des clés : une hygiène, pas un événement

Une clé DKIM n'a pas vocation à être éternelle. Plus une clé privée vit longtemps, plus la probabilité qu'elle fuite augmente : sauvegarde égarée, serveur compromis, prestataire quitté en laissant la clé active, copie oubliée dans un dépôt de code. Or une clé privée DKIM volée permet de signer des messages parfaitement authentiques aux yeux des destinataires — avec l'alignement DMARC en bonus. La rotation périodique borne ce risque dans le temps : une clé volée hier ne vaut plus rien après la rotation.

Sur la fréquence, la référence couramment citée par l'industrie (notamment les recommandations M3AAWG) est une rotation au moins deux fois par an, soit tous les six mois environ. En pratique : tous les six mois pour les flux sensibles, une fois par an au grand minimum, et immédiatement en cas de soupçon de compromission ou de départ d'un prestataire.

Le point remarquable est que la rotation peut être totalement transparente, grâce aux sélecteurs. La procédure sans coupure tient en quatre étapes :

1. Générer une nouvelle paire de clés et publier la nouvelle clé publique sous un nouveau sélecteur (par exemple s2027), sans toucher à l'ancien.
2. Basculer la signature côté serveur d'envoi vers la nouvelle clé.
3. Attendre quelques jours : le courrier signé avec l'ancienne clé, encore en transit ou en file d'attente, doit finir d'être délivré et vérifié.
4. Révoquer l'ancien sélecteur (vider son p=), puis le supprimer.

À aucun moment un message ne circule sans clé publique vérifiable : les deux sélecteurs coexistent pendant la bascule. La procédure détaillée, avec les pièges à éviter et le cas des clés déléguées en CNAME, fait l'objet de notre guide de la rotation des clés. Dernier rappel qui relève de la même hygiène : la clé privée est un secret critique, à stocker comme tel (coffre-fort de secrets, accès restreint), jamais en clair dans un dépôt ou un ticket.

1024 ou 2048 bits : la taille de la clé

Pour les clés RSA, deux tailles se rencontrent sur le terrain. Le 1024 bits, longtemps la valeur par défaut, reste accepté par les vérificateurs mais n'offre plus de marge de sécurité sérieuse : la RFC 8301 l'a fixé comme minimum absolu, et la factorisation d'une clé de cette taille n'est plus hors de portée d'un adversaire très bien doté. Le 2048 bits est le standard actuel : marge cryptographique confortable, support universel côté destinataires, et la seule contrainte pratique — l'enregistrement DNS découpé en plusieurs chaînes — est un non-sujet chez les hébergeurs DNS corrects.

La règle est donc simple : toute nouvelle clé se génère en 2048 bits, et un domaine encore équipé en 1024 profite de sa prochaine rotation pour monter en gamme — c'est exactement le type de bascule que le mécanisme des sélecteurs rend indolore. L'histoire a d'ailleurs tranché : les clés courtes (512 et 768 bits) ont été publiquement factorisées il y a plus d'une décennie, et les grands fournisseurs pénalisent ou ignorent les signatures produites avec des clés faibles. L'argumentaire complet, chiffres à l'appui, est dans le comparatif 1024 vs 2048 bits.

Au-delà de RSA, la RFC 8463 a introduit les clés Ed25519 : beaucoup plus courtes à robustesse équivalente, elles tiennent sans découpage dans un enregistrement DNS. Leur support côté vérificateurs progresse mais reste partiel ; la pratique recommandée est de les publier en second sélecteur, en double signature à côté d'une clé RSA 2048, jamais en remplacement sec.

DKIM et DMARC : l'alignement du d=

Il faut le dire sans détour : DKIM seul ne protège pas contre l'usurpation d'identité. Une signature DKIM valide prouve que le message est intègre et signé par le domaine d= — mais rien, dans DKIM, n'exige que ce d= corresponde au domaine que le lecteur voit dans le champ From:. Un attaquant peut signer proprement avec son propre domaine et afficher le vôtre dans le From: : DKIM passera au vert.

C'est précisément le chaînon que DMARC ajoute : l'alignement. Pour qu'un message satisfasse DMARC via DKIM, il faut que la signature soit valide et que son domaine d= soit aligné avec le domaine du From:. En mode relaxed (le défaut), un domaine organisationnel commun suffit — newsletter.exemple.fr signé s'aligne avec un From: en exemple.fr ; en mode strict (adkim=s), l'égalité doit être exacte. C'est cette règle qui transforme une preuve d'intégrité en une véritable protection d'identité, et c'est pourquoi DKIM se déploie toujours dans la perspective de DMARC — le fonctionnement complet de la politique est décrit dans la page de référence DMARC.

L'alignement DKIM a une propriété décisive : il survit au transfert (forwarding). Quand un email est réacheminé — d'une boîte professionnelle vers une adresse personnelle, par exemple — c'est le serveur qui transfère qui le remet, et l'adresse IP d'origine ne correspond plus : le contrôle d'IP échoue, comme l'explique la page de référence SPF. La signature DKIM, elle, voyage dans le message : tant que le contenu signé n'est pas modifié, elle reste valide après un ou plusieurs sauts. Sur du courrier transféré, DKIM est souvent le seul mécanisme encore capable de produire un résultat aligné — raison pour laquelle une politique DMARC stricte sans DKIM solide est une politique fragile. La limite existe aussi : les listes de diffusion qui réécrivent le sujet ou ajoutent un pied de page cassent la signature, un cas que le standard ARC vise à rattraper. Un DKIM signé et aligné sur toutes les sources est, en pratique, la condition numéro un pour mener sereinement le passage de p=none à p=reject.

Vérifier une signature DKIM

Bonne nouvelle : il n'y a rien à recalculer soi-même. Chaque serveur destinataire vérifie les signatures et consigne son verdict dans un en-tête Authentication-Results, visible dans le code source de tout message reçu :

Authentication-Results: mx.example.net;
  dkim=pass header.d=exemple.fr;
  spf=pass ...; dmarc=pass ...

Deux informations comptent. dkim=pass : la signature est cryptographiquement valide. header.d= : le domaine signataire — c'est lui qu'il faut comparer au From: pour juger l'alignement. Un dkim=pass avec le header.d= d'un prestataire n'apporte rien à DMARC : signature valide, mais identité non alignée. La lecture détaillée de ces en-têtes, balise par balise, avec les causes d'échec typiques, est couverte dans notre guide de vérification d'une signature.

Ce contrôle à l'unité ne dit toutefois rien de l'ensemble des flux. La vue exhaustive vient des rapports agrégés DMARC, qui recensent, source par source, les résultats DKIM et leur alignement tels que les grands destinataires les ont réellement évalués — c'est l'objet de notre guide des rapports agrégés. Et pour un état des lieux immédiat de votre domaine — sélecteurs détectés, clés publiées, alignement, politique DMARC — notre analyseur DKIM et DMARC gratuit restitue le tout en quelques secondes, sans inscription.

FAQ

DKIM est-il obligatoire pour envoyer des emails ?

Formellement, non : un message sans signature DKIM peut être délivré. En pratique, si. Les exigences expéditeurs de Gmail et Yahoo imposent DKIM aux envois en volume, DMARC ne peut produire d'alignement robuste sans lui, et les destinataires accordent une confiance moindre au courrier non signé. Pour tout domaine qui envoie de l'email professionnel, DKIM est un prérequis de fait.

DKIM chiffre-t-il le contenu des messages ?

Non. DKIM signe, il ne chiffre pas : le message circule en clair de ce point de vue, et la signature ne fait que prouver son origine et son intégrité. La confidentialité du transport relève d'autres mécanismes (TLS entre serveurs, renforcé par MTA-STS), et le chiffrement de bout en bout d'autres outils encore (S/MIME, OpenPGP).

Que se passe-t-il quand une signature DKIM échoue ?

Rien d'automatique. Un dkim=fail isolé n'entraîne pas le rejet du message : c'est un signal, que le destinataire combine avec SPF, la réputation et surtout la politique DMARC du domaine. C'est DMARC qui décide — si ni DKIM ni SPF ne produisent de résultat aligné, la politique publiée (none, quarantine ou reject) s'applique.

Combien de sélecteurs un domaine peut-il publier ?

Autant que nécessaire : le standard ne fixe aucune limite. Un domaine actif publie couramment cinq à dix sélecteurs — un ou deux par service d'envoi, plus ceux qui coexistent temporairement pendant une rotation. La bonne pratique n'est pas de les limiter, mais de les inventorier : chaque sélecteur actif est une identité capable de signer pour le domaine, et un sélecteur oublié d'un prestataire quitté est une porte restée ouverte.

À quelle fréquence faut-il faire tourner la clé DKIM ?

La référence industrielle est une rotation semestrielle, une fois par an au grand minimum, et sans délai en cas de compromission supposée ou de départ d'un prestataire. Grâce au double sélecteur, l'opération se fait sans aucune interruption de flux. Les clés déléguées en CNAME sont tournées par le fournisseur lui-même — vérifiez que c'est bien le cas, la délégation n'étant pas une garantie.

Un message peut-il porter plusieurs signatures DKIM ?

Oui, et c'est courant : le standard autorise plusieurs en-têtes DKIM-Signature sur un même message. Un routeur d'emailing signe souvent avec son propre domaine et avec le vôtre ; une double signature RSA + Ed25519 est aussi une pratique de transition. Pour DMARC, une seule signature valide et alignée suffit — les autres ne gênent pas.