Rotation des clés DKIM : runbook opérationnel sans downtime (J-7 à J+30)

La rotation de clé DKIM est une opération récurrente. Les guides vendor (Microsoft, AWS, SendGrid) décrivent le bouton « rotate » sans expliquer la fenêtre de chevauchement, le délai de propagation DNS ni la procédure de rollback. Ce runbook répond à la question « comment roter une clé DKIM sans downtime » avec une timeline calendaire J-7 à J+30, des scripts openssl testés et les pièges remontés du terrain.

Pour la référence générale, consultez le guide complet DKIM et la structure d'un enregistrement DKIM. Ici, l'objectif est opérationnel : générer la paire de clés DKIM, publier le sélecteur DKIM, basculer la signature DKIM, surveiller DMARC, retirer l'ancien sélecteur. Public visé : sysadmins, DevOps, SRE et équipes infrastructure en production.

Pourquoi roter une clé DKIM en production ?

Trois raisons opérationnelles justifient une rotation de clé DKIM périodique.

Compromission de clé. Une clé privée DKIM finit toujours par fuiter : sauvegarde non chiffrée, accès KMS legacy d'un ex-employé, dump d'un fournisseur SaaS. La rotation limite la fenêtre d'exploitation d'une fuite.

Limite cryptographique. La RFC 8301 a déprécié les clés RSA sous 1024 bits dès 2018 et recommande RSA 2048 minimum. Une clé RSA 1024 publiée en 2018 est aujourd'hui rejetée par Google, Yahoo et Microsoft. Roter régulièrement force à remplacer les algorithmes hérités.

Hygiène cryptographique. NIST SP 800-57 Part 1 Rev. 5 recommande des cryptopériodes courtes pour les clés de signature : 1 à 2 ans maximum, plus court pour les environnements sensibles. Sans rotation régulière, la première rotation forcée tourne au drame.

DKIM2, en cours de standardisation à l'IETF, ajoute une protection contre le replay mais ne supprime pas le besoin de rotation. Voir DKIM2 et la protection contre le replay.

Stratégie de rotation DKIM : sélecteurs parallèles plutôt que remplacement direct

Principe fondamental : ne jamais remplacer une clé DKIM par overwrite. Toujours publier un nouveau sélecteur DKIM en parallèle, basculer la signature DKIM, puis retirer l'ancien sélecteur après une période de grâce.

Trois facteurs imposent la coexistence temporaire :

• Cache DNS résolveur. La valeur TXT d'un sélecteur est mise en cache pendant le TTL (1 heure à 24 heures). Certains résolveurs servent encore l'ancienne valeur.
• Retry SMTP. Un MTA destinataire conserve un message en queue jusqu'à 5 jours. Si le sélecteur est retiré trop tôt, la revérification échoue.
• Audit forensique. Les équipes sécurité doivent vérifier la signature d'un message reçu 2 semaines plus tôt. Un sélecteur retiré rend cette vérification impossible.

Convention de nommage : sélecteurs datés trimestriels. Exemple : s2026-q1 pour janvier à mars 2026, s2026-q2 pour la suivante. Cette convention évite les collisions avec les sélecteurs vendor (selector1 Microsoft 365, google Google Workspace, mte1 SendGrid). Les deux sélecteurs coexistent pendant la fenêtre de chevauchement :

s2025-q4._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
s2026-q1._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Durée de chevauchement minimale : 7 jours côté propagation, 30 jours côté retrait pour couvrir les retries SMTP les plus longs.

Calendrier opérationnel de la rotation DKIM

La timeline ci-dessous condense la procédure de rotation DKIM sans downtime en 6 jalons J-7 à J+30. Chaque étape est idempotente : un rollback partiel reste possible tant que l'ancien sélecteur DKIM reste publié.

Générer la paire de clés DKIM avec openssl

Quatre commandes openssl couvrent la totalité des besoins pour générer une paire de clés DKIM (privée + publique). Toutes ont été testées avec OpenSSL 3.x.

RSA 2048 : génération de la clé privée.

openssl genrsa -out dkim_private.pem 2048

