DKIM permet d’associer un message à un domaine signataire. Pour une newsletter, l’enjeu pratique est de savoir quel service signe, sous quel domaine et comment vérifier que cette signature fonctionne. Vous pouvez piloter ces questions sans manipuler vous-même de clés privées.

Le sujet devient particulièrement utile lorsqu’un domaine est partagé par la newsletter, la facturation et des formulaires. Une configuration claire permet de rattacher chaque signature à un usage connu.

Une signature technique, distincte du nom affiché

Le cadre DKIM utilise une clé privée pour signer et une clé publique publiée dans le DNS pour vérifier. Il n’authentifie pas la véracité de chaque phrase ni la personne physique supposée écrire. La RFC 5863 explicite cette distinction entre identité signataire et confiance dans le contenu.

Dans votre documentation, séparez donc le nom affiché, l’adresse visible et le domaine DKIM. Cela évite qu’une validation de signature soit résumée par « l’email est fiable » sans préciser ce qui a réellement été contrôlé.

Cette précision aide aussi l’équipe éditoriale. Elle peut travailler sur la reconnaissance du nom et la promesse du message pendant que le prestataire vérifie la signature : les deux interventions se complètent.

À quoi sert un sélecteur DKIM ?

Le sélecteur, indiqué par s= dans la signature, distingue une clé au sein du domaine d=. Cette combinaison guide la recherche DNS. La RFC 6376 décrit aussi l’utilisation de sélecteurs pour faire coexister des clés pendant une transition.

Considérez le sélecteur comme une référence à documenter. Vous n’avez pas besoin de lui donner une signification marketing ni d’y inscrire le nom d’un lecteur.

Dans un inventaire, notez le service, le domaine signataire, le sélecteur, la personne responsable et l’état de la configuration. Si votre fournisseur gère cette partie, demandez-lui où retrouver ces informations et comment il annonce une modification.

Quelles questions poser sur les clés ?

Pour les signatures RSA, la RFC 8301 impose au moins 1 024 bits et recommande au moins 2 048 bits ; elle écarte l’ancien algorithme rsa-sha1. Ces tailles ne doivent pas être transposées à tous les algorithmes cryptographiques.

Le responsable d’une petite structure peut traduire cela en demande simple : « Quel algorithme et quelle taille utilisez-vous, et qui assure leur maintenance ? » Une réponse précise peut rester courte.

Demandez également comment les accès sont gérés. Une clé privée ne doit pas être copiée dans le dossier partagé de l’équipe éditoriale pour prouver que le travail a été fait. Le compte rendu de configuration et les résultats de test suffisent à votre suivi.

Préparer une rotation avec le prestataire

Une rotation planifiée consiste à changer de clé selon une procédure maîtrisée. La coexistence temporaire des anciennes et nouvelles références permet d’accompagner les messages encore en transit ; la spécification DKIM décrit ce principe.

Pour votre organisation, préparez d’abord la liste des usages concernés. Demandez ensuite le déroulé : publication, activation de la nouvelle signature, tests, surveillance et retrait de l’ancienne référence. La durée dépend du fonctionnement du service ; ne la déduisez pas d’une recette universelle.

Conservez les éléments permettant de vérifier le changement. Votre objectif est qu’une autre personne puisse comprendre ce qui a été modifié et identifier le bon contact si un flux présente une anomalie.

Exemple fictif : le changement de plateforme

Imaginons une créatrice qui déplace sa newsletter vers une nouvelle plateforme, tout en gardant son outil de vente en ligne. Le prestataire lui transmet des références DNS à ajouter.

Avant de retirer les anciens réglages, elle distingue la lettre et les confirmations d’achat. Elle fait envoyer un test de chaque type, puis demande la validation des signatures et des domaines utilisés.

Le retrait de l’ancienne configuration est programmé lorsque le périmètre est clair. La créatrice évite ainsi de considérer toute entrée ancienne comme inutile. Cet exemple est fictif ; il montre une façon de coordonner la migration et les usages qui restent actifs.

Contrôler le parcours réel

Testez avec le modèle et le service qui seront utilisés en production. Conservez l’original du message reçu et faites examiner le résultat DKIM par le prestataire. Un aperçu visuel valide la mise en page ; il ne remplace pas ce contrôle technique.

Si le message passe par un intermédiaire, signalez-le dans la demande. Fournissez autant que possible le message obtenu en envoi direct et celui reçu après le parcours concerné. Vous donnez ainsi au diagnostic une base de comparaison.

Gardez un compte rendu séparé par flux. Une réponse générale « domaine configuré » laisse souvent trop de questions ouvertes pour savoir quel parcours a réellement été vérifié.

Distinguer maintenance et incident

Une rotation prévue et une suspicion de compromission ne se gèrent pas avec la même urgence. Si un incident est identifié, le prestataire doit préciser les mesures immédiates et leurs effets possibles sur les messages en cours.

Pour la maintenance ordinaire, demandez comment les changements sont annoncés et comment les services retirés sont désactivés. Ce suivi peut être intégré à vos procédures d’arrivée et de départ d’outils.

Évitez d’inventer une fréquence obligatoire de rotation pour toutes les newsletters. Ce qui doit être explicite dans votre organisation, c’est le responsable de la décision, sa justification et la vérification après intervention.

Garder un contrôle compréhensible

Votre dossier DKIM peut tenir dans un tableau et quelques exemples de messages. Il doit permettre de répondre à trois questions : quels services signent en notre nom, comment le sait-on et qui intervient si cela change ?

Ce niveau de maîtrise est utile à une petite équipe. Vous confiez la cryptographie au bon interlocuteur tout en gardant la compréhension de votre identité d’envoi et de ses dépendances.