DKIM en pratique : sélecteurs, clés et services

Module 4: Délivrabilité : SPF, DKIM et DMARC en pratique · Temps de lecture : 12 minutes

Objectif d'apprentissage : Après cette leçon, vous saurez décortiquer un en-tête DKIM-Signature, configurer DKIM avec votre propre domaine pour chaque service d'envoi, vérifier qu'un sélecteur fonctionne, et expliquer comment remplacer vos clés en toute sécurité.

Notions clés : DKIM-Signature, d= (domaine signataire), s= (sélecteur), h= (en-têtes signés), bh= et b=, canonicalisation (c=), <selector>._domainkey.<domein>, TXT avec p= ou CNAME vers le service, longueur de clé 2048 bits (RFC 8301), segments de 255 caractères, ed25519 (RFC 8463), rotation de clés, p= vide (révoquée), DKIM et redirection

Pourquoi DKIM est le plus important des trois

SPF indique quels serveurs sont autorisés à envoyer du courrier, mais il échoue en cas de redirection et se base sur le Return-Path, qui chez beaucoup de services ne vous appartient pas. DKIM appose une signature dans le message lui-même. Cette signature survit à une redirection (tant que le message n'est pas modifié) et est liée à un domaine que vous choisissez. C'est pourquoi DKIM est en pratique souvent le seul mécanisme qui fait réussir DMARC pour les newsletters, les factures issues d'un logiciel de comptabilité et le courrier redirigé.

Les bases (comment la clé est inscrite dans le DNS, ce qu'est un sélecteur) figurent dans le cours DNS, leçon 4.4. Ici, nous allons plus loin : que contient exactement une signature, et comment configurer DKIM pour chaque service ?

Décortiquer une signature

Ouvrez les en-têtes d'un message que vous avez reçu (leçon 1.5). En haut, si le message est signé, vous trouverez quelque chose comme :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
	t=1762588800; h=from:to:subject:date:message-id:mime-version:content-type;
	bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
	b=Gm7yW3q...longue suite de caractères...Qx9A==

Le destinataire récupère la clé publique à l'adresse <s>._domainkey.<d>, ici donc x._domainkey.example.com, et vérifie que b= correspond aux en-têtes de h= et à l'empreinte bh=. Si une seule lettre a été modifiée en chemin dans le corps du message ou dans un en-tête signé, la vérification échoue.

Dans Authentication-Results, vous voyez le résultat, par exemple dkim=pass header.d=example.com header.s=x. Un message peut avoir plusieurs signatures, par exemple une de votre domaine et une du service lui-même. Pour DMARC, seule compte une signature dont d= correspond à votre domaine De.

À chaque service son propre sélecteur

Un domaine peut avoir de nombreuses clés DKIM en même temps, chacune sous son propre sélecteur. C'est exactement le but recherché : chaque service qui envoie en votre nom signe avec sa propre clé.

TXT ou CNAME ?

• Avec un enregistrement TXT, vous placez vous-même la clé publique dans votre DNS. Si le service souhaite une nouvelle clé, c'est à vous de modifier l'enregistrement.
• Avec un enregistrement CNAME, vous redirigez le sélecteur vers un nom chez le service, par exemple k2._domainkey.example.com CNAME dkim2.mailer.example. Le service gère alors lui-même la clé et peut la remplacer sans que vous ayez quoi que ce soit à faire. C'est pourquoi les grands services optent pour le CNAME, et en utilisent souvent deux : cela leur permet d'alterner entre une clé active et une nouvelle clé.

Attention : un CNAME ne peut pas coexister avec un autre enregistrement sur le même nom. S'il y a déjà un TXT sur selector1._domainkey, retirez-le.

Le plus important : activer DKIM chez le service

Chez de nombreux services, DKIM avec votre propre domaine n'est pas activé par défaut. Ils signent alors avec leur propre domaine (d=mailer.example). Le message est bien signé, mais n'est pas aligné avec votre adresse De. Pour DMARC, cela ne compte pas. Dans l'administration du service, cela s'appelle souvent « vérifier le domaine », « vérification de domaine », « authentification » ou « domaine d'expéditeur personnalisé ». Ce n'est qu'une fois que vous avez posé les enregistrements ET activé l'option dans le service qu'il signe avec d=example.com.

Clés : longueur, segments et algorithme

• Longueur. Le RFC 8301 indique : au moins 1024 bits, et les expéditeurs devraient utiliser au moins 2048 bits. Utilisez 2048. Une clé de 512 bits est considérée comme invalide par les destinataires.
• Segments de 255 caractères. Un enregistrement TXT se compose de chaînes de caractères de 255 caractères maximum. Une clé de 2048 bits fait environ 400 caractères et ne tient pas dans une seule chaîne. L'enregistrement se compose alors de deux chaînes ou plus mises bout à bout ("v=DKIM1; k=rsa; p=MIIBIj..." "...IDAQAB"), que le destinataire recolle. La plupart des panneaux le font automatiquement. En cas d'erreur, vous obtenez une clé tronquée et toute signature échoue. Copiez donc toujours une clé dans son intégralité, sans espaces ou guillemets superflus au milieu.
• ed25519 (RFC 8463) est un algorithme plus moderne avec des clés courtes. Tous les destinataires ne le vérifient pas encore. Qui l'utilise signe donc avec deux signatures : une RSA et une ed25519.

Remplacer une clé

Il est bon de remplacer une clé de temps en temps, et certainement si vous pensez que la clé privée a fuité (par exemple après le piratage du serveur ou le départ d'un administrateur). Procédez ainsi :

1. Créez une nouvelle clé sous un nouveau sélecteur, par exemple s2026, et placez la clé publique dans le DNS.
2. Attendez que l'enregistrement soit visible partout (le TTL, voir le cours DNS leçon 6.1).
3. Faites signer le serveur avec le nouveau sélecteur.
4. Laissez l'ancienne clé encore quelques jours : le courrier déjà en chemin ou vérifié à nouveau y fait encore référence.
5. Révoquez l'ancienne clé en vidant p= (v=DKIM1; p=), ou retirez l'enregistrement.

Chez les services utilisant des enregistrements CNAME, le service s'en charge lui-même.

Ce qui fait échouer DKIM

• Le message est modifié en chemin : une liste de diffusion qui ajoute [nomdeliste] dans l'objet ou ajoute un pied de page, un antivirus qui colle une ligne sous le message, un serveur de redirection qui convertit la mise en forme.
• Clé incorrecte ou tronquée dans le DNS.
• Le sélecteur n'existe pas : une faute de frappe dans le nom, ou selector1._domainkey.example.com.example.com (le nom de domaine en double, parce que le panneau l'ajoute déjà lui-même derrière).
• Clé révoquée (p= vide) alors que le serveur signe encore avec ce sélecteur.

Vérifier que cela fonctionne

1. Envoyez un message depuis le service vers une adresse chez Gmail ou Outlook.com.
2. Ouvrez les en-têtes et cherchez le DKIM-Signature : notez d= et s=.
3. Regardez dans Authentication-Results s'il y a dkim=pass, et si header.d= correspond à votre domaine.
4. Recherchez le sélecteur : dig TXT s._domainkey.example.com (ou avec un outil en ligne). Il doit y avoir un p= avec une longue clé, ou un CNAME menant à un tel enregistrement.

En pratique : à quoi cela ressemble dans un panneau

Avec un forfait d'hébergement WebOké, DKIM est activé par défaut, avec le sélecteur x : l'enregistrement s'appelle x._domainkey.<votredomaine>. Dans DirectAdmin, vous le voyez dans Administration DNS ; si votre DNS est chez un autre prestataire, copiez-y cet enregistrement. Dans Mon WebOké, la carte Définir l'e-mail indique quelle valeur doit figurer et si elle est trouvée. Chez d'autres prestataires, le sélecteur porte un autre nom (default, mail, dkim), mais vous le trouvez de la même manière : dans le panneau ou dans le s= d'un message signé.

Résumé

• DKIM est le contrôle qui survit à une redirection et que vous liez, par service, à votre propre domaine ; pour DMARC, seule compte une signature avec votre domaine dans d=.
• Dans le DKIM-Signature, vous trouvez d= (domaine) et s= (sélecteur) ; la clé se trouve à <s>._domainkey.<d>.
• Chaque service reçoit son propre sélecteur ; les enregistrements CNAME permettent au service de remplacer lui-même les clés. Activez aussi réellement DKIM avec votre propre domaine dans le service.
• Utilisez 2048 bits ; attention aux clés tronquées lors de la copie.
• Remplacez une clé avec un nouveau sélecteur et ne révoquez l'ancienne qu'après coup.

Quiz

Exercice

Exercice Z4.3: Vérifier un sélecteur DKIM. Envoyez un message depuis votre propre domaine (ou depuis un service qui envoie en votre nom) vers une adresse personnelle chez un autre prestataire. Ouvrez les en-têtes et renseignez les valeurs de d= et s= issues du DKIM-Signature, ainsi que ce qui figure dans Authentication-Results au niveau de dkim=. Le programme recherche le sélecteur en direct, suit un éventuel CNAME, vérifie la clé (présence, non-vide, longueur) et indique si d= est aligné avec le domaine que vous indiquez comme expéditeur.

Pour en savoir plus

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres prestataires, le fonctionnement est comparable.

• Cours DNS gratuit 4.4: DKIM : la signature sous votre mail
• Guide DirectAdmin 5.8: Activer et vérifier DKIM
• Configurer DKIM lorsque le DNS est géré sur un serveur externe
• Guide WebOké 6.7: La carte Configurer la messagerie (MX, SPF, DKIM, DMARC)
• RFC 6376 (DKIM), RFC 8301 (longueur de clé et algorithmes), RFC 8463 (ed25519)