Rotation des clés DKIM : comment opérer sans le moindre drame

Ce qu’est réellement la rotation DKIM (et ce que ce n’est pas)

La rotation DKIM consiste à changer la clé cryptographique qui signe vos courriels sortants. En pratique, cela signifie :

• Vous générez une nouvelle clé privée sur le signataire (MTA ou relais sortant).
• Vous publiez la clé publique correspondante dans le DNS sous un sélecteur.
• Vous basculez la signature pour utiliser le nouveau sélecteur (ou signez avec les deux pendant la transition).
• Vous gardez l’ancienne clé publique disponible suffisamment longtemps pour que les vérificateurs puissent valider les anciens messages.

Ce que ce n’est pas : un exercice d’« optimisation » de délivrabilité. La rotation ne vous rend pas plus digne de confiance en soi ; elle réduit le risque lié à la compromission de clé et à la dérive opérationnelle. Si vos mails échouent déjà SPF/DMARC, la rotation DKIM ne vous sauvera pas. Elle peut toutefois révéler que vous viviez sur du temps emprunté.

Pourquoi la rotation crée du drame

Trois raisons :

1. Le DNS est un système de cache distribué avec ses opinions. Vous ne « changez pas le DNS », vous négociez avec des résolveurs que vous ne contrôlez pas.
2. L’email est asynchrone. Les messages peuvent être retardés, réessayés, mis en file ou livrés des heures plus tard, nécessitant toujours l’ancienne clé pour la validation.
3. Les gens confondent les domaines. Le domaine visible dans From, le domaine d= de DKIM, et le domaine d’enveloppe SMTP sont liés mais pas identiques. Les confondre transforme des changements « simples » en appels d’incident multi-équipes.

Conseil d’opinion d’entrée : faites la rotation en double-signature si vous le pouvez. Si vous ne le pouvez pas, vous ferez quand même une rotation sûre, mais vous devrez être plus prudent sur le timing et la conservation des anciennes clés dans le DNS. Autre chose : ne faites jamais de rotation pendant un lancement majeur. Votre futur vous enverra une carte postale depuis le dossier spam.

Faits intéressants et un peu d’histoire

• DKIM est issu d’une fusion. DomainKeys (Yahoo) et Identified Internet Mail (Cisco) ont été combinés en DKIM, standardisé comme RFC 4871 en 2007.
• DKIM n’encrypte pas les emails. Il signe certains en-têtes et le corps (ou une partie) pour détecter la falsification, pas pour garder des secrets.
• Le sélecteur est un primitif de versioning. DKIM a été conçu pour la rotation : les sélecteurs existent pour publier plusieurs clés simultanément.
• Les premières déploiements DKIM utilisaient uniquement RSA. RSA est devenu le défaut ; Ed25519 est apparu plus tard dans des spécifications et implémentations récentes, mais l’adoption est inégale.
• Les clés 2048 bits sont devenues le « standard sérieux ». Les clés RSA 1024 bits se voient encore, mais certains récepteurs les considèrent comme faibles ou en violation de politique.
• La validation DKIM a lieu au moment de la réception. Cela signifie que les récepteurs ont besoin d’un accès DNS à votre clé publique lorsqu’ils évaluent le message — pas au moment où vous l’avez envoyé.
• DKIM survit mieux au transfert que SPF. SPF vérifie le chemin ; DKIM vérifie le contenu. Les transferts brisent SPF régulièrement ; DKIM survit souvent si le transféreur ne réécrit pas les parties signées.
• DMARC a rendu DKIM opérationnellement obligatoire. Une fois l’application de DMARC devenue courante, DKIM a cessé d’être « agréable à avoir » et est devenu « ne me réveillez pas ».

Le modèle mental : sélecteurs, clés, DNS et temps

Pensez à DKIM comme à quatre éléments en mouvement :

• Signataire : le système qui détient la clé privée et ajoute l’en-tête DKIM-Signature (Postfix + OpenDKIM, un relais cloud, ou un ESP).
• Sélecteur : une chaîne comme s2026q1 qui choisit quelle clé récupérer dans le DNS.
• Enregistrement DNS : un enregistrement TXT à <selector>._domainkey.<domain> contenant la clé publique et les métadonnées.
• Récepteur : Gmail, Outlook, et tous les autres qui effectuent des recherches DNS et valident la signature lors de l’acceptation du message.

Le temps est la dépendance cachée

Le système a deux horloges séparées :

1. Propagation et cache DNS : TTL plus comportement des résolveurs.
2. Latence de livraison du courrier : files, réessais, graylisting, congestion, et « cet appareil legacy » qui réessaiera demain.

