Incohérence du sélecteur DKIM : la correction en 2 minutes

Ce qu’est réellement une incohérence de sélecteur DKIM

DKIM utilise la cryptographie à clé publique pour permettre à un récepteur de vérifier qu’un message a été signé par quelqu’un qui contrôle un domaine.
Le récepteur extrait un en-tête DKIM-Signature, repère un d= (domaine) et un s= (sélecteur), puis recherche un enregistrement TXT DNS à :

<selector>._domainkey.<domain>

Quand on parle d’« incohérence de sélecteur DKIM », on entend généralement l’un des cas suivants :

• Le message est signé avec le sélecteur s=foo, mais le DNS n’a que bar._domainkey.
• Le signataire est configuré pour utiliser le sélecteur foo, mais la clé publiée dans foo._domainkey ne correspond pas à la clé privée utilisée pour signer.
• Le domaine dans la signature d= ne correspond pas au domaine où vous avez publié l’enregistrement (fréquent avec les sous-domaines et les domaines de rebond).
• Le DNS est correct, le signataire est correct, mais la visibilité DNS est fausse (DNS split-horizon, résolveurs obsolètes, cache, ou délégation cassée).

Les incohérences DKIM ne sont pas des problèmes de type « le courrier est en panne ». Elles sont pire : le courrier circule toujours, mais avec une confiance réduite. Cela signifie que votre incident n’apparaît pas comme une panne nette. Il apparaît comme « le pipeline a l’air correct » tandis que les e-mails commerciaux atterrissent dans le spam.
Problème classique de fiabilité : l’échec est silencieux jusqu’à ce qu’il coûte cher.

Un détail opérationnel important : les récepteurs traitent souvent DKIM comme un signal parmi d’autres. Une incohérence peut ne pas faire rebondir instantanément le courrier, mais elle peut faire basculer du trafic limite — surtout si la réputation IP est médiocre ou si vous envoyez en rafales.

Blague #1 : les sélecteurs DKIM sont comme des étiquettes de bagage — perdez l’étiquette et votre e-mail voyage toujours, juste pas où vous le souhaitiez.

Procédure de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Quand l’alerte arrive (« DKIM échoue »), votre mission est de trouver rapidement le goulot d’étranglement : est-ce un problème DNS, un problème de signature ou un problème d’alignement de domaine ?
Ne commencez pas par faire tourner les clés. Ne commencez pas par éditer le DNS en panique. Commencez par lire ce que le mail dit réellement de lui-même.

Premier point : confirmer quel sélecteur et domaine sont utilisés actuellement

• Récupérez un message frais du flux affecté (pas un échantillon d’il y a une semaine).
• Extraites les d= et s= depuis DKIM-Signature.
• Regardez Authentication-Results pour voir comment le récepteur l’a évalué.

Si le sélecteur dans l’en-tête n’est pas celui que vous pensez avoir configuré, vous avez déjà terminé : vous dépannez le mauvais expéditeur ou le mauvais chemin de signature.
Dans les grandes organisations, il existe plusieurs signataires (passerelle cloud, MTA, système de tickets, CRM). L’e-mail que vous tenez vous indique lequel signe réellement.

Deuxième point : interrogez le DNS pour ce sélecteur exact

• Interrogez le TXT pour <selector>._domainkey.<domain>.
• Interrogez au moins deux résolveurs différents (votre résolveur d’entreprise et un public).
• Vérifiez NXDOMAIN vs réponse vide vs enregistrement tronqué/cassé.

Si le DNS ne renvoie pas de clé DKIM pour le sélecteur indiqué dans l’en-tête, corrigez le DNS ou corrigez le sélecteur utilisé par le signataire. Généralement une ligne suffit.

Troisième point : validez que la clé publique correspond à la clé privée du signataire

• Sur l’hôte signataire, localisez le fichier de clé privée dans votre configuration OpenDKIM/OpenSMTPD/Haraka/quelque soit le setup.
• Dérivez la clé publique depuis la clé privée et comparez-la à ce qui est dans le DNS (ou republiez la bonne).

