Comment une équipe produit peut-elle configurer DKIM en toute sécurité ?

Recensez chaque chemin sortant réel avant de générer une clé

Commencez par un inventaire, et non par un enregistrement DNS. Répertoriez chaque système capable d’émettre des e-mails à partir des domaines From visibles de l’organisation : workers applicatifs, fournisseurs transactionnels, plateformes marketing, outils de support, systèmes d’identité, logiciels de ticketing, relais et chemins d’urgence. Pour chacun, consignez son propriétaire, les catégories de messages, l’expéditeur d’enveloppe, le domaine From visible, le domaine DKIM d= actuel, le sélecteur, le composant de signature et si un autre relais modifie ensuite le message. Une clé DKIM publiée pour un fournisseur ne sert à rien pour un autre chemin qui n’utilise jamais sa clé privée. De même, un tableau de bord générique de fournisseur montrant un domaine vérifié ne prouve pas que chaque tenant, région, flux, modèle ou solution de repli est signé. Utilisez des échantillons contrôlés provenant de chaque chemin et conservez leurs en-têtes d’origine. Décidez quels chemins sont autorisés avant d’activer la signature ; DKIM authentifie la responsabilité d’un domaine pour une signature, et non le consentement du destinataire ni la véracité du contenu du message.

Choisissez un domaine de signature compatible avec l’alignement DMARC

La balise DKIM d= identifie le domaine de signature. Choisissez un domaine que l’organisation contrôle et peut gérer pendant toute la durée de vie du flux d’e-mails. Lorsque DMARC s’appuiera sur DKIM, le domaine d= doit être aligné sur le domaine du champ From visible défini par la RFC 5322, selon la règle d’alignement relaxed ou strict applicable. Un domaine de signature appartenant au fournisseur peut produire un résultat DKIM valide tout en restant non aligné sur le domaine From de l’organisation. Décidez si c’est le domaine apex ou un sous-domaine dédié qui doit signer chaque flux, en tenant compte de la propriété, de la séparation des réputations, de la délégation DNS et de l’isolation des incidents. N’inventez pas de domaines supplémentaires simplement pour contourner un problème de réputation ou de politique. Consignez la relation avec le domaine organisationnel et le mode DMARC visé. Testez l’alignement à partir des en-têtes reçus finaux ; ne le déduisez jamais d’une simple requête sur le sélecteur, car le message pourrait utiliser une autre valeur d=.

Attribuez les sélecteurs comme des identités opérationnelles

Un sélecteur permet à un domaine de publier plusieurs clés et de les modifier sans remplacer un enregistrement global unique. Créez une politique de sélecteurs déterministe qui identifie un fournisseur ou signataire et une génération de rotation sans divulguer de secrets. Par exemple, product-a-2026q3 peut être plus clair que default, mais gardez des noms conformes aux conventions DNS et aux limites de vos outils. Ne réutilisez jamais une même clé privée entre des fournisseurs, environnements ou tenants sans rapport simplement pour réduire les enregistrements DNS. Tenez un registre comprenant le sélecteur, le domaine d=, l’objectif, le service de signature, le propriétaire, la date de création, l’algorithme, l’empreinte de la clé publique, l’état de déploiement, l’échéance de rotation et les preuves de retrait. Vérifiez le nom exact du sélecteur avant publication : la requête est `selector._domainkey.signing-domain`. Un enregistrement créé par erreur au domaine From visible, au domaine return path ou dans la mauvaise zone DNS ne vérifiera pas la signature prévue. Évitez de supprimer un ancien sélecteur avant l’expiration des e-mails différés et des nouvelles tentatives signés avec celui-ci.

Générez et protégez la clé privée

Générez la paire de clés dans un service de gestion de clés ou un système de signature étroitement contrôlé lorsque le fournisseur le permet. La clé privée ne doit jamais se retrouver dans le DNS public, le contrôle de version, le code côté navigateur, les sorties de CI, les outils d’analyse, les logs ordinaires, les tickets, les documents, les prompts ou les discussions partagées. N’accordez l’accès à la signature qu’au composant de messagerie qui a besoin de la clé, séparez la production des environnements inférieurs et journalisez les accès administratifs. La RFC 8301 met à jour les exigences cryptographiques de DKIM : les signataires doivent utiliser des clés RSA d’au moins 1024 bits et devraient utiliser au moins 2048 bits ; elle mentionne aussi les contraintes DNS opérationnelles liées aux clés plus longues. Utilisez les capacités et recommandations actuelles du signataire choisi et de la population de destinataires plutôt que de recopier un exemple obsolète. Si vous envisagez Ed25519, la RFC 8463 définit son usage avec DKIM, mais l’interopérabilité doit être testée et une stratégie de signature compatible conservée là où c’est nécessaire. La rotation doit être possible sans exporter la clé privée.