La rotation échoue quand vous supprimez l’ancienne clé du DNS avant que le monde ait fini de valider le courrier signé avec elle. Elle échoue aussi quand vous changez de signataire avant que la nouvelle clé ne soit visible par les récepteurs. La réponse est ennuyeuse : chevauchement.

Une citation, parce que ça colle

L’espoir n’est pas une stratégie. — attribué à divers responsables ingénierie ; couramment utilisé en opérations et fiabilité.

Blague 1 : Le cache DNS, c’est comme des paillettes : vous pensez avoir tout nettoyé, et ça réapparait trois semaines plus tard dans votre voiture.

Prévol : inventaire et contrôle du rayon d’impact

Avant de toucher aux clés, répondez à trois questions avec des preuves :

1. Qui signe aujourd’hui ? Peut-être vos MTAs. Peut-être votre ESP. Peut-être les deux (marketing vs transactionnel). « Les deux » est courant et pas intrinsèquement mauvais — jusqu’au moment où vous faites tourner l’un et oubliez l’autre.
2. Quels domaines et sous-domaines sont impliqués ? example.com, mail.example.com, news.example.com, et des domaines return-path personnalisés peuvent tous exister. Chacun peut avoir des sélecteurs et des politiques séparées.
3. Quelle politique dépend du succès DKIM ? L’application DMARC (quarantine/reject) transforme une petite erreur DKIM en un arrêt total.

Choisissez un schéma de nommage des sélecteurs qui vieillira bien

Les sélecteurs sont des chaînes. C’est à la fois du pouvoir et du chaos. Choisissez quelque chose qui reste sensé au fil des années et des équipes :

• Bon : s2026q1, mta1-2026-01, rotate-01
• Mauvais : default, dkim, test, new (parce que « new » devient « old » avant que votre ticket ne ferme)

Décidez de la durée de chevauchement

Ma recommandation pratique :

• Conservez l’ancien sélecteur publié au moins 7 jours après la bascule pour la plupart des organisations.
• Conservez-le 30 jours si vous avez des files longues, des systèmes réglementés, ou tout comportement de type « nous envoyons des relevés hebdomadaires ».

Les récepteurs peuvent valider d’anciens messages plus tard (pensez : livraison retardée, retraitement, ou déplacements de boîtes). Il n’y a pas de récompense à supprimer rapidement les anciennes clés DNS. La récompense, c’est de ne pas être dérangé.

Tâches pratiques avec commandes, sorties et décisions

Le but des commandes n’est pas du travail occupé. C’est transformer « je pense » en « je sais ». Ces tâches sont écrites pour un environnement Linux typique avec Postfix + OpenDKIM, plus une vérification DNS générique. Adaptez les chemins et noms de services si vous utilisez un autre signataire, mais gardez la discipline : observer, changer, observer encore.

Tâche 1 : Confirmer quel sélecteur signe actuellement

Envoyez-vous un message depuis votre système, puis inspectez les en-têtes dans votre boîte. Sur un serveur mail Linux, vous pouvez aussi chercher DKIM-Signature dans les logs si vous journalisez les résultats du milter.

cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan 04 09:12:11 mta1 postfix/cleanup[23111]: 4A2B9123: message-id=<...>
Jan 04 09:12:11 mta1 opendkim[1122]: 4A2B9123: DKIM-Signature field added (s=selector2025, d=example.com)
Jan 04 09:12:12 mta1 postfix/qmgr[977]: 4A2B9123: from=<noreply@example.com>, size=..., nrcpt=1 (queue active)

Ce que cela signifie : Vous signez actuellement avec le sélecteur selector2025 pour d=example.com.

Décision : C’est votre sélecteur « ancien ». Vous devez conserver son enregistrement DNS pendant et après la rotation.

Tâche 2 : Énumérer tous les enregistrements DKIM DNS que vous publiez actuellement

cr0x@server:~$ dig +short TXT selector2025._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"

Ce que cela signifie : Ce sélecteur existe et publie une clé publique.

Décision : Si dig ne renvoie rien, arrêtez. Vous signez avec un sélecteur qui n’est pas publié, et la rotation n’est pas votre plus gros problème.

Tâche 3 : Vérifier le TTL effectif et si vous pouvez le réduire en toute sécurité

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

Ce que cela signifie : Le TTL est de 3600 secondes (1 heure).

Décision : Si le TTL est énorme (comme 86400), réduisez-le un jour avant la bascule pour que les caches se vident plus rapidement. Si vous ne pouvez pas changer le TTL (DNS géré avec contraintes), planifiez un chevauchement plus long et faites de la double-signature si possible.

Tâche 4 : Générer une nouvelle paire de clés DKIM (exemple OpenDKIM)