Si le DNS a une clé mais que la signature échoue à la vérification, vous avez probablement un décalage de clé (mauvaise clé publiée, mauvais fichier déployé, sélecteur pointant vers une vieille clé, ou plusieurs signataires non synchronisés).

Idée paraphrasée (attribuée) : « Vous ne pouvez pas améliorer ce que vous ne mesurez pas », souvent associée à Peter Drucker. Dans le domaine de l’authentification des e-mails, « mesurer » signifie « lire l’en-tête et interroger le DNS ».

La correction en 2 minutes (la vérité ennuyeuse)

La plupart des incidents d’incohérence de sélecteur se terminent de la même manière : quelqu’un a changé un sélecteur à un endroit et a oublié que l’autre endroit existait.
Vous le corrigez en rendant le sélecteur cohérent entre :

1. Ce que le signataire émet (le s= dans DKIM-Signature)
2. Ce que publie le DNS (l’enregistrement TXT pour ce sélecteur)
3. Quel fichier de clé le signataire utilise (clé privée mappée à ce sélecteur)

La « correction en 2 minutes » la plus rapide dépend de quel côté est fautif :

• DNS ne contient pas le sélecteur présent dans les mails en production : publiez l’enregistrement TXT pour ce sélecteur (copiez depuis la clé publique attendue par le signataire).
• Le signataire utilise le mauvais sélecteur : mettez à jour la configuration du signataire pour utiliser le sélecteur déjà présent dans le DNS, rechargez le service.
• Mismatch de clé : publiez la bonne clé publique pour le sélecteur utilisé, ou déployez la bonne clé privée pour le sélecteur déjà publié.

Le conseil que je donne aux équipes : préférez modifier le signataire pour qu’il corresponde au DNS uniquement si vous êtes absolument sûr que le DNS est correct et à jour.
Sinon, adaptez le DNS à ce que le signataire utilise déjà, car c’est cela que vos récepteurs évaluent actuellement. Changer le signataire peut prendre du temps à se propager à travers passerelles, conteneurs ou systèmes fournisseurs.

N’oubliez pas le cache. Si vous publiez un nouvel enregistrement TXT, les récepteurs ne le verront pas forcément immédiatement. Votre TTL autoritatif compte, tout comme le comportement de cache du récepteur.
Mais : si votre enregistrement n’existait pas (NXDOMAIN) et que vous l’ajoutez, de nombreux systèmes le prendront en compte rapidement ; le cache négatif peut tout de même vous gêner pendant quelques minutes.

Faits et contexte historique (pourquoi cela se répète)

1. DKIM normalisé en 2007 : Il provient de la fusion de DomainKeys (Yahoo) et Identified Internet Mail (Cisco). Cette fusion explique la présence du nom « domainkey » et la terminologie DKIM.
2. Les sélecteurs ont été conçus pour la rotation des clés : Le sélecteur permet de publier plusieurs clés en même temps et de changer de signataire sans supprimer immédiatement les anciennes clés.
3. Les limites de longueur des TXT DNS ont façonné DKIM : Les chaînes TXT ont des contraintes pratiques, et les longues clés sont souvent réparties en plusieurs chaînes entre guillemets. Certains outils gèrent mal cela et créent des cassures « invisibles ».
4. Les récepteurs utilisent souvent la canonicalisation relaxée par défaut : DKIM prend en charge la canonicalisation « simple » et « relaxed » pour tolérer les changements d’espaces en transit. C’est pourquoi de nombreux e-mails valident encore après certaines modifications de format d’en-tête.
5. DMARC (2012) a rendu visibles les échecs DKIM auprès des dirigeants : DKIM existait avant DMARC, mais les rapports et l’application DMARC ont fait de l’authentification un sujet de conseil d’administration.
6. Les clés 2048 bits sont devenues la référence : Les clés 1024 bits sont de plus en plus considérées comme faibles ; certains récepteurs les pénalisent. Les rotations coïncident souvent avec un changement de taille de clé, ce qui augmente le risque d’erreur de sélecteur.
7. Certaines plateformes font tourner automatiquement les sélecteurs : Les plates-formes cloud peuvent générer des sélecteurs comme selector1/selector2 ou des chaînes spécifiques au fournisseur. Les humains « standardisent » ensuite et cassent les choses.
8. Le DNS split-horizon est un méchant récurrent : Les résolveurs internes renvoyant des réponses différentes des externes peuvent donner l’impression que DKIM est correct en interne alors qu’il échoue sur Internet public.

