Qu'est-ce qu'un sélecteur DKIM et comment le gérer sur plusieurs fournisseurs de services de messagerie (ESP) ?

Qu'est-ce qu'un sélecteur DKIM ?

Un sélecteur DKIM est une courte chaîne de caractères incluse dans l'en-tête d'un e-mail signé DKIM qui indique au serveur de messagerie destinataire où trouver la clé publique correspondante dans le DNS. Il est défini dans la balise `s=` de l'en-tête DKIM-Signature.

Chaque signature DKIM comprend une valeur de sélecteur. Le sélecteur, associé au domaine signataire indiqué par la balise `d=`, forme un chemin de requête DNS qui pointe vers un enregistrement TXT spécifique contenant la clé publique utilisée pour vérifier la signature.

Voici à quoi ressemble le sélecteur dans l'en-tête d'un e-mail :

Signature DKIM : v=1 ; a=rsa-sha256 ; d=example.com ; s=selector1 ;
c=relaxed/relaxed ; q=dns/txt ; h=from:to:subject:date ;
bh=abc123…=; b=xyz789…=

Dans cet exemple, `selector1` est le sélecteur DKIM. Le serveur destinataire interrogera `selector1._domainkey.example.com` pour récupérer la clé publique.

Les organisations utilisent souvent plusieurs clés de signature en même temps, en fonction de leurs besoins en matière d'e-mails. Chaque clé dispose de son propre sélecteur, ce qui permet aux deux de coexister sous le même domaine sans conflit.

Les sélecteurs permettent également de procéder à la rotation des clés sans interruption de service. Vous pouvez publier une nouvelle clé sous un nouveau sélecteur tandis que l'ancien sélecteur reste actif, puis effectuer la bascule une fois la propagation terminée.

Comment fonctionnent les sélecteurs DKIM ?

Lorsqu'un serveur de messagerie destinataire reçoit un e-mail signé DKIM, il extrait le sélecteur (`s=`) et le domaine (`d=`) de l'en-tête du message, interroge le DNS à l'adresse `{selector}._domainkey.{domain}`, récupère la clé publique à partir de l'enregistrement TXT obtenu, puis utilise cette clé pour vérifier la signature cryptographique du message.

Voici la procédure étape par étape :

Étape 1 : Le serveur d'envoi signe l'e-mail

Avant que l'e-mail ne quitte le serveur de messagerie émetteur (ou ESP), celui-ci utilise sa clé privée pour générer une signature cryptographique sur certains champs d'en-tête et le corps du message. Cette signature, ainsi que la valeur du sélecteur et le domaine de signature, est ajoutée à l'e-mail sous la forme de l'en-tête `DKIM-Signature`.

Étape 2 : Le serveur destinataire extrait le sélecteur et le domaine

Lorsque l'e-mail arrive dans la boîte de réception, le serveur de réception analyse l'en-tête `DKIM-Signature` et en extrait deux valeurs :

1. Le sélecteur à partir de `s=` 
2. Le domaine à partir de `d=`.

Étape 3 : Le serveur destinataire interroge le DNS

The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record

Par exemple, si `s=google` et `d=example.com`, la requête DNS est : google._domainkey.example.com

Étape 4 : Le DNS renvoie la clé publique

L'enregistrement TXT situé à cette adresse DNS contient la clé publique et les paramètres associés :

v=DKIM1 ; k=rsa ; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…

Étape 5 : Le serveur destinataire vérifie la signature

Le serveur utilise la clé publique pour vérifier la signature cryptographique figurant dans l'en-tête de l'e-mail. 

1. Si la signature correspond, le test DKIM est réussi. 
2. Si la clé est manquante, l'enregistrement est incorrect.
3. Si la signature ne correspond pas, la validation DKIM échoue.

Le sélecteur relie l'en-tête de l'e-mail à l' enregistrement DNS car, sans cet enregistrement DNS, le serveur destinataire n'aurait aucun moyen de localiser la clé publique appropriée, en particulier lorsqu'un domaine publie plusieurs clés DKIM pour différents services.

Syntaxe et format du sélecteur DKIM 

