DKIM : comment fonctionne la signature et comment la tester

Le DKIM (DomainKeys Identified Mail) est une signature numérique que le domaine expéditeur ajoute à chaque email. Elle permet au serveur destinataire de vérifier que le message vient bien de ce domaine et qu’il n’a pas été modifié en route, ce qui limite l’usurpation d’identité (spoofing) et pèse sur la délivrabilité. L’IETF l’a standardisé en 2007 (RFC 4871), puis révisé en 2011 (RFC 6376).

Que vérifie exactement un serveur quand il écrit dkim=pass dans l’en-tête d’un message ? Il constate qu’une signature jointe par le domaine expéditeur correspond à une clé publique publiée dans le DNS de ce domaine. Le corps du message n’a pas bougé pendant le transit. Rien d’autre. Un tableau de bord d’emailing qui affiche « DKIM OK » ne dit donc rien de la liste visée ni de la réputation de l’IP.

Depuis le 1er février 2024, Google exige l’authentification SPF, DKIM et DMARC des expéditeurs qui envoient plus de 5 000 messages par jour vers Gmail. Ce guide lit une signature champ par champ, montre l’enregistrement à publier, puis détaille le test et les causes d’échec.

L’en-tête DKIM-Signature, champ par champ

Ouvrez l’original d’un email reçu : l’en-tête ressemble à ceci (valeurs d’illustration, signature raccourcie).

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exemple.fr; s=s1; t=1760000000;
 h=from:to:subject:date:message-id;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=Zm9ybWF0IGQnaWxsdXN0cmF0aW9u...

Chaque balise répond à une définition de la RFC 6376, publiée par l’IETF en septembre 2011.

Deux balises se confondent souvent. bh contient l’empreinte du corps, b la signature elle-même, calculée sur les en-têtes de h et sur l’en-tête DKIM-Signature (avec b vide). Une empreinte SHA-256 pèse 32 octets, soit 44 caractères en base64 dans bh. Un corps modifié d’un seul octet casse bh ; un en-tête signé modifié casse b. L’algorithme rsa-sha1 est proscrit depuis la RFC 8301 (janvier 2018) : une signature moderne affiche rsa-sha256. La balise optionnelle l, qui limite le signé à un nombre d’octets du corps, laisse la porte ouverte à l’ajout de contenu après la partie couverte ; la RFC 6376 en décrit le mauvais usage en section 8.2.

De la signature à la vérification : qui fait quoi

Le vocabulaire courant (« chiffrer le hash avec la clé privée ») brouille les rôles. Dans les faits, la séquence suit quatre temps.

1. Le serveur d’envoi (MTA) canonise le corps, en calcule l’empreinte SHA-256 et la place dans bh.
2. Il calcule l’empreinte des en-têtes listés dans h, plus celle de l’en-tête DKIM-Signature lui-même, puis signe le résultat avec sa clé privée. Cette signature devient b. La clé privée ne quitte jamais le serveur d’envoi.
3. Le serveur destinataire lit d et s, interroge le DNS sur s._domainkey.d et récupère la clé publique. L’expéditeur n’intervient plus à ce stade.
4. Le destinataire recalcule l’empreinte du corps et la compare à bh, puis vérifie b avec la clé publique. Les deux contrôles concordent : dkim=pass.

Sélecteur et enregistrement TXT : où la clé est publiée

Le sélecteur, valeur de la balise s, construit le nom DNS que le destinataire va interroger : s._domainkey.d. Pour s=s1 et d=exemple.fr, la requête porte sur s1._domainkey.exemple.fr, où l’on attend un enregistrement TXT.

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

La balise v annonce la version, k le type de clé, p la clé publique en base64. Un p vide signale une clé révoquée. Le début de la valeur trahit la taille : MIIBIjANBgkq… correspond à une clé RSA de 2048 bits, MIGfMA0GCSqG… à une clé de 1024 bits.

La RFC 8301 impose aux signataires des clés RSA d’au moins 1024 bits et recommande 2048 bits. Une clé de 1024 bits tient en 216 caractères environ. Une clé de 2048 bits pèse 392 caractères en base64 : elle dépasse les 255 caractères d’une chaîne DNS ; l’enregistrement doit donc être découpé en plusieurs chaînes entre guillemets, ce que certaines interfaces DNS font seules et d’autres non. Chaque outil d’envoi (Google Workspace, un CRM, un ESP) reçoit son propre sélecteur sous le même domaine, ce qui explique qu’une zone en contienne plusieurs.

Dernier piège : selon l’interface, le champ « nom d’hôte » attend s1._domainkey seul ou le nom complet. Saisir le nom complet là où le domaine s’ajoute automatiquement produit s1._domainkey.exemple.fr.exemple.fr, introuvable pour le destinataire. Cet enregistrement vit dans la même zone que les autres enregistrements DNS de l’expéditeur (SPF, MX, DMARC) : une seule interface à modifier, un seul propriétaire de la zone à identifier.

Configurer DKIM chez Google Workspace, Microsoft 365 ou un ESP

Chez Google Workspace, le chemin passe par la console d’administration : Applications > Google Workspace > Gmail > Authentifier les e-mails. Le bouton « Générer un nouvel enregistrement » crée la paire de clés ; on copie la valeur TXT dans la zone DNS puis on lance l’authentification. Après l’activation de Gmail, la clé n’apparaît dans la console qu’au bout de 24 à 72 heures, selon la documentation d’aide de Google Workspace.