cr0x@server:~$ sudo mkdir -p /etc/opendkim/keys/example.com/selector2026
cr0x@server:~$ sudo opendkim-genkey -b 2048 -D /etc/opendkim/keys/example.com/selector2026 -d example.com -s selector2026
cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector2026
total 8
-rw------- 1 root root 1704 Jan  4 10:02 selector2026.private
-rw-r--r-- 1 root root  451 Jan  4 10:02 selector2026.txt

Ce que cela signifie : Vous avez une clé privée et un modèle TXT pour le DNS.

Décision : Utilisez RSA 2048 bits sauf raison forte contraire. Si votre plateforme supporte Ed25519 et que vos récepteurs l’acceptent, vous pouvez l’envisager — mais ne lancez pas une expérience de compatibilité pendant une rotation.

Tâche 5 : Valider les permissions des fichiers de clés (les clés privées ne sont pas un projet de groupe)

cr0x@server:~$ sudo stat -c "%n %a %U:%G" /etc/opendkim/keys/example.com/selector2026/selector2026.private
/etc/opendkim/keys/example.com/selector2026/selector2026.private 600 root:root

Ce que cela signifie : Le fichier est lisible uniquement par root.

Décision : Assurez-vous que l’utilisateur OpenDKIM peut le lire (souvent par propriété ou groupe). De mauvaises permissions causent des pannes silencieuses « la signature a cessé ».

Tâche 6 : Configurer OpenDKIM pour connaître la nouvelle clé (KeyTable/SigningTable)

cr0x@server:~$ sudo grep -n "example.com" /etc/opendkim/KeyTable /etc/opendkim/SigningTable
/etc/opendkim/KeyTable:12:selector2025._domainkey.example.com example.com:selector2025:/etc/opendkim/keys/example.com/selector2025/selector2025.private
/etc/opendkim/SigningTable:9:*@example.com selector2025._domainkey.example.com

Ce que cela signifie : Tout pointe vers selector2025.

Décision : Ajoutez les lignes du nouveau sélecteur. Si vous prévoyez la double-signature, votre approche dépendra du logiciel (certains supportent plusieurs signatures ; d’autres non). Si vous ne pouvez pas faire de double-signature, vous ferez un cutover mais garderez l’ancien DNS publié.

Tâche 7 : Ajouter le nouveau sélecteur à la KeyTable

cr0x@server:~$ sudo bash -lc 'echo "selector2026._domainkey.example.com example.com:selector2026:/etc/opendkim/keys/example.com/selector2026/selector2026.private" >> /etc/opendkim/KeyTable'
cr0x@server:~$ sudo tail -n 2 /etc/opendkim/KeyTable
selector2025._domainkey.example.com example.com:selector2025:/etc/opendkim/keys/example.com/selector2025/selector2025.private
selector2026._domainkey.example.com example.com:selector2026:/etc/opendkim/keys/example.com/selector2026/selector2026.private

Ce que cela signifie : OpenDKIM sait maintenant où se trouve la nouvelle clé privée.

Décision : Si vous utilisez une KeyTable en base ou un autre signataire, l’étape équivalente s’applique : enregistrez le sélecteur et le chemin de clé.

Tâche 8 : Basculer la SigningTable vers le nouveau sélecteur (exemple de cutover en single-signing)

cr0x@server:~$ sudo sed -i 's/\*@example.com selector2025\._domainkey\.example\.com/*@example.com selector2026._domainkey.example.com/' /etc/opendkim/SigningTable
cr0x@server:~$ sudo grep -n "\*@example.com" /etc/opendkim/SigningTable
9:*@example.com selector2026._domainkey.example.com

Ce que cela signifie : Les nouveaux mails seront signés avec selector2026 une fois qu’OpenDKIM aura rechargé.

Décision : Ne rechargez pas tant que le DNS n’est pas publié. Signer avec un sélecteur que personne ne peut récupérer équivaut à DKIM=fail chez les récepteurs.

Tâche 9 : Extraire la valeur TXT DNS que vous devez publier

cr0x@server:~$ sudo cat /etc/opendkim/keys/example.com/selector2026/selector2026.txt
selector2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB" )  ; ----- DKIM key selector2026 for example.com

Ce que cela signifie : Cette valeur p= est ce que les récepteurs utiliseront.

Décision : Publiez-la exactement. Pas de guillemets supplémentaires depuis l’interface DNS, pas de sauts de ligne insérés dans la clé, pas de points-virgules manquants. Les outils DNS varient ; validez après publication.

Tâche 10 : Publier le nouvel enregistrement DKIM, puis vérifier depuis plusieurs résolveurs