Les sélecteurs DKIM doivent respecter les règles syntaxiques spécifiques définies dans RFC 6376.

Caractères autorisés :

• Caractères alphanumériques (a–z, A–Z, 0–9)
• Tirets (-)
• Points (.) pour les sélecteurs de type sous-domaine

Contraintes :

• Dans la résolution DNS, les sélecteurs ne sont pas sensibles à la casse, bien que l'utilisation des minuscules soit la norme.
• La RFC 6376 ne fixe pas de limite maximale de longueur, mais des contraintes pratiques liées au DNS s'appliquent. La plupart des implémentations limitent la longueur des sélecteurs à 63 caractères (la longueur maximale d'une étiquette DNS).
• Les sélecteurs ne peuvent pas commencer ni se terminer par un tiret.
• Les points dans les sélecteurs créent des hiérarchies de sous-domaines dans la requête DNS. Par exemple, `2024.jan._domainkey.example.com` est un chemin de requête valide si le sélecteur est `2024.jan`.

Le format de l'enregistrement DNS TXT situé sur le chemin d'accès du sélecteur contient les balises suivantes :

Remarque : Les clés RSA de 2048 bits génèrent des chaînes de clé publique qui dépassent la limite de 255 caractères imposée pour une seule chaîne TXT DNS. Le DNS gère cela à l'aide d'enregistrements TXT à chaînes multiples, dans lesquels la valeur est répartie sur plusieurs chaînes entre guillemets que le résolveur concatène conformément à la norme RFC 6376. Cependant, toutes les interfaces de gestion DNS ne gèrent pas cela efficacement, ce qui est une cause fréquente d'échecs DKIM

Comment trouver votre sélecteur DKIM 

Il existe quatre méthodes fiables pour identifier les sélecteurs DKIM utilisés pour un domaine donné. Chacune présente des avantages différents selon que vous contrôlez le domaine, que vous avez accès aux en-têtes des e-mails ou que vous effectuez un audit depuis l'extérieur.

Méthode 1 : Vérifier les en-têtes des e-mails

La méthode la plus directe consiste à examiner les en-têtes des e-mails. Ouvrez un message envoyé depuis le domaine en question et affichez l'intégralité des en-têtes.

• Dans Gmail : ouvrez le message → cliquez sur le menu à trois points → « Afficher l'original ».
• Dans Outlook : ouvrez le message → Fichier → Propriétés → « En-têtes Internet ».
• Dans Apple Mail : Affichage → Message → Tous les en-têtes.

Recherchez l'en-tête `DKIM-Signature` et repérez la balise `s=`. Cette valeur correspond au sélecteur.

Si l'e-mail est passé par plusieurs services de signature, vous pouvez voir plusieurs en-têtes `DKIM-Signature`, chacun avec un sélecteur différent.

Méthode 2 : Utiliser un outil de vérification DKIM

Si vous connaissez le nom du sélecteur, vous pouvez interroger directement l'enregistrement DKIM à l'adresse selector._domainkey.example.com. Recherche d'enregistrements DKIM de PowerDMARC, MXToolbox ou des commandes DNS en ligne de commandetelles que dig et nslookup peuvent renvoyerl'enregistrement TXT publié pour ce sélecteur.

Utilisation de dig:

bash

dig TXT selector1._domainkey.example.com +short

 

Utilisation de nslookup:

bash

nslookup -q=TXT selector1._domainkey.example.com

Cette méthode nécessite que vous connaissiez déjà le nom du sélecteur ou que vous essayiez les valeurs par défaut courantes.

La fonction de vérification DKIM de PowerDMARC peut également détecter automatiquement les sélecteurs pour de nombreux domaines, valider la syntaxe DKIM, identifier les enregistrements manquants ou mal formés, et aider à résoudre les problèmes courants de configuration DKIM. 

Méthode 3 : Consultez la console d'administration de votre ESP

La plupart des fournisseurs de messagerie affichent le sélecteur DKIM et la clé publique dans leurs paramètres d'authentification. Par exemple :