Microsoft 365 (Office 365 dans les anciennes documentations) procède autrement. Le portail Microsoft Defender (security.microsoft.com), rubrique « Email authentication settings », fournit deux sélecteurs nommés selector1 et selector2, à publier en CNAME vers des enregistrements hébergés par Microsoft, sur le modèle selector1-exemple-fr._domainkey.locataire.onmicrosoft.com. Un seul des deux sélecteurs signe à la fois, l’autre attend la prochaine rotation : la bascule se fait sans coupure.

Avec un ESP, la plateforme fournit les enregistrements TXT ou CNAME à copier. Tant que la zone DNS ne les contient pas, l’ESP signe avec son propre domaine : le test affiche dkim=pass. Le domaine d ne correspond pourtant pas au From, si bien que la signature ne compte pas pour DMARC. Même effet avec une passerelle sortante qui ajoute un pied de page : le corps change après la signature, un cas que la documentation de Google Workspace signale expressément.

Tester DKIM : lire Authentication-Results

Envoyez un message de test vers une boîte Gmail, puis ouvrez le menu à trois points du message et choisissez Afficher l’original. Gmail y affiche « DKIM : PASS » avec le domaine puis détaille le verdict dans l’en-tête Authentication-Results.

Authentication-Results: mx.google.com;
 dkim=pass header.i=@exemple.fr header.s=s1 header.b=Zm9ybWF0;
 spf=pass smtp.mailfrom=exemple.fr;
 dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=exemple.fr

Dans la ligne dkim, header.s donne le sélecteur utilisé, header.i l’identité signataire, header.b les premiers caractères de la signature. Ce format est celui de la RFC 8601. Les verdicts possibles : pass, fail (signature invalide), none (aucune signature), neutral, temperror et permerror (erreur DNS passagère ou définitive).

Pour isoler un problème de DNS avant tout envoi, la commande dig +short TXT s1._domainkey.exemple.fr renvoie la valeur publiée ; un outil de test DKIM en ligne (dkim lookup, dkim checker) fait la même requête avec la valeur de s de l’en-tête.

Pourquoi une signature DKIM échoue

Un dkim=fail tient presque toujours à l’un de ces cas.

• Le corps a changé après la signature : pied de page ajouté par un relais. bh ne correspond plus.
• Le sélecteur est introuvable : faute de frappe ou nom d’hôte doublé du domaine.
• La clé publique est tronquée : TXT de 2048 bits non découpé.
• La clé privée a été régénérée côté fournisseur sans mise à jour du DNS.
• Le message transite par une liste de diffusion ou un transfert qui réécrit l’objet ou ajoute un pied de page : la signature d’origine ne couvre plus le contenu reçu.
• La signature passe mais le domaine d diffère du domaine du From : DMARC la rejette pour défaut d’alignement.

Alignement DMARC et exigences de Gmail et Yahoo

Yahoo applique ses exigences depuis février 2024 : son Sender Hub demande que le domaine du From soit aligné avec le domaine SPF ou avec le domaine DKIM (bonnes pratiques Yahoo). En mode relaxed, valeur par défaut, un d=news.exemple.fr s’aligne avec un From en exemple.fr ; le mode strict (adkim=s) exige l’identité exacte, selon la RFC 7489 de 2015. Un message envoyé par un ESP avec d=mailer.esp-exemple.com et un From en @exemple.fr échoue donc l’alignement DKIM ; si le Return-Path appartient aussi à l’ESP, le SPF échoue lui aussi. Sous une politique DMARC en p=reject, un message dont ni le SPF ni le DKIM ne sont alignés est rejeté.

Les seuils diffèrent selon le volume. Pour tout expéditeur vers Gmail, Google demande SPF ou DKIM depuis le 1er février 2024 ; au-delà de 5 000 messages par jour, SPF et DKIM sont tous deux requis. Google demande aussi un DMARC publié (p=none suffit), des enregistrements DNS directs et inverses valides ainsi qu’une connexion TLS ; le format des messages suit la RFC 5322. Côté réputation, la page vise un taux de spam sous 0,10 % dans Postmaster Tools et interdit d’atteindre 0,30 %. Yahoo réclame SPF et DKIM ensemble, un DMARC au moins en p=none et le même plafond de 0,3 %. Le SPF seul ne passe donc plus pour un gros volume.

Rotation des clés

Remplacer une clé sans coupure demande deux sélecteurs, par exemple s1 puis s2. On publie la nouvelle clé sous s2 pendant que s1 signe encore, on bascule la signature sur s2, puis on laisse s1 en DNS le temps que les messages en file d’attente soient vérifiés. Le supprimer trop tôt provoque des dkim=fail sur des envois légitimes, que l’on prend à tort pour une panne DNS.

Ce que le DKIM ne vérifie pas

Un spammeur peut signer ses envois avec son propre domaine et obtenir dkim=pass : la signature prouve l’origine du message, elle ne juge ni le contenu ni la qualité de la liste. Un domaine parfaitement signé qui écrit à des adresses mortes accumule des hard bounces. Sa réputation d’expéditeur en pâtit quand même.

Avant la prochaine campagne, faites passer un échantillon de la liste par une vérification d’adresses : le résultat dit combien d’adresses invalides la base contient avant qu’elles ne remontent dans Postmaster Tools.