Publiez la clé publique avec précision

Publiez un enregistrement TXT au nom de propriétaire exact `selector._domainkey.signing-domain`. L’enregistrement de clé DKIM contient des balises telles que v=DKIM1, un type de clé si nécessaire et p= contenant le contenu de la clé publique sans délimiteurs de clé privée. Respectez le format exact de l’enregistrement du signataire et le comportement de citation de votre fournisseur DNS. Avant d’enregistrer, vérifiez si l’interface DNS ajoute automatiquement la zone, scinde les longues chaînes ou échappe des caractères. Interrogez directement les serveurs de noms faisant autorité après publication, puis des résolveurs récursifs indépendants, et reconstituez la valeur TXT complète. Plusieurs chaînes de caractères dans un même enregistrement TXT sont concaténées par les clients DNS, tandis que plusieurs enregistrements de ressources concurrents peuvent créer une ambiguïté. Conservez la réponse précédente et le TTL pour un retour arrière. Ne réduisez pas la sécurité en publiant une clé plus large ou en laissant un indicateur de test en production simplement pour faire taire un vérificateur. Un enregistrement visible prouve la publication DNS, pas que l’expéditeur utilise la clé privée correspondante.

Configurez le signataire final et les champs signés

Configurez le composant qui remet le message final au transport sortant, ou assurez-vous qu’aucun composant ultérieur ne modifie le contenu signé. Une signature DKIM couvre un hash du corps et les champs d’en-tête listés dans h=. La RFC 6376 exige que le champ d’en-tête From soit signé pour qu’une signature soit valide. Incluez les en-têtes critiques pour l’identité adaptés au produit, comprenez comment les en-têtes répétés sont sélectionnés, et évitez de signer des champs qu’un système en aval indispensable doit réécrire, sauf si cette transformation est maîtrisée. Choisissez la canonicalisation délibérément. La canonicalisation relaxed tolère certains changements définis d’espaces et de mise en forme des en-têtes, mais pas des modifications arbitraires du corps. La canonicalisation simple est plus fragile. L’ajout d’un pied de page, la réécriture de liens, les changements de frontière MIME, la conversion de l’encodage de transfert, les balises d’objet et la normalisation des fins de ligne après la signature peuvent faire échouer la vérification. Signez le message entièrement rendu après les transformations approuvées, et empêchez les utilisateurs non fiables de choisir d=, s=, les listes d’en-têtes ou les clés.

Vérifiez de bout en bout les messages d’origine reçus

Envoyez des messages contrôlés par chaque chemin réel, configuré comme en production, vers des boîtes aux lettres de test externes gérées par l’équipe. Conservez le message d’origine brut, et non un corps copié ou une pièce jointe de ticket resérialisée. Inspectez les valeurs d= et s= de DKIM-Signature, la liste des en-têtes signés, le hash du corps, l’algorithme, la canonicalisation, l’horodatage et l’éventuelle expiration. Interrogez la clé publique depuis un réseau indépendant et exécutez un vérificateur conforme aux standards sur les octets d’origine. Comparez l’en-tête Authentication-Results du destinataire de confiance avec votre vérificateur, en respectant les périmètres de confiance de la RFC 8601. Testez le texte brut, le multipart alternative, les pièces jointes prévues, les objets Unicode, les en-têtes longs, les modèles, les transformations de suivi, les nouvelles tentatives et les chemins de relais. Les tests négatifs doivent inclure un en-tête signé volontairement modifié dans une fixture, un sélecteur absent, un sélecteur expiré ou retiré, et un chemin qui contourne la signature. Ne modifiez jamais les e-mails de vrais clients pour créer un test.

Évaluez DKIM, DMARC et la livraison comme des résultats distincts