• Google Workspace : Console d'administration → Applications → Google Workspace → Gmail → Vérifier l'adresse e-mail
• Microsoft 365 : Portail Defender → Stratégies et règles → Stratégies de menaces → Authentification des e-mails → DKIM
• Mailchimp : Site web → Domaines → Authentification → Paramètres DKIM

Méthode 4 : Rapports agrégés DMARC

C'est le moyen le plus efficace pour identifier tous les sélecteurs qui signent activement des e-mails pour votre domaine, y compris ceux dont vous n'avez peut-être pas connaissance.

Rapports agrégés DMARC (rapports RUA) incluent les résultats de l'authentification DKIM pour chaque message reçu par les serveurs de messagerie déclarants. Chaque résultat comprend le sélecteur utilisé, le domaine de signature et le statut de réussite ou d'échec.

Si votre organisation utilise plusieurs fournisseurs de services de messagerie (ESP) ou si des services tiers envoient des e-mails en votre nom, les rapports DMARC mettront en évidence des sélecteurs que vous ne pourriez pas détecter en vous contentant d'inspecter les en-têtes. Cela s'avère particulièrement utile pour identifier les services de messagerie informels qui ont été autorisés à un moment donné et qui n'ont jamais été désactivés.

L'analyseur DMARC de PowerDMARC analyseur DMARC analyse automatiquement ces rapports agrégés et affiche tous les sélecteurs DKIM actifs par domaine dans un tableau de bord unique, éliminant ainsi la nécessité d'extraire et de recouper manuellement les données XML provenant de multiples sources de rapports.

Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.

5. Sélecteurs DKIM par défaut d'ESP : Tableau de référence 2026 

L'une des tâches les plus courantes dans la gestion DKIM consiste à déterminer quel sélecteur correspond à quel service de messagerie. Le tableau ci-dessous répertorie les sélecteurs DKIM par défaut utilisés par 14 principaux fournisseurs de services de messagerie (ESP) au début de l'année 2026.

Important : Les ESP peuvent modifier les sélecteurs par défaut à tout moment, et certaines plateformes attribuent des sélecteurs spécifiques à chaque compte ou aléatoires. Vérifiez toujours le sélecteur affiché dans votre propre console d'administration ESP par rapport à ce tableau.

Si votre domaine envoie des e-mails via trois ou quatre de ces plateformes simultanément, vous aurez trois ou quatre sélecteurs DKIM actifs dans votre DNS, et chacun d'entre eux doit être suivi, vérifié et renouvelé indépendamment. 

La gestion de plusieurs sélecteurs DKIM sur plusieurs fournisseurs de services de messagerie (ESP) devient complexe à grande échelle, d'autant plus que chaque plateforme a ses propres calendriers de rotation, formats de sélecteurs et exigences DNS. 

PowerDMARC Hosted DKIM permet de centraliser la gestion des sélecteurs via un tableau de bord unique, facilitant ainsi l'ajout, la rotation, la validation et la surveillance des sélecteurs DKIM sans avoir à modifier manuellement et à plusieurs reprises les enregistrements DNS.

Commencez un essai gratuit

Conventions de nommage et bonnes pratiques

Les sélecteurs DKIM peuvent porter pratiquement n'importe quel nom, à condition de respecter les règles syntaxiques. En l'absence d'une convention de nommage cohérente, la gestion des sélecteurs se détériore rapidement à mesure que de nouveaux services sont ajoutés et que les clés sont renouvelées.

Modèles de nommage recommandés

Une approche structurée de la dénomination facilite grandement l'identification des responsables, le suivi des rotations, le dépannage en cas de panne et permet d'éviter toute confusion opérationnelle par la suite. 

Modèle 1 : ESP + Date

Exemples :

• google-1er trimestre 2026
• sendgrid-202601
• hubspot-2025q4

C'est le modèle le plus utile sur le plan opérationnel. D'un seul coup d'œil, vous pouvez identifier quel service détient la clé et quand celle-ci a été renouvelée pour la dernière fois. Lors d'un audit, vous pouvez immédiatement signaler tout sélecteur dont la date remonte à plus de 12 mois.

Modèle 2 : Fonction de service + Séquence

Exemples :

• marketing-01
• transactionnel-01
• entreprise-01