cr0x@server:~$ dig +noall +answer TXT selector2026._domainkey.example.com
selector2026._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB"

Ce que cela signifie : L’enregistrement existe et le TTL est de 300 secondes (5 minutes).

Décision : Si le TTL n’est pas celui prévu, corrigez-le maintenant tant que personne n’en dépend. Interrogez aussi un résolveur public connu pour réduire le risque de « mon DNS corporate me ment ».

cr0x@server:~$ dig @1.1.1.1 +short TXT selector2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB"

Ce que cela signifie : Un résolveur public le voit.

Décision : Ne basculez pas tant qu’au moins deux résolveurs indépendants ne retournent pas la nouvelle clé de manière cohérente.

Tâche 11 : Recharger OpenDKIM proprement et confirmer qu’il n’y a pas d’erreur

cr0x@server:~$ sudo systemctl reload opendkim
cr0x@server:~$ sudo systemctl status opendkim --no-pager -l
● opendkim.service - OpenDKIM Milter
     Loaded: loaded (/lib/systemd/system/opendkim.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:00:03 UTC; 1h 8min ago
       Docs: man:opendkim(8)
   Main PID: 1122 (opendkim)
     Status: "Running"

Ce que cela signifie : Le service est up. C’est nécessaire, pas suffisant.

Décision : Vérifiez immédiatement les logs pour des erreurs de chargement de clé ; OpenDKIM peut tourner tout en n’ajoutant pas de signatures.

Tâche 12 : Confirmer qu’OpenDKIM utilise le nouveau sélecteur dans les logs

cr0x@server:~$ sudo tail -n 20 /var/log/mail.log | grep -E "opendkim|DKIM-Signature" | tail -n 5
Jan 04 10:12:07 mta1 opendkim[1122]: 6C9FD123: DKIM-Signature field added (s=selector2026, d=example.com)
Jan 04 10:12:07 mta1 postfix/qmgr[977]: 6C9FD123: from=<noreply@example.com>, size=..., nrcpt=1 (queue active)

Ce que cela signifie : Le courrier est maintenant signé avec selector2026.

Décision : Effectuez une vérification externe (en-têtes Gmail ou une boîte de test) avant de déclarer victoire.

Tâche 13 : Vérifier que DKIM passe sur un message reçu (inspection des en-têtes)

Dans Gmail ou Outlook, affichez la source originale du message. Vous cherchez les résultats d’authentification.

cr0x@server:~$ python3 - <<'PY'
import re,sys
msg=open('/tmp/raw.eml','r',errors='ignore').read()
m=re.search(r'Authentication-Results:.*', msg, re.I)
print(m.group(0) if m else "no Authentication-Results header found")
PY
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector2026 header.b=AbCdEf...

Ce que cela signifie : DKIM passe et le sélecteur est correct.

Décision : Si DKIM=fail, arrêtez et déboguez avant de décommissionner l’ancienne clé.

Tâche 14 : Suivre l’utilisation continue de l’ancien sélecteur (pour savoir quand il est sûr de le retirer)

cr0x@server:~$ sudo grep -R "s=selector2025" -n /var/log/mail.log | tail -n 5
Jan 03 23:48:51 mta1 opendkim[1122]: 1F0A9123: DKIM-Signature field added (s=selector2025, d=example.com)

Ce que cela signifie : Le dernier courrier observé signé avec l’ancien sélecteur date d’hier.

Décision : Si cela apparaît encore après la bascule, vous avez un autre signataire, un second MTA, ou un déploiement partiel. Ne supprimez pas l’ancien DNS tant que vous ne savez pas que tous les signataires sont passés.

Tâche 15 : Confirmer que l’alignement DMARC ne sera pas impacté par la rotation

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; adkim=s; aspf=s"

Ce que cela signifie : DMARC est en alignement strict (adkim=s). Cela signifie que le d= de DKIM doit correspondre exactement au domaine From.

Décision : Assurez-vous que votre signataire utilise d=example.com (pas un sous-domaine) si le From est @example.com. La rotation est un bon moment pour changer accidentellement le d= et provoquer des échecs DMARC.

Tâche 16 : Détecter un format DNS cassé (guillemets, points-virgules et chaînes coupées)

cr0x@server:~$ dig +short TXT selector2026._domainkey.example.com | tr -d '"' | grep -E "v=DKIM1;|p="
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB

Ce que cela signifie : Vous voyez proprement v=DKIM1 et p= dans le TXT retourné.

Décision : Si votre sortie contient des parenthèses errantes, des fragments cassés, ou un p= manquant, corrigez le DNS. Certains consoles tronquent les longs TXT si vous collez avec des espaces blancs.

Blague 2 : Faire tourner des clés DKIM sans surveillance, c’est comme échanger de parachute en plein vol parce que l’étiquette avait l’air vieille.

Checklists / plan étape par étape (rotation sans drame)

Plan A : Bonne pratique (sélecteurs à double-signature)

Si votre pile de signature supporte l’ajout de deux en-têtes DKIM-Signature (ancien et nouveau sélecteur), faites-le. Cela vous offre la bonne paresse : les récepteurs peuvent valider avec l’une ou l’autre clé pendant que les caches et retardataires se mettent à jour.

1. Choisissez un nouveau sélecteur avec un nommage sain (par ex., s2026q1).
2. Abaissez le TTL sur le(s) enregistrement(s) DKIM courant(s) 24 heures avant (par ex. à 300 secondes), si votre processus DNS le permet.
3. Générez une nouvelle paire de clés sur le signataire, stockez la clé privée en sécurité, définissez les permissions, et enregistrez-la dans la config du signataire.
4. Publiez la nouvelle clé publique dans le DNS sous le nouveau sélecteur. Vérifiez via plusieurs résolveurs.
5. Activez la double-signature : signez chaque message avec les deux sélecteurs pendant au moins 48 heures (souvent plus dans les grandes organisations).
6. Mesurez : confirmez que les récepteurs rapportent DKIM=pass avec le nouveau sélecteur de façon cohérente.
7. Cessez de signer avec l’ancien sélecteur une fois que vous êtes confiant, mais conservez l’enregistrement DNS de l’ancien sélecteur.
8. Retirez l’ancienne clé DNS seulement après la période de chevauchement et une fois que vous avez des preuves qu’aucun système ne l’utilise encore.

Plan B : Cutover en single-signing (toujours sûr, juste moins indulgent)

1. Choisir le sélecteur et générer les clés.
2. Publier le nouveau sélecteur dans le DNS en premier. Vérifiez depuis l’extérieur de votre réseau.
3. Attendre au moins une fenêtre TTL (et réalistement plus) pour que les caches l’aient récupéré.
4. Basculez la signature vers le nouveau sélecteur et rechargez le signataire.
5. Vérifiez que DKIM passe en utilisant des en-têtes de boîtes réelles (Gmail/Outlook) et vos logs.
6. Conservez l’ancien sélecteur DNS publié pendant la période de chevauchement.

Plan de rollback (rédigez-le avant d’en avoir besoin)

Les rollbacks doivent être ennuyeux. Si vous improvisez, vous perdez déjà du temps.

• Déclencheur de rollback : montée du taux d’échec DKIM ; échecs DMARC ; recherches de clé retournant NXDOMAIN de façon intermittente ; grands récepteurs indiquant « mauvaise signature ».
• Action de rollback : remettez la SigningTable sur l’ancien sélecteur et rechargez le signataire ; conservez les deux enregistrements DNS publiés.
• Vérification du rollback : confirmez que les logs montrent la signature avec l’ancien sélecteur ; confirmez DKIM pass dans une boîte externe.

Important : le rollback n’est possible que si vous n’avez pas supprimé l’ancien enregistrement (et si vous avez gardé la clé privée accessible au signataire). Vous seriez surpris de voir combien de personnes « nettoient » trop tôt.

Règles pour la fenêtre de changement (mes opinions fermes)

• Faites-le en milieu de semaine pendant les heures avec support présent. Les rotations du vendredi soir sont un hobby, pas une pratique.
• Ne coupez pas avec d’autres changements. Rotation de clé + modifications de routage sortant = comment entrer en enfer des « causes plausibles multiples ».
• Annoncez aux parties prenantes qui possèdent des flux d’envoi. Plateformes marketing, CRM, systèmes de tickets, et applis internes. Vous tournez leur machine de réputation ; ils méritent un avertissement.

Guide de diagnostic rapide

Quand la délivrabilité baisse après une rotation, vous avez besoin d’un chemin rapide et ordonné. Pas d’une séance de brainstorm.

Première étape : déterminer si DKIM échoue à cause du DNS ou de la signature

1. Vérifiez un vrai message reçu (Gmail/Outlook en-têtes) : cherchez Authentication-Results et s’il indique dkim=pass ou dkim=fail, ainsi que quel header.s sélecteur a été utilisé.
2. Si ça échoue, interrogez le DNS pour ce sélecteur depuis un résolveur public et depuis votre serveur. Si le DNS ne renvoie rien ou des réponses incohérentes, vous avez un problème de propagation/cache.
3. Si le DNS paraît correct, inspectez les logs du signataire pour « key not found », « permission denied », ou « no signature added ». Voilà votre pipeline de signature.

Deuxième étape : vérifier l’impact sur l’alignement DMARC

1. Confirmez que la valeur DKIM d= correspond au domaine visible dans From, surtout si DMARC est en alignement strict (adkim=s).
2. Confirmez qu’aucun nouveau chemin sortant ne réécrit le domaine From ou n’ajoute une autre signature DKIM qui perturbe les récepteurs.

Troisième étape : identifier un cutover partiel et la confusion multi-signataires

1. Cherchez dans les logs les deux sélecteurs. Si les deux apparaissent encore des jours plus tard, vous avez plus d’un signataire.
2. Vérifiez les ESP marketing ou relais cloud qui signent pour vous. Ils peuvent avoir leur propre configuration DKIM et leurs sélecteurs.
3. Cherchez des messages avec plusieurs en-têtes DKIM-Signature et voyez lesquels passent/échouent. Une signature échouante peut être acceptable si une autre passe, mais les règles d’alignement DMARC comptent.

Le goulot que vous traquez

La plupart des « incidents de rotation DKIM » sont soit :

• Enregistrement DNS manquant ou mal formé pour le nouveau sélecteur.
• Signataire mal configuré (signant toujours l’ancien sélecteur, mauvais domaine, mauvais chemin de clé, permissions incorrectes).
• Signataire non pris en compte (une unité métier n’a pas reçu le mémo).

Erreurs courantes : symptôme → cause → correctif

1) Symptom : DKIM échoue soudainement pour tous les mails après le cutover