RSA 2048 : extraction de la clé publique base64 pour le DNS.

openssl rsa -in dkim_private.pem -pubout -outform der | openssl base64 -A

Le résultat est la valeur à coller dans le tag p= du TXT record.

Ed25519 : génération de la clé privée.

openssl genpkey -algorithm ed25519 -out dkim_ed25519_private.pem

Ed25519 : extraction de la clé publique base64 (32 octets).

openssl pkey -in dkim_ed25519_private.pem -pubout -outform der | tail -c 32 | openssl base64

Le tail -c 32 est nécessaire : openssl émet un header ASN.1 de 12 octets devant les 32 octets effectifs de la clé Ed25519, header que la RFC 8463 exige de retirer pour le p=.

Tableau comparatif des trois options réalistes en 2026 :

Recommandation 2026 : RSA 2048 seul pour la compatibilité maximale, ou double-publish RSA 2048 plus Ed25519 pour bénéficier de la signature Ed25519 chez les récepteurs compatibles. Éviter RSA 4096 : la clé publique dépasse 255 caractères et impose un découpage TXT en plusieurs chaînes, fragile à chaque édition DNS. Pour le détail comparatif, voir RSA vs Ed25519 pour DKIM.

Gestion de la clé privée DKIM

La clé privée DKIM est un secret cryptographique au même titre qu'une clé TLS. Trois modèles de stockage acceptables existent en production pour héberger une clé privée DKIM.

KMS managé (AWS KMS asymmetric keys, GCP Cloud KMS, Azure Key Vault). La clé est générée et reste dans le HSM. Le MTA appelle l'API KMS pour signer chaque message. La clé privée n'est jamais exposée en mémoire applicative, la rotation est tracée par IAM. Inconvénient : 5 à 20 ms de latence par appel.

HashiCorp Vault Transit. Équivalent self-hosted du KMS managé. La clé reste dans le backend Transit, le MTA signe via l'API. Path conventionnel : secret/dkim/captaindns/s2026-q1.

Fichier PEM chiffré au repos. Minimum acceptable pour les petites infrastructures. La clé est stockée sur le serveur d'envoi dans un volume chiffré (LUKS, encrypted EBS), permissions 0600, propriété opendkim:opendkim. Déploiement via Ansible Vault, Sealed Secrets Kubernetes ou SOPS.

Anti-patterns à proscrire :

• Clé privée commitée dans le repo Git, même en branche privée. Git conserve l'historique pour toujours.
• Clé privée passée en variable d'environnement non chiffrée (DKIM_PRIVATE_KEY=...) dans un docker-compose ou un fichier .env.
• Clé privée stockée dans un secret manager partagé avec des comptes de service inutiles (principe de moindre privilège violé).

Au moment de la rotation, ne pas oublier de roter aussi les accès KMS. Un ex-employé qui a eu accès en lecture à secret/dkim/captaindns/s2025-q4 ne doit pas conserver cet accès même si la clé n'est plus active : elle reste valide pour signer des messages antidatés.

Automatiser la rotation DKIM par cron

Une rotation manuelle est oubliée à la première vacance d'équipe. Automatiser la rotation DKIM devient indispensable au-delà de 3 à 4 domaines actifs. Découper le job en 3 étapes idempotentes :

1. Generate : produire la paire et stocker la clé privée en KMS.
2. Publish-DNS : appeler l'API du provider DNS pour ajouter le TXT.
3. Switch-signing : reconfigurer le MTA après la fenêtre J-7.

Squelette bash Generate + Publish-DNS sur Cloudflare :

#!/bin/bash
set -euo pipefail

SELECTOR="s$(date +%Y-q%q)"
DOMAIN="captaindns.com"
ZONE_ID="${CLOUDFLARE_ZONE_ID}"

# Generate RSA 2048
openssl genrsa -out "dkim_${SELECTOR}.pem" 2048
PUB=$(openssl rsa -in "dkim_${SELECTOR}.pem" -pubout -outform der | openssl base64 -A)

# Store private key in Vault
vault kv put "secret/dkim/${DOMAIN}/${SELECTOR}" private_key=@"dkim_${SELECTOR}.pem"