Utile lorsque plusieurs fournisseurs de services de messagerie (ESP) gèrent le même domaine et que vous souhaitez organiser les sélecteurs par flux de messagerie plutôt que par fournisseur.

Modèle 3 : Paramètres par défaut d'ESP (pas de nommage personnalisé)

De nombreux fournisseurs de services de messagerie (ESP) ne permettent pas de personnaliser le nom des sélecteurs. Google Workspace utilise toujours « google ». Microsoft 365 utilise « selector1 » et « selector2 ». Dans ces cas-là, vous devez vous contenter de ce que la plateforme propose et gérer le mappage en externe.

Pratiques de dénomination à éviter

Des noms mal structurés ou trop génériques peuvent prêter à confusion lors des audits, du dépannage et des rotations de clés, en particulier dans les environnements comportant plusieurs ESP et un grand nombre de sélecteurs actifs. Évitez les pratiques de nommage suivantes : 

• Noms génériques hors contexte : `key1`, `test`, `dkim` ne fournissent aucune information sur l'ESP ou l'état de rotation.
• Sélecteurs contenant des informations sensibles: N'intégrez pas de détails relatifs à l'infrastructure interne, de noms d'hôtes de serveurs ou d'identifiants d'employés dans les noms de sélecteurs. Les noms de sélecteurs sont accessibles au public via le DNS.
• Sélecteurs trop longs : Bien que la longueur maximale autorisée soit techniquement de 63 caractères, les sélecteurs de plus de 30 caractères ajoutent une complexité inutile aux enregistrements DNS et aux commandes de recherche.

La configuration d'un domaine unique avec un seul ESP est simple. Il suffit de générer une paire de clés, de publier la clé publique sous le sélecteur de l'ESP, et le tour est joué. Les difficultés opérationnelles apparaissent lorsque ce même domaine envoie des e-mails via plusieurs plateformes.

Un cadre de gestion pratique

Le cycle de vie en cinq étapes présenté ci-dessous propose une approche structurée de la gestion des sélecteurs :

Étape 1 : État des lieux

Répertorier tous les sélecteur DKIM pour chaque domaine que vous gérez, en indiquant l'ESP, la longueur de la clé, la date de publication et la personne ou l'équipe responsable. Les rapports agrégés DMARC constituent le moyen le plus rapide de constituer cet inventaire, car ils révèlent tous les sélecteurs qui signent actuellement les e-mails pour votre domaine, y compris ceux dont personne ne se souvient avoir configuré.

Étape 2 : Valider

Pour chaque sélecteur de votre inventaire, interrogez le DNS afin de vérifier que la clé publique est bien publiée et correctement formatée. Envoyez un e-mail test via chaque fournisseur de services de messagerie (ESP) et assurez-vous que la validation DKIM est réussie. Vérifiez la longueur des clés et signalez tout sélecteur utilisant une clé de 1024 bits.

Étape 3 : Standardiser

Adoptez une convention de nommage et appliquez-la à tous les sélecteurs dont vous avez la charge. Pour les ESP qui utilisent des noms de sélecteurs fixes, documentez clairement le mappage. Définissez un calendrier de rotation et attribuez les responsabilités.

Étape 4 : Suivi.

Utilisez les rapports agrégés DMARC pour surveiller en continu les taux de réussite et d'échec DKIM par sélecteur. Une hausse soudaine du taux d'échec sur un sélecteur spécifique indique généralement un changement au niveau du DNS, l'expiration d'une clé ou une modification de la configuration chez le fournisseur de services de messagerie (ESP).

Étape 5 : Mise hors service

Lorsque vous cessez d'utiliser un ESP, révoquez sa clé DKIM en publiant une valeur `p=` vide dans l'enregistrement DNS du sélecteur. Ne vous contentez pas de supprimer l'enregistrement DNS. Une valeur `p=` vide indique explicitement aux serveurs destinataires que la clé a été révoquée. La suppression pure et simple de l'enregistrement entraîne un échec de la recherche DNS, ce qui est ambigu et peut être interprété différemment selon les destinataires.