Cause racine : Vous avez basculé la signature vers le nouveau sélecteur avant de publier le nouvel enregistrement DNS (ou avant que les caches puissent le voir).

Correctif : Publiez l’enregistrement, vérifiez via des résolveurs publics, puis attendez le TTL ou revenez à l’ancien sélecteur jusqu’à ce que le DNS soit visible.

2) Symptom : DKIM passe parfois, échoue parfois

Cause racine : DNS en split-brain (réponses d’autorité multiples pendant la propagation), ou certains récepteurs interrogent des caches avec NXDOMAIN.

Correctif : Assurez-vous que le fournisseur DNS affiche un enregistrement cohérent sur tous les serveurs autoritaires ; prolongez le chevauchement ; évitez de supprimer l’ancienne clé trop tôt.

3) Symptom : l’en-tête DKIM est totalement absent

Cause racine : Milter non lancé, Postfix non connecté, ou OpenDKIM ne peut pas lire la clé privée à cause des permissions/SELinux.

Correctif : Vérifiez le statut des services et les logs ; validez Postfix smtpd_milters ; corrigez la propriété des clés et les contextes SELinux si nécessaire.

4) Symptom : DKIM indique « bad signature » même si le DNS est correct

Cause racine : Quelque chose modifie le message après signature (injection de pied de page, « line wrapping », filtres de contenu), ou incompatibilité de canonicalization.

