Choisissez un DKIM configuration de clé qui satisfait au protocole et fonctionne sur les systèmes qui envoient et reçoivent votre courrier. Un nombre plus élevé dans un panneau de contrôle ne constitue pas une décision de sécurité complète. Enregistrez l'algorithme, le type de clé et les preuves du destinataire, et séparez la force cryptographique de la livraison et alignement.
Utiliser les exigences RSA mises à jour
RFC 8301 met à jour l'ancienne spécification DKIM . Pour RSA, les clés de signature doivent comporter au moins 1 024 bits et les signataires doivent utiliser au moins 2 048 bits. Les vérificateurs doivent prendre en charge la validation avec des clés RSA de 1 024 à 4 096 bits, peuvent prendre en charge des clés plus grandes et ne doivent pas accepter les clés RSA inférieures à 1 024 bits comme valides. Un vérificateur peut toujours appliquer une politique locale basée sur la longueur de la clé.
La même RFC interdit rsa-sha1 pour la signature et la vérification. N'utilisez pas l'exemple SHA-1 d'un didacticiel obsolète comme recommandation de déploiement actuelle. Vérifiez le réel a= valeur dans un reçu DKIM-Signature et le type de clé atteint via son sélecteur, plutôt que de faire confiance aux souvenirs d'un administrateur concernant la configuration d'origine.
Le minimum et la recommandation répondent à des questions différentes. Une clé RSA de 1 024 bits peut atteindre le plancher spécifié sans répondre au choix recommandé le plus strict. Si l'organisation le conserve en raison d'une limitation documentée du système, enregistrez l'exception, le propriétaire et la condition de suppression. Ne décrivez pas cette exception comme la meilleure configuration universelle.
Vérifiez le service avant de générer des clés
Déterminez si le fournisseur gère les clés ou accepte le matériel fourni par le client. Amazon SES Easy DKIM documente un 2048 bits défaut; ce comportement du produit ne doit pas être généralisé à toutes les plateformes de messagerie. Certains services exposent uniquement un ensemble d'options pris en charge. Une clé de 4 096 bits générée est inutile si le signataire prévu ne peut pas la charger ou si le chemin d'approvisionnement DNS corrompt son enregistrement public.
RFC 8463 ajoute Ed25519-SHA256 : les signataires doivent l'implémenter et les vérificateurs doivent l'implémenter selon cette spécification. Ses tailles de clé ne sont pas numériquement comparables aux tailles RSA en tant que mesures de sécurité équivalentes. La prise en charge dans la norme ne démontre pas la prise en charge dans chaque interface de signataire, de récepteur ou d'administration déployée. Traitez une migration d'algorithme comme un changement de compatibilité avec des preuves explicites, et non comme un paramètre cosmétique. La section 6 RFC 8463 autorise les RSA et Ed25519 signatures pendant la transition ; ils doivent utiliser des sélecteurs distincts car chaque sélecteur identifie un seul enregistrement de clé. Vérifiez que le service de signature réel prend en charge cette approche avant de la planifier.
Construire une matrice de validation utile
Pour chaque itinéraire d'envoi, enregistrez le logiciel ou le fournisseur, l'algorithme, la taille de la clé le cas échéant, le sélecteur, la méthode de publication et un système de réception représentatif. Séparez trois tests : le signataire accepte la configuration, la clé publique est résolue intacte et un destinataire vérifie un message produit par ce signataire.
Une migration illustrative commence avec un ancien signataire de facturation RSA 1 024 bits. La cible proposée est RSA 2048 bits avec SHA-256. Publiez un nouveau sélecteur à l'aide du processus pris en charge par la plateforme, vérifiez la clé, envoyez-le via l'application de facturation et inspectez le résultat de la réception. Un test depuis la boîte mail d'un employé ne prouve pas que l'application de facturation a changé. Conservez l’ancienne dépendance uniquement pour la transition planifiée et le courrier retardé légitime, sauf indication contraire en réponse à l’incident.
Interpréter les échecs avec précision
Si un enregistrement plus volumineux ne parvient pas à être publié, étudiez l'interface DNS et la représentation TXT avant d'affaiblir la cryptographie. Si la vérification signale un algorithme non pris en charge, conservez ce résultat par rapport au récepteur réel et à la version du logiciel. Si DKIM réussit mais DMARC échoue, inspectez l’alignement de l’identité au lieu de modifier à nouveau la taille de la clé.
Documentez ce qui a été testé et ce qui reste inconnu. Un échantillon de récepteurs performants constitue une preuve opérationnelle utile et non une garantie couvrant l’ensemble d’Internet. Planifiez un examen lorsque le fournisseur, les conseils cryptographiques ou la population de destinataires importants changent. La décision est défendable lorsque ses exigences, ses limites de mise en œuvre et les résultats observés sont visibles.
Lecture connexe
Signatures RSA et Ed25519 DKIM : questions de déploiement et interopérabilité · Syntaxe de clé publique DKIM : identifiez les valeurs DNS tronquées ou mal formées.
Enregistrez la décision avant le déploiement
- Itinéraire actuel : application, propriétaire, domaine de signature, sélecteur et algorithme émis.
- Choix proposé : prise en charge de RSA-SHA256 à 2 048 bits ou plus lorsque cela est justifié, ou transition Ed25519 prise en charge.
- Preuve d'acceptation : le signataire charge la clé ; DNS le sert intact ; un système de réception approuvé vérifie un message provenant de cette application.
- Condition d'arrêt : algorithme non pris en charge, clé mal formée ou signature manquante. Résolvez ce défaut avant de retirer le sélecteur de travail.
- Exception : si vous conservez un RSA 1 024 bits, indiquez la limitation, le propriétaire du risque et la date de réévaluation.