PowerDMARC fournit un tableau de bord centralisé qui répertorie tous les sélecteurs DKIM actifs sur l'ensemble des domaines de votre compte, en extrayant simultanément les données des rapports agrégés DMARC et de la surveillance DNS. Pour les MSP gérant un large portefeuille de clients, cela remplace le suivi sur tableur qui devient ingérable dès que l'on dépasse quelques dizaines de domaines.

Rotation des clés DKIM et stratégie de sélection

La rotation des clés DKIM consiste à générer une nouvelle paire de clés et à publier la nouvelle clé publique sous un nouveau sélecteur (ou un sélecteur mis à jour), puis à configurer le service d'envoi pour qu'il signe avec la nouvelle clé privée.

Une clé privée DKIM qui reste inchangée pendant des années représente un risque croissant. Si la clé est compromise à la suite d'une intrusion sur le serveur, d'une menace interne ou d'une faille dans le système de stockage des clés, un pirate peut signer des e-mails qui passeront l'authentification DKIM au nom de votre domaine. Une rotation régulière limite la durée d'exposition.

Comment renouveler les clés DKIM sans interruption de service

Le processus de rotation standard utilise deux sélecteurs à la suite :

1. Générer une nouvelle paire de clés : Créez une nouvelle paire de clés RSA (ou Ed25519) de 2048 bits.
2. Publiez la nouvelle clé publique sous un nouveau sélecteur : Par exemple, si votre sélecteur actuel est `google-2025q3`, publiez la nouvelle clé sous `google-2026q1`.
3. Attendez que la propagation DNS soit effective : Prévoyez 24 à 48 heures pour que le nouvel enregistrement TXT se propage à l'échelle mondiale. Pour Microsoft 365 en particulier, prévoyez jusqu'à 96 heures pour une propagation complète.
4. Mettez à jour la configuration de signature : Configurez l'ESP ou le serveur de messagerie pour qu'il signe les messages sortants à l'aide de la nouvelle clé privée et du nouveau sélecteur.
5. Vérifier : Envoyez des messages de test et vérifiez que le contrôle DKIM est réussi avec le nouveau sélecteur.
6. Révoquer l'ancienne clé : Après une période de transition (généralement de 7 à 14 jours, afin de permettre la livraison des messages en cours de transmission signés avec l'ancienne clé), publiez une valeur `p=` vide pour l'ancien sélecteur.

Rotation des clés DKIM dans les environnements multi-ESP

Chaque ESP dispose de son propre mécanisme de rotation :

• Microsoft 365 : offre une rotation intégrée entre `selector1` et `selector2`. Lancez la rotation via le portail Defender.
• SendGrid : alterne automatiquement entre `s1` et `s2`.
• Google Workspace : nécessite une régénération manuelle de la clé via la console d'administration.
• La plupart des plateformes marketing : nécessitent une rotation manuelle via leurs paramètres d'authentification de domaine.

Le fait de faire tourner tous les sélecteurs le même jour crée une période de risque concentré et complique le dépannage en cas de panne. Répartissez les rotations sur plusieurs semaines ou plusieurs mois.

La fonctionnalité DKIM hébergée de PowerDMARC gère la génération de clés, la publication DNS et la rotation des sélecteurs pour tous les domaines de votre compte, avec des calendriers de rotation configurables par domaine et par ESP.

Commencez un essai gratuit

Erreurs courantes liées au sélecteur DKIM et comment les résoudre 

Lorsque DKIM échoue, la cause est presque toujours liée à l'une des rares erreurs de configuration du sélecteur ou du DNS. Le tableau ci-dessous présente les échecs les plus courants, leurs symptômes et la manière de les résoudre.

Le problème de troncature à 2048 bits en détail

Lorsque les organisations passent de clés DKIM de 1 024 bits à des clés de 2 048 bits (étant donné que le RSA à 1 024 bits est considéré comme peu sûr pour le protocole DKIM), la longueur de la clé publique encodée en base64 double à peu près. La chaîne obtenue dépasse généralement les 400 caractères.

Les enregistrements DNS TXT sont limités à 255 caractères par chaîne au sein de l'enregistrement. La solution, définie dans la RFC 6376, consiste à répartir la valeur sur plusieurs chaînes au sein d'un même enregistrement TXT. Les serveurs de messagerie destinataires concatènent automatiquement ces chaînes.