Correctif : Assurez-vous que la signature DKIM se produit le plus tard possible dans le pipeline ; évitez les modifications après signature ; revérifiez les paramètres de canonicalization.

5) Symptom : DKIM passe mais DMARC échoue

Cause racine : le domaine DKIM d= n’est pas aligné avec le domaine From (surtout en alignement strict).

Correctif : Signez avec le domaine From, ou ajustez la politique DMARC en connaissance de cause. Ne « corrigez » pas en affaiblissant DMARC à moins d’accepter le compromis de sécurité.

6) Symptom : certains expéditeurs utilisent encore l’ancien sélecteur des semaines plus tard

Cause racine : Un second système d’envoi (ESP, SaaS, MTA régional) n’a pas été mis à jour.

Correctif : Inventoriez toutes les sources sortantes ; consultez les rapports DMARC agrégés (si vous en avez) et les logs ; mettez à jour chaque signataire ; conservez l’ancienne clé DNS jusqu’à la migration du dernier.

7) Symptom : Les récepteurs signalent « clé trop courte » ou traitent les mails comme suspects

Cause racine : Vous avez généré une clé RSA 1024 bits (ou un récepteur a une politique contre cela).

Correctif : Passez à RSA 2048 bits ; republiez ; refaites le cutover. Si vous faites la rotation de toute façon, n’envoyez pas une clé faible parce que c’est plus rapide.

8) Symptom : l’enregistrement TXT DNS semble tronqué

Cause racine : Copie/coller ou interface DNS qui a inséré des espaces ou perdu des fragments ; certains fournisseurs exigent une convention de guillemets.

