Vérificateur DKIM

DomainKeys Identified Mail (RFC 6376) permet à un domaine expéditeur d'apposer une signature numérique sur les en-têtes d'un message. La signature est générée avec une clé privée détenue par le serveur d'envoi et couvre un ensemble défini d'en-têtes ainsi que le corps du message. Le serveur destinataire récupère la clé publique correspondante dans le DNS et recalcule la signature ; si les deux correspondent, le message n'a pas été modifié en chemin et provient bien d'un serveur détenant la clé privée.

DKIM ne dit rien sur l'adresse d'enveloppe ni sur le "From" affiché au destinataire - cet alignement relève de DMARC. DKIM prouve seulement que le contenu signé est intact et a été signé par le détenteur du sélecteur.

• La signature se trouve dans un en-tête DKIM-Signature ajouté par le serveur expéditeur
• La vérification récupère la clé publique via un enregistrement TXT, jamais dans le message lui-même
• Un domaine peut faire tourner plusieurs sélecteurs en parallèle - un par prestataire d'envoi est courant

La clé publique se trouve sous `<sélecteur>._domainkey.<domaine>` en tant qu'enregistrement TXT. Le sélecteur est une étiquette arbitraire choisie par celui qui configure la signature - votre fournisseur d'emails l'attribue, et il n'est pas devinable à partir du seul nom de domaine. Un enregistrement typique ressemble à ceci :

• `v=DKIM1` - version du protocole, toujours présente
• `k=rsa` - algorithme de clé (rsa est standard ; ed25519 est valide mais plus rare)
• `p=` - la clé publique elle-même, encodée en base64
• `p=` avec une valeur vide signifie que la clé a été révoquée volontairement

Contrairement à un enregistrement MX ou SPF, une clé DKIM n'a pas de nom d'hôte fixe - elle n'existe que sous le sélecteur choisi lors de la configuration, donc un vérificateur doit soit connaître ce sélecteur, soit tester les plus courants. Google Workspace utilise typiquement `google`, Microsoft 365 alterne entre `selector1`/`selector2`, et des expéditeurs transactionnels comme Sendgrid, Mailgun ou Amazon SES ont chacun leur propre nom par défaut. Si vous connaissez le sélecteur exact attribué par votre prestataire, le saisir directement évite ce test à l'aveugle et ne vérifie que cet enregistrement.

La RFC 6376 traite le sélecteur comme unité de rotation : pour renouveler une clé, l'expéditeur publie un nouveau sélecteur avec la nouvelle clé publique, bascule la signature dessus, et ne retire l'ancien sélecteur qu'une fois qu'aucun email en file ne le référence plus. Publier un tag `p=` vide sur l'ancien sélecteur le révoque immédiatement sans supprimer l'enregistrement - utile en cas de suspicion de fuite de la clé privée, car un enregistrement supprimé peut rester en cache chez les résolveurs pendant toute la durée du TTL, alors qu'un `p=` vide est sans ambiguïté dès qu'il est récupéré.

Un sélecteur orphelin - encore publié dans le DNS avec une clé valide longtemps après que le système d'envoi qui l'utilisait a été arrêté - reste une faille ouverte. Quiconque récupère cette ancienne clé privée peut toujours produire des signatures qui se vérifient.

Chaque sélecteur qui répond obtient sa propre ligne. Un sélecteur valide signale une clé publique trouvée sous son sous-domaine `_domainkey`, avec la valeur de l'enregistrement affichée pour confirmer que le tag de clé n'est pas vide. Un sélecteur avec un `p=` vide est signalé comme révoqué, à distinguer d'un sélecteur qui n'existe simplement pas. Quand aucun des sélecteurs testés ne répond, les résultats listent ceux qui ont été essayés, pour savoir s'il faut ajouter le sélecteur de votre prestataire et relancer la vérification. Une ligne de synthèse distincte indique combien de sélecteurs ont réellement été trouvés sur l'ensemble du balayage, et un enregistrement ADSP - un mécanisme antérieur à DMARC - est signalé à part s'il est encore publié, car il révèle une configuration résiduelle plutôt qu'une protection active.