La plupart des interfaces de gestion DNS courantes ne gèrent pas cela efficacement :

• Certaines interfaces tronquent la valeur à 255 caractères sans avertissement préalable.
• Certaines interfaces rejettent purement et simplement la saisie en affichant un message d'erreur vague.
• Certaines interfaces exigent que l'administrateur divise manuellement la chaîne de caractères et place chaque segment entre guillemets.

Si vous publiez une clé de 2048 bits et que DKIM commence immédiatement à échouer, vérifiez la réponse DNS réelle à l'aide de `dig` ou `nslookup`. Comparez la valeur `p=` renvoyée avec la clé publique complète de votre paire de clés. Si la valeur renvoyée est plus courte, cela signifie que votre fournisseur DNS l'a tronquée.

Pour éviter cela : 

• Utilisez un fournisseur DNS prenant en charge nativement les enregistrements TXT longs (Cloudflare, AWS Route 53 et la plupart des plateformes DNS d'entreprise gèrent correctement cette fonctionnalité).
• Utilisez le protocole DKIM basé sur CNAME, dans lequel le chemin DNS du sélecteur pointe vers un enregistrement CNAME hébergé par le fournisseur de services de messagerie (ESP). Ce dernier gère l'enregistrement TXT sur son infrastructure, ce qui permet d'éviter complètement le problème.
• Si vous devez utiliser un fournisseur qui nécessite un fractionnement manuel, divisez la clé en chaînes de 250 caractères maximum, chacune placée entre guillemets, au sein d'un seul enregistrement TXT.

Sélecteurs DKIM et alignement DMARC 

DKIM et DMARC sont deux protocoles distincts, mais leur interaction prend souvent les administrateurs au dépourvu. Il arrive que DKIM passe le test alors que DMARC échoue. Lorsque cela se produit, la cause est presque toujours un décalage dans l'alignement des domaines, lié à la manière dont le domaine de signature du sélecteur s'articule avec le domaine de l'en-tête « From: ».

Comment fonctionne l'alignement DMARC avec DKIM

DMARC exige qu'au moins un mécanisme d'authentification (SPF DKIM) soit valide et corresponde au domaine indiqué dans l'en-tête « From: ».

Pour l'alignement DKIM , le domaine `d=` dans l'en-tête DKIM-Signature doit correspondre au domaine dans l'en-tête `From:`. Le sélecteur lui-même n'est pas pris en compte pour l'alignement. L'alignement repose uniquement sur le domaine `d=`.

DMARC prend en charge deux modes d'alignement :

Les deux cas où DKIM est validé mais DMARC échoue

L'un des résultats les plus déroutants en matière d'authentification des e-mails est de voir DKIM réussir alors que DMARC échoue. Cela se produit généralement lorsque la signature elle-même est valide, mais que le domaine signataire ne correspond pas correctement au domaine « De : » visible utilisé dans le message.

Scénario 1 : un fournisseur de services de messagerie (ESP) tiers utilise son propre domaine

Certains fournisseurs de services de messagerie (ESP), lorsque DKIM n'est pas explicitement configuré pour votre domaine, signent les messages sortants en utilisant leur propre domaine dans le champ `d=`. Par exemple, un e-mail envoyé au nom de `[email protected]` peut comporter une signature DKIM avec `d=esp-provider.com`.

La vérification DKIM est réussie (la signature est valide), mais DMARC échoue car `esp-provider.com` ne correspond pas à `example.com`.

Configurez la signature DKIM dans l'outil d'envoi d'e-mails (ESP) afin d'utiliser votre propre domaine dans la balise `d=`. Cela implique généralement d'ajouter le sélecteur DKIM de l'ESP en tant qu'enregistrement DNS sous votre domaine et d'activer la signature DKIM personnalisée dans les paramètres de l'ESP.

Scénario 2 : Signature des sous-domaines avec alignement DMARC strict

Si votre politique DMARC utilise un alignement strict (`adkim=s`) et que votre fournisseur de services de messagerie (ESP) signe avec `d=sub.example.com` alors que l'adresse `From:` utilise `example.com`, le test DMARC échouera même si le test DKIM est réussi.

Vous pouvez soit passer à un alignement souple (`adkim=r`, qui est la valeur par défaut), soit vous assurer que le domaine `d=` de la signature DKIM correspond exactement au domaine `From:`.

Vérification de la cohérence entre plusieurs fournisseurs de services de traduction

Dans les environnements multi-ESP, chaque plateforme d'envoi peut signer avec différents domaines `d=`. Un ESP peut signer avec votre domaine racine, un autre avec un sous-domaine, et un troisième peut utiliser par défaut son propre domaine jusqu'à ce que vous configuriez une signature personnalisée.

Les rapports agrégés DMARC indiquent le domaine « d= » et le résultat de l'alignement pour chaque message signé par DKIM. Consultez ces rapports pour identifier tout fournisseur de services de messagerie (ESP) qui signe avec un domaine non aligné. Les rapports DMARC de PowerDMARC mettent en évidence les échecs d'alignement par source d'envoi, ce qui permet d'identifier facilement quel ESP doit être reconfiguré.

Conclusion

Les organisations qui considèrent la gestion des sélecteurs comme une pratique opérationnelle continue, plutôt que comme une tâche ponctuelle de configuration, sont celles qui garantissent une délivrabilité constante, réussissent haut la main les audits et réagissent rapidement aux incidents.

Si vous gérez plus d'une poignée de domaines ou si vous travaillez avec plusieurs fournisseurs de services de messagerie (ESP), il vaut la peine d'investir dans la centralisation de la visibilité de votre sélecteur DKIM.

PowerDMARC offre cette vue centralisée, en combinant l'analyse des rapports agrégés DMARC, la surveillance DNS et la gestion hébergée de DKIM au sein d'une interface unique spécialement conçue pour faire face à ce type de complexité opérationnelle.

Gérez facilement les sélecteurs DKIM sur plusieurs fournisseurs de messagerie. Inscrivez-vous pour un essai pour surveiller les enregistrements DKIM, améliorer la conformité DMARC et protéger la délivrabilité de vos e-mails.

FAQ

Comment trouver mon sélecteur DKIM ?

Vous pouvez trouver votre sélecteur DKIM en affichant l'intégralité des en-têtes d'un e-mail et en repérant l'élément champ DKIM-Signature . La valeur après s= est le sélecteur. Par exemple, dans s=google, le sélecteur est google.

Combien de sélecteurs DKIM un domaine peut-il avoir ?

Il n'y a pas de limite technique quant au nombre de sélecteurs DKIM qu'un domaine peut posséder. Les entreprises utilisent généralement plusieurs sélecteurs simultanément pour différents fournisseurs de messagerie, services ou périodes de rotation des clés.

Plusieurs fournisseurs de services de messagerie (ESP) peuvent-ils utiliser des sélecteurs DKIM différents sur un même domaine ?

Oui. Chaque fournisseur de messagerie utilise généralement son propre sélecteur DKIM. Par exemple, Google Workspace, SendGrid et Mailchimp peuvent tous disposer de sélecteurs distincts sous le même domaine sans que cela ne pose de problème.

Quelle est la différence entre un sélecteur DKIM et une clé DKIM ?

Le sélecteur est le nom utilisé pour localiser l'enregistrement DKIM dans le DNS, tandis que la clé DKIM désigne la paire de clés cryptographiques publique/privée utilisée pour signer et vérifier les e-mails.

Pourquoi le test DKIM est-il réussi alors que celui de DMARC échoue toujours ?

Cela est généralement dû à un échec de l'alignement DMARC. La signature DKIM peut être validée, mais le domaine d= de la signature DKIM ne correspond pas au champ From: utilisé dans l'e-mail.

À quelle fréquence faut-il renouveler les sélecteurs et les clés DKIM ?

Les bonnes pratiques en matière de sécurité recommandent de renouveler les clés DKIM tous les 6 à 12 mois. Pendant cette période de transition, l'ancien et le nouveau sélecteur doivent rester actifs temporairement afin d'éviter tout échec de validation pendant la propagation DNS.