Correctif : Renseignez de nouveau l’enregistrement en utilisant le format multi-chaînes correct du fournisseur ; validez que le p= retourné est contigu quand vous le récupérez.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont fait la rotation DKIM un jeudi matin. Le ticket de changement était propre : nouvelle clé, nouveau sélecteur, mise à jour du signataire. L’ingénieur a fait la vérification évidente : dig depuis son laptop montrait le nouvel enregistrement TXT. Il a basculé la signature. Tout avait l’air correct pendant cinq minutes.

Puis le support a commencé à envoyer des captures d’écran : « Votre message a été bloqué. » Les mails transactionnels vers un gros fournisseur de boîte grand public ont commencé à atterrir en spam ou à échouer DMARC. L’on-call a vu que DKIM échouait chez ce fournisseur, mais passait dans une petite boîte de test. Confus. Le genre de confusion qui fait perdre une heure.

L’hypothèse erronée était simple : « Si mon résolveur le voit, tout le monde le voit. » Leur DNS corporate était configuré pour forwarder les requêtes vers un résolveur rapide qui avait déjà récupéré le nouvel enregistrement. Le grand fournisseur, toutefois, touchait un chemin de cache différent et voyait parfois NXDOMAIN pour le nouveau sélecteur. Ce n’était pas de la « propagation lente » mystique ; c’était le comportement normal de caches distribués amplifié par un TTL qui avait été de 24 heures jusqu’à la veille.

La correction n’a pas été héroïque. Ils ont rollbacké la signature vers l’ancien sélecteur, laissé le nouveau sélecteur publié, attendu une journée complète, puis basculé de nouveau. La leçon : la vérification doit inclure des résolveurs publics et des checks autoritatifs, pas seulement « le DNS que mon laptop utilise aujourd’hui ».

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise voulait un « DNS propre ». Leur équipe sécurité poussait pour une suppression agressive des anciennes clés DKIM : rotation hebdomadaire, suppression immédiate après bascule, zone minimale. Ça paraissait net sur une diapositive.

Ça s’est retourné contre eux de façon ennuyeuse. Leur trafic sortant incluait des systèmes qui mettaient des messages en file pendant des heures (envois par batch, notifications retardées, réessais lors d’un throttling fournisseur). Un sous-ensemble de messages avait été signé avec l’ancienne clé et livré tardivement, après que l’enregistrement DNS de l’ancien sélecteur ait été supprimé. Les récepteurs ne pouvaient pas les valider. Certains fournisseurs ont traité cela comme un signal négatif plus fort qu’un message non signé parce que cela ressemblait à de la falsification.

Ils n’avaient pas d’alarme « DKIM échoue parce que vous avez supprimé la clé trop tôt ». Ils n’avaient qu’un tableau de bord « délivrabilité en baisse », ce qui est l’équivalent opérationnel d’un détecteur de fumée qui déclenche après que la cuisine est déjà en feu.

Ils ont fait marche arrière : conserver les anciens sélecteurs dans le DNS pendant des semaines, pas des jours. Ils ont aussi introduit un versioning des sélecteurs par trimestre et limité la fréquence des rotations à quelque chose en rapport avec le risque réel. Un DNS plus « propre » n’a pas amélioré la délivrabilité. Il n’a amélioré la vie de personne.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation avait l’habitude, qui paraissait excessive jusqu’au jour où elle a servi : ils maintenaient un « inventaire auth mail » listant chaque système qui envoie du mail, quel domaine il utilise dans From, quel sélecteur DKIM il utilise, et qui en est responsable. Ce n’était pas glamour. C’était mis à jour par des humains. C’était correct.

Quand ils ont planifié une rotation DKIM pour le domaine parent, ils ont utilisé cet inventaire pour préparer le changement à travers les systèmes : deux MTA on-prem, un relais cloud, et un outil de ticketing SaaS qui signait en leur nom avec un sous-domaine délégué. Ils ont fait la rotation de chaque flux délibérément et ont conservé les anciennes clés publiées pendant un mois.

À mi-parcours, ils ont découvert qu’un MTA régional signait encore avec un sélecteur plus ancien. Pas par incompétence — parce que la région avait une fenêtre de maintenance différente et un pipeline de gestion de config séparé. L’inventaire l’a rendu visible. Ils n’ont pas supprimé l’ancien sélecteur. Aucun incident n’a eu lieu. Personne n’a remarqué. C’est l’objectif.

Ils avaient aussi un snippet de rollback pré-écrit dans leur gestion de configuration : un changement pour revenir au sélecteur précédent et redéployer. Ils ne l’ont jamais utilisé. Le fait qu’ils pouvaient l’utiliser est la raison pour laquelle la rotation est restée calme.

FAQ

1) À quelle fréquence devons-nous faire la rotation des clés DKIM ?