Trois mini-histoires d’entreprise (comment les grands cassent le courrier)

Mini-histoire n°1 : L’incident causé par une fausse hypothèse

Une entreprise SaaS de taille moyenne a migré d’une pile Postfix + OpenDKIM sur site vers un relais e-mail cloud pour les notifications sortantes.
Le plan de migration tenait sur un joli tableur : « Mettre à jour SPF, configurer DKIM, vérifier DMARC. » Tout le monde a hoché la tête. L’invitation calendrier disait « 30 minutes. »

L’ingénieur en charge du DNS a supposé que le nom du sélecteur était arbitraire, alors il a choisi quelque chose de mémorable : prod2025.
Il a publié prod2025._domainkey.example.com avec la clé affichée par l’UI du relais. Propre.

Mais le relais signait déjà les messages avec s=selector1. La page « DKIM settings » de l’UI montrait deux sélecteurs et un commutateur pour la rotation.
L’ingénieur a vu « prod2025 » dans la doc et a pensé qu’il devait le nommer lui-même, donc il l’a fait. Il n’a jamais changé le sélecteur effectif du relais.

Résultat : authentification échouée pour tous les mails sortants, politique DMARC en « quarantine », et les e-mails de réinitialisation de mot de passe les plus importants se sont mis à arriver dans le spam. Les tickets de support ont explosé. Personne ne pouvait reproduire le problème en interne parce que leur boîte de test avait des règles de blanchiment.

La correction fut presque insultante : publier l’enregistrement TXT pour selector1 et arrêter d’inventer des noms de sélecteurs, sauf si vous changez aussi le signataire.
Le postmortem a gardé une leçon utile : quand l’authentification des e-mails échoue, lisez d’abord l’en-tête. Ne faites pas confiance à ce que vous pensez avoir configuré.

Mini-histoire n°2 : L’« optimisation » qui a mal tourné

Une entreprise globale avait une flotte de passerelles mail bien rangée dans deux régions. Quelqu’un a décidé d’« optimiser » les mises à jour DNS en abaissant le TTL de tous les enregistrements DKIM à 60 secondes.
L’idée : rotation plus rapide, rollback plus rapide, moins de risque. Ça sonnait raisonnable en réunion.

Ce qui s’est réellement passé : leur fournisseur DNS autoritatif a commencé à limiter le taux de certaines requêtes des résolveurs et a parfois renvoyé SERVFAIL pendant les pics.
Ce n’était pas une panne complète ; c’était intermittent et dépendant de la charge. Les passerelles mail signaient toujours avec le même sélecteur, mais les récepteurs ne pouvaient parfois pas récupérer la clé à cause d’échecs DNS transitoires.

DKIM a commencé à échouer de façon sporadique chez des grands fournisseurs grand public. Les équipes de délivrabilité voyaient « certaines campagnes bien, d’autres non », ce qui génère de l’incertitude et des tensions.
Le SRE d’astreinte n’avait aucune erreur sur les passerelles mail. Le service de signature DKIM était sain. Le problème était en aval : la récupération de la clé.

Ils ont rétabli un TTL raisonnable (heures, pas secondes), corrigé les paramètres du fournisseur DNS et cessé de traiter DKIM comme un système de feature flag.
L’« optimisation » a augmenté le volume de requêtes, amplifié un maillon faible et leur a donné un mode de défaillance difficile à détecter depuis leur réseau.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de services financiers avait une pratique peu glamour : chaque système d’envoi sortant envoyait chaque semaine un e-mail canari vers une boîte externe dédiée chez deux fournisseurs.
La boîte était surveillée par un script qui analysait les en-têtes, enregistrait les résultats DKIM/SPF/DMARC, et alarmait en cas de changement.

