DKIM : signer les messages pour prouver leur origine et leur intégrité

DKIM (DomainKeys Identified Mail) permet à un domaine de signer les messages qu'il émet. Le serveur émetteur calcule une signature sur une partie des en-têtes et sur le corps du message, puis l'insère dans un en-tête DKIM-Signature:. Le serveur de réception récupère la clé publique correspondante dans le DNS et vérifie que le message n'a pas été altéré en transit et qu'il a bien été signé par le domaine annoncé. DKIM est normalisé par la RFC 6376.

Comment fonctionne une signature#

L'en-tête DKIM-Signature: contient plusieurs étiquettes, dont :

• d= : le domaine signataire, celui qui engage sa réputation ;
• s= : le sélecteur, nom qui permet de publier plusieurs clés pour un même domaine ;
• h= : la liste des en-têtes couverts par la signature (From, Subject, Date, To, Message-ID…) ;
• bh= : le condensat du corps du message ;
• b= : la signature elle-même ;
• a= : l'algorithme, en pratique rsa-sha256 ou ed25519-sha256 ;
• c= : la canonicalisation (simple ou relaxed) appliquée aux en-têtes et au corps, qui tolère ou non des modifications mineures d'espaces et de casse.

Le vérificateur interroge le nom <sélecteur>._domainkey.<domaine>, reconstruit le condensat et compare. Si tout concorde, le résultat est dkim=pass et l'identité d= est considérée comme authentifiée. Contrairement à SPF, DKIM survit aux transferts et aux réexpéditions tant que le message n'est pas modifié.

L'enregistrement DNS#

La clé publique se publie dans un enregistrement TXT sous le label _domainkey :

s2026a._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

Étiquettes utiles :

• v=DKIM1 : version, facultative mais recommandée en première position ;
• k=rsa ou k=ed25519 : type de clé ;
• p= : la clé publique en base64 ; une valeur vide signifie que la clé est révoquée ;
• t=y : mode test, à ne pas laisser en production ;
• t=s : interdit l'usage de la clé pour des sous-domaines du d=.

Une clé RSA de 2048 bits produit une chaîne de plus de 255 caractères : elle doit être découpée en plusieurs chaînes dans le même enregistrement, ce que la plupart des interfaces DNS font automatiquement mais pas toutes. Les clés Ed25519 (RFC 8463) sont beaucoup plus courtes, mais tous les vérificateurs ne les acceptent pas encore ; la pratique courante est de signer deux fois, RSA et Ed25519.

Déployer DKIM#

1. Générer une paire de clés RSA 2048 bits (1024 bits est aujourd'hui considéré comme insuffisant par la plupart des routeurs).
2. Choisir un sélecteur explicite, par exemple daté (s2026a), pour faciliter la rotation.
3. Publier la clé publique en DNS, attendre la propagation, puis activer la signature sur le serveur ou la plateforme d'envoi.
4. Pour un prestataire externe, le schéma habituel consiste à publier un CNAME de <sélecteur>._domainkey.votre-domaine vers un nom hébergé par le prestataire, qui gère alors la clé et sa rotation. Dans ce cas, le d= reste votre domaine, ce qui est indispensable pour l'alignement DMARC.
5. Signer au minimum From, To, Subject, Date, Message-ID, MIME-Version et Content-Type. Signer aussi, en les listant une fois de plus dans h=, les en-têtes qui ne doivent pas être ajoutés après coup (oversigning), notamment From et Subject.
6. Faire tourner les clés régulièrement, idéalement tous les six à douze mois : publier la nouvelle clé sous un nouveau sélecteur, basculer la signature, conserver l'ancienne clé publiée quelques jours pour les messages encore en transit, puis la retirer.

Erreurs fréquentes#

• Clé de 1024 bits ou moins : signature acceptée mais dévalorisée, voire ignorée.
• d= sur le domaine du prestataire : la signature est valide mais ne s'aligne pas avec votre From:, donc ne compte pas pour DMARC.
• Signer trop peu d'en-têtes : un message peut être rejoué avec un Subject ou un To modifié tout en gardant une signature valide.
• Étiquette l= (longueur du corps signée) : permet d'ajouter du contenu après la partie signée. À proscrire.
• Modification après signature : pied de page ajouté par une passerelle, réécriture de liens, conversion de l'encodage. La signature casse et seul ARC peut en conserver la trace.
• Rejeu DKIM : un message légitimement signé, par exemple envoyé depuis un compte d'essai d'une plateforme partagée, est renvoyé massivement à d'autres destinataires avec sa signature intacte. Signer Date et Message-ID, limiter la durée de validité avec x=, et surveiller les comptes d'envoi réduisent le risque. Les travaux DKIM2 visent à traiter ce problème à la racine.
• Clé jamais retirée : un sélecteur abandonné mais toujours publié reste utilisable si la clé privée a fuité.

Ce que SenderRadar en montre#

SenderRadar liste les sélecteurs DKIM observés pour un domaine, le type et la taille de chaque clé, la présence éventuelle d'un mode test, les délégations par CNAME vers des prestataires, et signale les clés faibles ou révoquées. SenderRadar s'appuie sur sa propre base d'analyse pour indiquer, de façon progressive, l'évolution des sélecteurs dans le temps.

Références#

• RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures
• RFC 8463 – A New Cryptographic Signature Method for DKIM (Ed25519)
• RFC 8301 – Cryptographic Algorithm and Key Usage Update to DKIM
• Groupe de travail DKIM de l'IETF