Faites la rotation selon un calendrier qui correspond à votre niveau de risque : communément du trimestriel à l’annuel. Rotatez immédiatement si vous suspectez une compromission de clé, si un signataire a été exposé, ou si vous avez perdu le contrôle de la clé privée.

2) Puis-je réutiliser le même sélecteur et simplement changer la clé dans le DNS ?

Vous pouvez, mais vous ne devriez pas. Les sélecteurs existent pour permettre le chevauchement des clés et éviter le chaos de cache. Réutiliser un sélecteur force un cutover brutal et rend le dépannage plus difficile parce que « le nom du sélecteur » ne signifie plus « quelle version de clé ».

3) Combien de temps dois-je garder l’ancienne clé publique DKIM dans le DNS ?

Au moins 7 jours après avoir cessé de signer avec elle ; 30 jours est plus sûr en entreprise. Si vous avez des files longues ou des envois périodiques, gardez-la plus longtemps. La supprimer tôt n’apporte pas grand-chose et peut nuire aux mails livrés tardivement.

4) Quel TTL devrais-je utiliser pour les enregistrements TXT DKIM ?

Les valeurs courantes sont 300 à 3600 secondes. Pour une rotation, abaisser le TTL un jour à l’avance aide. Après la rotation, vous pouvez le remonter modérément si vous voulez moins de requêtes DNS, mais ne poursuivez pas des micro-optimisations.

5) Quelle taille de clé devrions-nous utiliser ?

Utilisez RSA 2048 bits sauf si votre environnement a une alternative validée et une compatibilité récepteur confirmée. Les clés 1024 bits sont de plus en plus considérées comme faibles ou inacceptables par politique.

6) Si DKIM passe, avons-nous encore besoin de SPF ?

Oui. SPF et DKIM échouent de manières différentes. DMARC permet qu’un DKIM (aligné) ou SPF satisfasse la politique. Garder les deux vous donne de la résistance face au forwarding, aux relais et aux chemins d’envoi étranges.

7) Pourquoi DKIM échoue-t-il seulement pour les messages transférés ?

Les transféreurs modifient parfois le corps ou les en-têtes (ajout de pieds de page, réécriture des sujets, altération des frontières MIME). S’ils touchent aux parties signées, la signature casse. Les solutions incluent minimiser les modifications après signature et utiliser des mécanismes de transfert compatibles DMARC quand possible.

8) Pouvons-nous faire une rotation sans interruption si nous utilisons un ESP tiers ?

Généralement oui, mais vos contrôles sont différents : vous générez/publiez les clés DNS et configurez l’usage du sélecteur chez l’ESP. La même règle de chevauchement s’applique : publiez le nouveau sélecteur d’abord, vérifiez, puis basculez. Conservez l’ancien sélecteur publié après.

9) Quelle est la manière la plus sûre de tester avant de basculer le trafic de production ?

Utilisez un sous-domaine dédié ou un petit sous-ensemble de flux mail si votre signataire supporte des politiques par expéditeur ou par domaine. Publiez le nouveau sélecteur, signez des mails de test avec, et validez dans plusieurs principaux fournisseurs de boîte.

10) Plusieurs signatures DKIM confondent-elles les récepteurs ?

Non, plusieurs signatures sont courantes. Les récepteurs peuvent valider une ou toutes. Ce qui compte, c’est qu’au moins une signature DKIM alignée passe pour DMARC (selon la politique et le mode d’alignement).

Conclusion : prochaines étapes à faire cette semaine

Si vous voulez que la rotation DKIM soit une non-événement, traitez-la comme tout autre changement de production : mettez-la en scène, vérifiez-la en externe, chevauchez plus longtemps que votre instinct, et ne supprimez pas les choses trop tôt.

• Rédigez votre inventaire d’expéditeurs : chaque système, chaque domaine From, chaque sélecteur DKIM.
• Choisissez un schéma de sélecteur qui survive aux changements d’organisation (par trimestre ou par année, cela suffit).
• Faites un dry-run sur un sous-domaine non critique pour valider vos outils DNS et le comportement de reload du signataire.
• Ajoutez deux moniteurs : (1) « présence de signature DKIM » sur des échantillons sortants, (2) « taux de DKIM pass » via des en-têtes de boîtes reçues ou la télémétrie disponible.
• Planifiez la rotation avec chevauchement : publiez la nouvelle clé, vérifiez sur des résolveurs publics, puis basculez la signature, conservez l’ancienne clé publiée pendant des semaines.

Votre but n’est pas de prouver que vous pouvez faire une rotation de clés. Votre but est que personne ne remarque que vous l’avez fait.