Un fournisseur a fait tourner un sélecteur DKIM un vendredi soir dans le cadre d’une « maintenance de sécurité de routine ».
Le samedi matin, l’alarme canari a déclenché : DKIM fail (sélecteur introuvable). Personne n’était sur un gros bridge d’incident parce que les systèmes de production étaient sains — seul l’état de confiance des e-mails était rompu.

L’astreinte a suivi le playbook : lire l’en-tête, voir s=vendor2026, interroger le DNS, NXDOMAIN.
Leur équipe DNS a publié le nouvel enregistrement en quelques minutes, car ils disposaient déjà d’une procédure de changement et d’une liste pré-approuvée de sous-domaines DKIM.

Aucun impact client digne d’un post de blog. Ce qui est exactement le but.
Ils n’ont pas « bougé vite ». Ils ont bougé de façon prévisible.

Tâches pratiques : commandes, sorties attendues et décisions

Ci‑dessous des tâches réelles que vous pouvez exécuter pendant un incident. Chaque tâche inclut : la commande, ce que signifie une sortie typique, et la décision suivante à prendre.
Adaptez les noms d’hôtes, domaines et chemins à votre environnement, mais conservez la logique.

Task 1: Extract selector and domain from a DKIM-Signature header

cr0x@server:~$ grep -i '^DKIM-Signature:' -m1 -n /tmp/message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Ce que ça signifie : L’e-mail live indique d=example.com et s=selector1.

Décision : Arrêtez les débats. Votre recherche DNS doit cibler selector1._domainkey.example.com.

Task 2: Check receiver-side evaluation in Authentication-Results

cr0x@server:~$ grep -i '^Authentication-Results:' -n /tmp/message.eml | head
12:Authentication-Results: mx.google.com;
13:       dkim=fail header.i=@example.com header.s=selector1 header.b=AbCdEf;
14:       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
15:       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Ce que ça signifie : DKIM a échoué pour selector1 ; SPF a réussi mais DMARC a échoué (probablement problème d’alignement ou DKIM requis par la politique).

Décision : Concentrez-vous d’abord sur la disponibilité et l’exactitude de l’enregistrement DKIM ; ensuite vérifiez l’alignement DMARC une fois DKIM rétabli.

Task 3: Query the DKIM TXT record with your default resolver

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com

Ce que ça signifie : Pas de sortie indique généralement NXDOMAIN ou aucun enregistrement TXT retourné (selon les options de dig).

Décision : Relancez avec plus de détail pour distinguer « pas d’enregistrement » d’« échec DNS ».

Task 4: Distinguish NXDOMAIN vs SERVFAIL vs empty answer

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51234
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Ce que ça signifie : NXDOMAIN : le nom n’existe pas publiquement (ou pas depuis ce résolveur).

Décision : Publiez l’enregistrement manquant, ou corrigez le sélecteur utilisé par le signataire si le DNS contient déjà un autre.

Task 5: Query authoritative DNS directly (remove “my resolver lies”)

cr0x@server:~$ dig +short NS example.com
ns1.dns-provider.net.
ns2.dns-provider.net.

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @ns1.dns-provider.net
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que ça signifie : Le serveur autoritatif a l’enregistrement.

Décision : Si les récepteurs échouent encore, suspectez le cache des résolveurs, des délais de propagation, ou que le récepteur voit une vue DNS différente (split-horizon, délégation).

Task 6: Compare answers from a public resolver (external reality check)

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @8.8.8.8
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que ça signifie : Le résolveur public voit la clé. Bien.

Décision : Si DKIM échoue toujours, passez au mismatch de clé / chemin de signature / canonicalisation et modifications d’en-têtes.

Task 7: Check if the record is broken by quoting, whitespace, or missing tags

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "morekeymaterial..."

Ce que ça signifie : Les chaînes TXT séparées sont normales. Les récepteurs les concatènent. L’absence de k=rsa est généralement acceptable (des valeurs par défaut existent), mais des balises malformées ou des guillemets typographiques ne le sont pas.