# Publish DNS via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"TXT\",\"name\":\"${SELECTOR}._domainkey\",\"content\":\"v=DKIM1; k=rsa; p=${PUB}\",\"ttl\":3600}"

# Verify publication
sleep 30
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"

Cron : 0 3 1 */6 * (tous les 6 mois, le 1er du mois à 3h UTC) déclenche la phase Generate plus Publish-DNS, suivi 7 jours plus tard d'un second cron qui exécute Switch-signing.

Intégrations vendor :

• AWS SES BYODKIM : commande aws sesv2 put-email-identity-dkim-signing-attributes avec le couple DomainSigningSelector et DomainSigningPrivateKey encodé en base64.
• Microsoft 365 : Rotate-DkimSigningConfig -Identity captaindns.com -KeySize 2048 (Exchange Online PowerShell). La rotation génère un nouveau sélecteur côté Microsoft mais oblige à publier le nouveau CNAME dans le DNS pour activer la nouvelle clé.
• SendGrid : la rotation est gérée via l'API POST /whitelabel/domains/{id}/validate après ajout du nouveau CNAME chez le provider DNS.

Alerting recommandé : déclencher une alerte si le taux de dkim=fail dans les rapports DMARC aggregate dépasse 1 % pendant la fenêtre J+0 à J+7. La validation post-rotation s'exécute en mode programmatique via l'API DKIM Record Check.

Pièges courants quand vous renouvelez une clé DKIM

Cinq pièges récurrents remontent des tickets support et des threads reddit r/sysadmin chaque fois qu'une équipe renouvelle une clé DKIM en urgence.

TTL trop long sur l'ancien sélecteur. Un TTL de 24 heures empêche la propagation rapide d'une correction. Baisser le TTL à 300 secondes 48 heures avant J+0, puis le remonter à 3600 secondes après J+7.

Sélecteur avec tirets mal placés. Certains parseurs DKIM stricts rejettent un sélecteur contenant un tiret en première ou dernière position. Préférer s2026q1 à -s2026-q1-.

DMARC en alignement strict (adkim=s). Une signature d=mail.captaindns.com est rejetée pour un From: contact@captaindns.com. Vérifier que le domaine d= de la nouvelle clé reste identique à celui de l'ancienne. Pour diagnostiquer les rejets côté DKIM voir causes des dkim=fail et corrections.

Clé publique cachée côté SaaS. Mailchimp, ActiveCampaign et d'autres publient un CNAME au lieu d'un TXT direct. La rotation est gérée par le provider : valider que le CNAME pointe vers la nouvelle target après la rotation déclarée.

Tag s= mal configuré. Le tag optionnel s=email restreint l'usage de la clé à la signature de messages email. Une clé publiée avec s=* ou sans tag accepte tous les services. Pour le détail, voir le tag s= dans l'enregistrement DKIM.

Exemple de TXT mal encodé (base64 wrap multi-ligne avec retour à la ligne brut, rejeté par certains résolveurs) :

s2026-q1._domainkey.captaindns.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
                                                "p=MIIBIjANBgkqhkiG\n"
                                                "9w0BAQEFAAOC..." )

Exemple correct (chaîne unique ou split propre par chunks de 255 caractères) :

s2026-q1._domainkey.captaindns.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

FAQ

Validez votre prochaine rotation de clé DKIM : utilisez le DKIM Record Check pour vérifier que votre nouveau sélecteur DKIM est publié et que la signature DKIM est correcte avant et après la bascule. Renouveler une clé DKIM sans downtime suppose une discipline calendaire J-7/J+30 et une instrumentation DMARC sérieuse : référez-vous au guide DMARCbis pour outiller la surveillance aggregate (rua). Pour anticiper les évolutions du protocole, voir aussi DKIM2 et la protection contre le replay.

Sources

• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463 - A New Cryptographic Signature Method for DKIM (Ed25519)
• NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management
• Microsoft Learn - Rotate-DkimSigningConfig
• AWS - Configure BYODKIM in Amazon SES
• Google - Email sender guidelines (DKIM, DMARC, list-unsubscribe)