Une réussite DKIM signifie que le vérificateur a trouvé une signature valide pour le domaine de signature identifié sur les champs et le corps signés. Elle n’authentifie pas chaque en-tête non signé, ne confirme pas un auteur humain, ne prouve pas le consentement du destinataire, n’établit pas la conformité légale et ne garantit ni l’acceptation ni le placement en boîte de réception. DMARC évalue séparément si un domaine DKIM ou SPF ayant réussi est aligné sur le domaine From visible et applique la politique du propriétaire du domaine. Pour les tests contrôlés, consignez au minimum le résultat et la raison DKIM, le domaine d=, le sélecteur, le domaine From visible, le résultat d’alignement, le résultat SPF, le résultat DMARC, le destinataire et l’horodatage. Excluez les adresses complètes de destinataires et le contenu des métriques courantes. L’acceptation par le fournisseur SMTP, l’acceptation par le serveur du destinataire, le bounce ultérieur, le placement dans un dossier de boîte aux lettres et l’engagement sont des états ultérieurs. Si DKIM réussit mais que l’e-mail est rejeté ou filtré, examinez plutôt l’alignement DMARC, SPF, la réputation de l’IP et du domaine, le taux de plaintes, la politique des messages, le débit et les consignes du destinataire que de faire pivoter les clés à répétition.

Faites la rotation sans créer de trou de vérification

Utilisez des sélecteurs qui se chevauchent. Générez d’abord une nouvelle clé protégée et publiez son enregistrement public sous un nouveau sélecteur. Vérifiez le DNS faisant autorité et récursif, configurez le signataire pour qu’il utilise le nouveau sélecteur, et envoyez des tests contrôlés par chaque chemin. Surveillez la proportion de signatures utilisant l’ancien et le nouveau sélecteur, ainsi que leurs résultats de vérification. Laissez l’ancienne clé publique disponible pendant la durée maximale de mise en file d’attente des messages, la fenêtre de nouvelles tentatives et la durée du cache DNS, plus une marge de sécurité explicite. Arrêtez ensuite toute signature avec l’ancien sélecteur, confirmez qu’aucune configuration active n’y fait référence, et retirez son enregistrement conformément à votre politique. Une révocation d’urgence après l’exposition d’une clé privée peut exiger un retrait plus rapide, une pause du trafic, la rotation des identifiants du fournisseur et une communication d’incident ; documentez ce compromis à l’avance. N’écrasez pas un sélecteur sur place lors d’une rotation de routine, car les anciennes clés publiques en cache peuvent faire échouer la vérification des messages signés avec la nouvelle clé privée.

Diagnostiquez les échecs en partant de la signature

En cas de signature absente, déterminez si le message a emprunté un flux non signé, un domaine From non autorisé, un relais de repli ou un chemin de modèle particulier. En cas de clé introuvable, vérifiez la requête exacte sur s= et d=, la délégation de zone, la réponse faisant autorité, les erreurs DNSSEC ou de résolveur, et la propagation. En cas de non-concordance du hash du corps, comparez le MIME brut avant signature et à la réception pour trouver les transformations postérieures à la signature. En cas de non-concordance de signature, vérifiez que la clé publique publiée correspond à la clé privée active et examinez la canonicalisation et les en-têtes signés. En cas de pass DKIM avec échec DMARC, évaluez l’alignement sur le domaine From visible. Distinguez les erreurs temporaires de requête DNS des défauts de configuration persistants, et ne recourez à des nouvelles tentatives de transport limitées que lorsque la réponse SMTP est transitoire. Mettez en pause le flux concerné en cas de signature interdomaines, de clés inconnues, d’échec de vérification généralisé ou de suspicion d’exposition de clé. Conservez des preuves minimisées pour la confidentialité et ne changez qu’une variable à chaque nouveau test contrôlé.

Utilisez la documentation DKIM de votre système d’envoi

Configurez DKIM dans les systèmes d’envoi réels et l’autorité DNS, validez les messages reçus d’origine et appuyez-vous sur les normes IETF actuelles et la documentation spécifique au fournisseur.

Questions fréquentes

Sources

• RFC 6376 : DomainKeys Identified Mail Signatures — RFC Editor
• RFC 8301 : Cryptographic Algorithm and Key Usage Update to DKIM — RFC Editor
• RFC 8463 : A New Cryptographic Signature Method for DKIM — RFC Editor
• RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 8601 : Message Header Field for Indicating Message Authentication Status — RFC Editor
• RFC 5321 : Simple Mail Transfer Protocol — RFC Editor