Décision : Si l’enregistrement contient des guillemets non-ASCII, des points-virgules errants, ou des sauts de ligne insérés par votre UI DNS, corrigez le format.

Task 8: Verify OpenDKIM is actually signing and which selector it uses

cr0x@server:~$ sudo opendkim-testkey -d example.com -s selector1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'selector1._domainkey.example.com'
opendkim-testkey: key OK

Ce que ça signifie : Depuis cet hôte, OpenDKIM peut récupérer la clé publique et elle est correctement analysée.

Décision : Si les récepteurs distants échouent encore, soit ils ne peuvent pas récupérer le DNS, soit le signataire n’utilise pas réellement cette clé/ce sélecteur pour le flux de mails affecté.

Task 9: Identify which KeyTable/SigningTable rule applies (common mismatch source)

cr0x@server:~$ sudo grep -R --line-number -E 'SigningTable|KeyTable|Selector|Domain' /etc/opendkim.conf /etc/opendkim/*
/etc/opendkim.conf:12:KeyTable           /etc/opendkim/KeyTable
/etc/opendkim.conf:13:SigningTable       refile:/etc/opendkim/SigningTable
/etc/opendkim/KeyTable:5:selector1._domainkey.example.com example.com:selector1:/etc/opendkim/keys/example.com/selector1.private
/etc/opendkim/SigningTable:3:*@example.com selector1._domainkey.example.com

Ce que ça signifie : Pour le mail depuis @example.com, vous prévoyez de signer avec selector1 en utilisant un fichier de clé privée spécifique.

Décision : Si l’en-tête montre un autre sélecteur, votre chemin réel de mail contourne ce signataire ou un autre signataire ajoute DKIM plus tard.

Task 10: Confirm the private key file exists and permissions are sane

cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector1.private
-r-------- 1 opendkim opendkim 1704 Jan  4 10:12 /etc/opendkim/keys/example.com/selector1.private

Ce que ça signifie : Le fichier existe, lisible uniquement par l’utilisateur/groupe opendkim. Bien.

Décision : Si les permissions sont incorrectes (lisible par tous ou illisible par opendkim), corrigez-les et redémarrez ; des clés illisibles peuvent entraîner des mails non signés ou des erreurs runtime.

Task 11: Derive public key from the private key (prove whether DNS matches)

cr0x@server:~$ sudo openssl rsa -in /etc/opendkim/keys/example.com/selector1.private -pubout -outform PEM | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Ce que ça signifie : Vous disposez maintenant d’un empreinte stable de la clé publique dérivée de la clé de signature.

Décision : Comparez-la au matériel de clé que vous pensez être dans le DNS (tâche suivante). Si elles diffèrent, vous avez un mismatch de clé, pas un problème de nom de sélecteur.

Task 12: Extract the DNS public key and fingerprint it the same way

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com | tr -d '"' | sed 's/.*p=//' | tr -d ' ' | base64 -d 2>/dev/null | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Ce que ça signifie : Si le hash correspond à la tâche 11, DNS et clé privée correspondent. Sinon, vous publiez la mauvaise clé pour ce sélecteur.

Décision : Publiez la clé correcte ou déployez la clé privée correcte. Ne faites pas de « redémarrages aléatoires » tant que les empreintes ne correspondent pas.

Task 13: Check Postfix is actually sending through the DKIM milter

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_protocol = 6
milter_default_action = accept

Ce que ça signifie : Postfix est configuré pour utiliser un milter DKIM sur localhost port 8891.

Décision : Si ces paramètres sont vides, ou si seul smtpd_milters est défini, certains chemins mail (comme submissions ou reinjections) peuvent contourner la signature. Corrigez la config pour couvrir tous les flux.

Task 14: Confirm the milter service is actually listening

cr0x@server:~$ sudo ss -ltnp | grep 8891
LISTEN 0      128        127.0.0.1:8891      0.0.0.0:*    users:(("opendkim",pid=2145,fd=6))

Ce que ça signifie : OpenDKIM est en cours d’exécution et à l’écoute.

Décision : Si rien n’écoute, redémarrez OpenDKIM et vérifiez les logs. Si OpenDKIM est down, vous verrez peut-être du courrier non signé plutôt qu’une incohérence de sélecteur — symptôme différent, correction différente.

Task 15: Validate a selector exists when you’re rotating keys (list what’s published)

cr0x@server:~$ for s in selector1 selector2 prod2026; do echo "== $s =="; dig +noall +answer TXT ${s}._domainkey.example.com; done
== selector1 ==
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
== selector2 ==
== prod2026 ==

Ce que ça signifie : Seul selector1 existe dans le DNS ; selector2/prod2026 n’existent pas.

Décision : Ne basculez pas le signataire sur selector2/prod2026 tant que le DNS n’est pas prêt, à moins que vous aimiez regarder les graphiques de délivrabilité chuter.

Blague #2 : la propagation DNS est la seule partie d’Internet qui fonctionne encore officiellement sur « avez-vous essayé d’attendre ? » comme étape de dépannage.

Listes de vérification / plan pas à pas

Checklist d’incident (15 minutes pour stabiliser)

1. Obtenez un message défaillant frais. Pas transféré, pas renvoyé, pas une capture d’écran.
2. Extraites d= et s=. C’est votre vérité terrain.
3. Interrogez le DNS pour ce sélecteur et domaine. Utilisez votre résolveur et un résolveur public.
4. Si NXDOMAIN : publiez l’enregistrement TXT manquant ou revenez à un sélecteur existant côté signataire.
5. Si l’enregistrement existe : lancez opendkim-testkey (ou l’équivalent de votre signataire) depuis l’hôte signataire.
6. Si « key OK » localement mais échecs chez les récepteurs : suspectez visibilité DNS, délégation, ou SERVFAIL intermittents à l’échelle.
7. Vérifiez le chemin de signature : confirmez que le mail passe par la passerelle/milter attendu.
8. Confirmez l’alignement DMARC : une fois DKIM rétabli, vérifiez que d= s’aligne avec le domaine From: pour votre politique.
9. Envoyez un canari. Vérifiez les en-têtes côté récepteur et capturez des preuves pour le postmortem.

Checklist de changement (rotation sûre de sélecteur/clé sans drame)

1. Générez une nouvelle paire de clés. Utilisez un nom de sélecteur qui ne risque pas de collision (ex. s2026a).
2. Publiez le nouveau sélecteur dans le DNS en premier. Attendez qu’il soit visible depuis l’extérieur.
3. Déployez la clé privée sur tous les signataires. Confirmez les permissions et le mapping de configuration (SigningTable/KeyTable).
4. Basculez la signature vers le nouveau sélecteur. Rechargez les services, vérifiez avec un e-mail canari.
5. Gardez l’ancien sélecteur publié. Pendant au moins plusieurs jours ; plus si vous avez des flux retardés ou des systèmes d’archivage.
6. Supprimez l’ancien sélecteur seulement après vérification. Ne nettoyez pas le même jour. C’est comme ça qu’on crée des heisenbugs dans la journalisation de conformité.

Checklist de conception (réduire la probabilité d’incohérence)

• Un seul propriétaire pour la signature sortante. Si cinq équipes peuvent changer le DKIM, personne ne possède la délivrabilité.
• Centralisez les changements DNS avec revue de code. Les enregistrements DKIM sont de la config de production, pas un ticket helpdesk.
• Monitoring canari externe. Les contrôles internes manquent le DNS split-horizon et le comportement des résolveurs externes.
• Consignez le sélecteur dans votre runbook. Pas « DKIM configuré », mais « le sélecteur est X ; procédure de rotation Y ».

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “dkim=fail (no key for signature)”

Cause racine : DNS ne contient pas l’enregistrement TXT pour le sélecteur indiqué dans l’en-tête du message, ou le récepteur ne peut pas le résoudre.

Correction : Publiez <selector>._domainkey.<domain> enregistrement TXT. Vérifiez via les serveurs autoritatifs et des résolveurs publics. Contrôlez les TTL de cache négatif si ça « échoue encore » brièvement.

2) Symptom: “dkim=fail (bad signature)” while DNS record exists

Cause racine : La clé publique dans le DNS ne correspond pas à la clé privée utilisée pour signer. Souvent causé par un déploiement partiel, un mauvais chemin de fichier, ou une rotation de clés seulement sur un nœud.

Correction : Comparez l’empreinte de la clé publique dérivée (Tasks 11–12). Redéployez la clé correcte partout ou mettez à jour le DNS pour correspondre à la clé de signature déployée. Testez ensuite avec un message frais.

3) Symptom: DKIM passes sometimes, fails sometimes

Cause racine : Plusieurs chemins sortants ou plusieurs signataires avec des configs incohérentes ; ou résolutions DNS intermittentes à l’échelle du récepteur (SERVFAIL, limites de taux).

Correction : Corrélez les messages échoués aux IPs/hôtes d’envoi ; vérifiez quel signataire a ajouté DKIM. Assurez-vous que tous les nœuds ont la même config sélecteur/clé. Si c’est lié au DNS, stabilisez les TTL et la fiabilité du fournisseur.

4) Symptom: SPF passes, DKIM passes, but DMARC fails

Cause racine : Échec d’alignement : le domaine DKIM d= ne s’aligne pas avec le domaine visible From:, ou le domaine mailfrom SPF ne s’aligne pas.

Correction : Assurez-vous que DKIM signe avec un d= qui correspond (ou est un sous-domaine autorisé par votre mode d’alignement DMARC) au domaine From. Ne « corrigez » pas DMARC en affaiblissant la politique sauf si c’est nécessaire.

5) Symptom: Everything looks correct internally, external receivers still show selector missing

Cause racine : DNS split-horizon, délégation cassée, ou changements DNS appliqués seulement aux vues internes.

Correction : Interrogez les nameservers autoritatifs et un résolveur public depuis l’extérieur du réseau corporate. Corrigez les enregistrements de zone publics et la délégation. L’authentification du courrier est jugée sur l’Internet public, pas votre VPN.

6) Symptom: DKIM fails after “minor” email infrastructure change

Cause racine : Le mail contourne maintenant l’étape de signature DKIM (nouveau chemin de relais, port de soumission changé, nouvelle passerelle, paramètres milter modifiés).

Correction : Tracez le chemin du message. Confirmez que les milters s’appliquent à tous les points d’injection (smtp et non-smtp). Validez que DKIM-Signature est présent et produit par le système attendu.

7) Symptom: DKIM fails only for one subdomain or one business unit

Cause racine : Mismatch de SigningTable : les règles signent @example.com mais pas @alerts.example.com, ou le signataire utilise d=example.com alors que le From est un sous-domaine et la politique exige un alignement strict.

Correction : Mettez à jour les règles SigningTable ; publiez des clés pour le domaine correct ; confirmez l’alignement avec le mode DMARC (relaxed vs strict).

8) Symptom: Receiver says “key too short” or treats DKIM as weak

Cause racine : Clé 1024 bits encore en usage ou configuration héritée.

Correction : Faites une rotation vers des clés 2048 bits. Publiez un nouveau sélecteur, déployez la nouvelle clé, changez la signature, puis retirez l’ancien sélecteur. N’essayez pas d’« éditer » l’ancienne clé sur place.

FAQ

1) Qu’est‑ce qu’un sélecteur DKIM, en termes simples ?

C’est le nom de la clé. Le sélecteur indique aux récepteurs quel enregistrement DNS récupérer pour la clé publique utilisée pour vérifier la signature.
Un domaine peut avoir plusieurs sélecteurs afin de pouvoir faire tourner les clés ou laisser différents systèmes signer avec différentes clés.

2) Comment trouver le sélecteur utilisé par mon système ?

Ne devinez pas. Regardez un message réel et lisez l’en-tête DKIM-Signature : s=....
Si le message n’a pas de DKIM-Signature, vous avez un autre problème : la signature ne se produit pas.

3) Pourquoi une incohérence de sélecteur apparaît‑elle souvent comme un échec DMARC ?

DMARC exige qu’au moins SPF ou DKIM réussisse et s’aligne avec le domaine From.
Si DKIM échoue à cause d’un sélecteur manquant/mismatch, et que SPF n’est pas aligné (fréquent avec des expéditeurs tiers), DMARC échoue.

4) Puis‑je « juste changer le sélecteur » sur le signataire ?

Oui, mais uniquement si le DNS publie déjà la clé de ce sélecteur et que le signataire dispose de la clé privée correspondante.
Changer d’abord le signataire est le moyen le plus rapide de créer un incident global de délivrabilité.

5) Pourquoi je vois deux sélecteurs comme selector1 et selector2 sur certaines plateformes ?

Beaucoup de fournisseurs supportent une rotation transparente en laissant deux clés publiées et en basculant entre elles.
La plateforme peut signer avec l’une pendant que l’autre est en staging. Les humains suppriment souvent « celle inutilisée » et causent des échecs intermittents.

6) Combien de temps devrais‑je garder un ancien sélecteur publié après rotation ?

Plus longtemps que vous ne le pensez. Plusieurs jours est courant ; plus si vous avez des files d’attente retardées, des relais qui réessaient, des systèmes de forwarding, ou de la journalisation de conformité.
La vérification DKIM se fait au moment de la réception, donc une livraison retardée peut encore nécessiter l’ancienne clé publique.

7) Que faire si le DNS semble correct depuis mon laptop mais les récepteurs échouent encore ?

Vérifiez depuis l’extérieur de votre réseau et interrogez les serveurs autoritatifs directement.
Le DNS split-horizon, la délégation cassée et les problèmes du fournisseur DNS apparaissent comme « ça marche ici » jusqu’à ce que ça ne marche plus.

8) DKIM dépend‑il de l’IP d’envoi comme le fait SPF ?

Pas directement. La vérification DKIM dépend de la signature et de la requête DNS pour la clé, pas de l’adresse IP d’envoi.
Mais les récepteurs combinent les signaux : si la réputation IP est mauvaise, un hic DKIM pèse davantage.

9) Une incohérence de sélecteur est‑elle la même chose qu’une « mauvaise signature » ?

Non. L’incohérence de sélecteur signifie souvent « aucune clé trouvée pour ce sélecteur » (enregistrement manquant ou nom incorrect).
« Mauvaise signature » signifie généralement que l’enregistrement existe mais que la clé publique ne vérifie pas la signature (mismatch de clé ou message modifié).

10) Devons‑nous automatiser la validation DKIM ?

Oui. Un simple canari externe qui capture les en-têtes et alerte sur les changements DKIM/SPF/DMARC détectera les problèmes de sélecteur avant vos clients.
C’est un de ces cas où la surveillance ennuyeuse bat les actions héroïques.

Étapes suivantes pour éviter la réapparition de l’incident

L’incohérence de sélecteur DKIM est le type de défaillance qui fait paraître les équipes intelligentes comme maladroites, parce que ce n’est rarement « difficile ».
C’est généralement juste une configuration incohérente entre le DNS et les signataires, avec suffisamment d’éléments mobiles pour cacher l’erreur.
La correction est rapide quand vous traitez l’en-tête d’e-mail comme source unique de vérité.

Faites ceci ensuite, tant que la douleur est fraîche :

1. Consignez vos sélecteurs en production par domaine et par système d’envoi.
2. Ajoutez un canari externe qui alerte sur les changements DKIM/SPF/DMARC.
3. Standardisez la rotation : publiez le nouveau sélecteur d’abord, puis déployez les clés, puis basculez la signature, puis retirez les anciennes clés plus tard.
4. Arrêtez d’improviser les noms de sélecteur sauf si vous contrôlez la configuration du signataire de bout en bout.

L’authentification des e-mails n’est pas glamour. C’est pour cela que cela casse.
Traitez DKIM comme une infrastructure de production, pas comme une case à cocher dans un portail fournisseur, et l’incohérence de sélecteur deviendra une correction de deux minutes — une seule fois, pas tous les trimestres.