← RFC Reference

DKIM — DomainKeys Identified Mail

Pourquoi cette RFC existe

SPF vérifie qu'un message provient d'une adresse IP autorisée, mais ne dit rien sur le contenu du message. Un message pourrait réussir SPF, puis être modifié par un relais compromis. SPF se casse également lors du transfert de courrier, car l'IP d'envoi change.

DKIM résout les deux problèmes. En attachant une signature cryptographique au message lui-même, il fournit une assertion d'identité au niveau du domaine qui survit au transfert (la signature voyage avec le message) et garantit l'intégrité du contenu (toute modification invalide la signature).

RFC 6376, publiée en 2011, est la spécification DKIM actuelle. Elle a obsolété RFC 4871 et introduit des améliorations à la canonicalisation, à la gestion des clés et à la sémantique des signatures. Elle reste la base de l'authentification modernes des e-mails aux côtés de SPF et DMARC.

Comment ça marche

Signature (côté expéditeur)

1. Le serveur de courrier d'envoi (ou un agent de signature en amont) sélectionne les en-têtes et le corps à signer.
2. Il canonicalise le contenu sélectionné en utilisant des algorithmes simple ou relaxed pour normaliser les espaces et la casse.
3. Il calcule un hachage du corps canonicalisé, puis un hachage des en-têtes sélectionnés plus le hachage du corps.
4. Il signe le hachage d'en-tête en utilisant la clé privée du domaine (RSA ou Ed25519).
5. Il ajoute un en-tête DKIM-Signature au message contenant la signature, le domaine de signature (d=), le sélecteur (s=) et les métadonnées sur ce qui a été signé.

Vérification (côté récepteur)

1. Le récepteur extrait les valeurs d= (domaine) et s= (sélecteur) de l'en-tête DKIM-Signature.
2. Il interroge DNS pour la clé publique à <selector>._domainkey.<domain>.
3. Il re-canonicalise les en-têtes signés et le corps en utilisant le même algorithme spécifié dans la signature.
4. Il vérifie la signature par rapport à la clé publique. Si valide, le résultat est pass.

Exemple d'en-tête DKIM-Signature

Enregistrement de clé publique DNS

Détails techniques clés

Canonicalisation

Le courrier électronique peut être subtilement modifié en transit (espaces de fin supprimés, en-têtes re-pliés). La canonicalisation normalise le contenu avant le hachage de sorte que les modifications bénignes ne cassent pas la signature. Deux algorithmes sont disponibles, spécifiés séparément pour les en-têtes et le corps :

Le paramètre le plus courant est c=relaxed/relaxed, qui tolère les modifications en transit les plus courantes.

Types de clés

RFC 6376 a défini les signatures RSA. RFC 8463 a ensuite ajouté la prise en charge d'Ed25519. Les clés RSA doivent être d'au moins 2048 bits ; les clés de 1024 bits sont considérées comme faibles et sont rejetées par certains récepteurs. Les clés Ed25519 sont beaucoup plus petites (44 caractères dans DNS) et plus rapides à vérifier.

Sélecteurs

Le sélecteur (s= tag) permet à un domaine de publier plusieurs clés DKIM simultanément. Ceci est essentiel pour la rotation des clés : publiez une nouvelle clé sous un nouveau sélecteur, commencez à la signer, puis supprimez l'enregistrement DNS de l'ancien sélecteur après une période de transition.

La balise l= (limite de longueur du corps)

La balise optionnelle l= limite le nombre d'octets du corps qui sont signés. Cela était destiné à permettre aux listes de diffusion d'ajouter des pieds de page sans casser les signatures. En pratique, cela crée une vulnérabilité de sécurité : un attaquant peut ajouter du contenu malveillant après la partie signée. La plupart des implémentations conscientes de la sécurité évitent d'utiliser l=.

Signature d'en-tête

La balise h= liste les en-têtes inclus dans la signature. La meilleure pratique est de signer au minimum : From, To, Subject, Date, Message-ID, MIME-Version et Content-Type. L'en-tête From est requis par spécification. Signer un en-tête qui n'existe pas empêche qu'il soit ajouté après la signature (une mesure importante anti-rejeu).

Erreurs courantes

• Utiliser des clés RSA de 1024 bits : Celles-ci sont cryptographiquement faibles selon les normes modernes. Gmail et d'autres récepteurs importants peuvent rétrograder la confiance. Utilisez toujours RSA 2048 bits ou Ed25519.
• Ne pas faire pivoter les clés : Les clés privées DKIM doivent être pivotées périodiquement (tous les 6 à 12 mois). Les sélecteurs rendent ceci transparent — publiez la nouvelle clé, basculez la signature, retirez l'ancienne clé.
• Signer avec un domaine mal aligné : Pour que DMARC réussisse via DKIM, le domaine d= dans la signature doit s'aligner avec le domaine d'en-tête From: (correspondance exacte ou sous-domaine, selon la politique DMARC). Si votre ESP signe en tant que d=esp.com, l'alignement DMARC échoue à moins que vous ne configuriez une signature DKIM personnalisée.
• Sur-signature vs sous-signature d'en-têtes : Ne pas signer les en-têtes importants (comme Subject) permet aux attaquants de les modifier. Sur-signer les en-têtes que les intermédiaires ajoutent légitimement peut causer des faux échecs.
• Retard de propagation des enregistrements DNS : Après avoir publié une nouvelle clé DKIM, attendez la propagation DNS avant de signer avec le nouveau sélecteur. Une signature référençant une clé publique inexistante échouera la vérification.
• Utiliser la balise de longueur de corps l= : Cela permet au contenu non signé d'être ajouté au message. Évitez-le.

Impact sur la livraison

• Fondation pour DMARC : L'alignement DKIM est l'une des deux voies pour réussir DMARC (l'autre étant l'alignement SPF). Puisque DKIM survit au transfert tandis que SPF ne le fait pas, DKIM est souvent la voie d'authentification la plus fiable.
• Liaison de réputation : DKIM lie les messages au domaine de signature (via la balise d=). Les fournisseurs de boîtes aux lettres utilisent ceci pour construire la réputation du domaine. La signature DKIM cohérente construit une réputation positive au fil du temps.
• Requis par les principaux fournisseurs : Gmail et Yahoo exigent que soit SPF soit DKIM réussisse pour tous les expéditeurs. Les expéditeurs en masse (5 000+ messages/jour vers Gmail) doivent avoir à la fois SPF et DKIM réussis, plus une politique DMARC.
• Survit au transfert : Contrairement à SPF, une signature DKIM voyage avec le message. Lorsque le courrier est transféré via des listes de diffusion, des règles .forward ou des expansions d'alias, DKIM peut toujours valider (à condition que le système de transfert ne modifie pas le contenu signé). Ceci rend DKIM essentiel pour la compatibilité des listes de diffusion.
• Intégrité du contenu : Au-delà de l'authentification, DKIM prouve que le message n'a pas été falsifié en transit. Ceci protège contre les modifications man-in-the-middle et augmente la confiance du récepteur.

Related RFCs