DKIM (DomainKeys Identified Mail)
Référence RFC 6376, complétée par la RFC 8301 (rsa-sha256 obligatoire, clés de 1 024 à 4 096 bits) et la RFC 8463 (ed25519-sha256) : syntaxe de la signature et de l’enregistrement de clé, signification des balises, canonicalisation, périmètre de signature et risques.
DKIM (RFC 6376) est un protocole d’authentification fondé sur le contenu : un domaine prend la responsabilité d’un message en ajoutant un en-tête DKIM-Signature qui contient des empreintes cryptographiques d’une sélection d’en-têtes et du corps, vérifiables grâce à une clé publique publiée dans le DNS. Une signature valide prouve que le contenu signé n’a pas été modifié après la signature et rattache le message au domaine d=, l’identifiant que DMARC compare au domaine From (voir DMARC). Contrairement à SPF, DKIM résiste au transfert tant que le contenu signé n’est pas modifié.
L’en-tête DKIM-Signature : référence des balises
| Balise | Obligatoire ? | Signification |
|---|---|---|
v= |
Obligatoire | Version ; doit valoir 1. |
a= |
Obligatoire | Algorithme de signature : rsa-sha256 ou ed25519-sha256 (RFC 8463). rsa-sha1 NE DOIT PAS être utilisé (RFC 8301). |
b= |
Obligatoire | La signature elle-même, en base64. Les espaces sont ignorées. |
bh= |
Obligatoire | Empreinte du corps canonicalisé (limité par l= s’il est présent), en base64. |
c= |
Facultatif | Canonicalisation, sous la forme header/body ; chacune vaut simple ou relaxed. Par défaut simple/simple ; c=relaxed seul signifie relaxed/simple. |
d= |
Obligatoire | SDID — le domaine signataire qui revendique la responsabilité ; il doit avoir un enregistrement de clé dans le DNS. C’est l’identifiant utilisé pour l’alignement DMARC. |
h= |
Obligatoire | Liste ordonnée, séparée par des deux-points, des champs d’en-tête signés. Elle ne doit pas être vide et ne doit pas inclure la DKIM-Signature en cours de création. Elle peut citer plusieurs fois le même nom et citer des champs inexistants (voir la sursignature ci-dessous). |
i= |
Facultatif | AUID — identité de l’agent ou de l’utilisateur : une adresse dont le domaine doit être égal à d= ou en être un sous-domaine (strictement égal si l’enregistrement de clé porte l’indicateur t=s). Par défaut : @ suivi de la valeur de d=. |
l= |
Facultatif | Longueur du corps : nombre d’octets du corps canonicalisé couverts par bh=. Par défaut : le corps entier. Risque de sécurité : voir ci-dessous. |
q= |
Facultatif | Méthode de récupération de la clé ; seule dns/txt est définie (par défaut). |
s= |
Obligatoire | Sélecteur — désigne la clé au sein du domaine (voir l’enregistrement de clé ci-dessous). |
t= |
Recommandé | Horodatage de la signature, en secondes Unix. Les vérificateurs peuvent ignorer les signatures dont l’horodatage est dans le futur. |
x= |
Recommandé | Horodatage d’expiration absolu ; doit être > t=. Ne protège pas contre le rejeu. |
z= |
Facultatif | Copie de diagnostic de champs d’en-tête sélectionnés au moment de la signature, séparés par ` |
Périmètre de signature : quels en-têtes signer
- Le champ From: DOIT être signé (c’est l’identité que DKIM a pour raison d’être de protéger, et le champ qu’évalue DMARC). En pratique, signez aussi Subject, Date, To, Reply-To, Message-ID, les en-têtes MIME et les champs List-*.
- Sursignature : si l’on cite un nom d’en-tête dans
h=une fois de plus qu’il n’apparaît, la signature couvre une instance « nulle » : tout ajout ultérieur de cet en-tête (par exemple un second From: ou Subject: injecté en aval) la casse. Recommandé pour From, Subject, To, Reply-To. - Les instances multiples d’un en-tête sont signées de bas en haut ; on ne peut pas signer une seule instance de façon sélective.
Le risque de la longueur de corps l=
l= permet à une signature de ne couvrir que les N premiers octets du corps, afin que des intermédiaires puissent ajouter du contenu (par exemple les pieds de page des listes de diffusion) sans la casser. Autrement dit, tout ce qui est ajouté au-delà des N octets n’est pas vérifié : un attaquant peut rejouer un message signé en y ajoutant du contenu malveillant, et la signature reste valide. Cette faille a été exploitée en pratique (« DKIM l= vulnerability », 2024). Ne signez pas avec l= ; les vérificateurs devraient traiter les signatures avec l= avec méfiance ou ignorer l’exemption qu’accorde cette balise.
L’enregistrement de clé DNS
Il est publié sous forme d’enregistrement TXT à l’adresse :
<selector>._domainkey.<domain>
| Balise | Par défaut | Signification |
|---|---|---|
v= |
DKIM1 |
Version ; si elle est présente, ce doit être la première balise. |
p= |
— (obligatoire) | La clé publique, en base64. Un p= vide signifie que la clé est révoquée. |
k= |
rsa |
Type de clé : rsa ou ed25519 (RFC 8463). |
h= |
toutes autorisées | Algorithmes d’empreinte acceptés, séparés par des deux-points (sha256 ; sha1 est obsolète). |
s= |
* |
Type de service : * ou email. |
t= |
aucun | Indicateurs : y = mode test ; s = le domaine de i= doit être strictement égal à d= (pas d’AUID de sous-domaine). |
n= |
vide | Notes lisibles destinées aux administrateurs. |
Exemple (Ed25519, tiré de la RFC 8463) :
brisbane._domainkey.football.example.com. IN TXT
"v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
Hygiène des sélecteurs : les sélecteurs permettent d’avoir plusieurs clés en même temps (par système, par fournisseur de services de messagerie (ESP), par date). Pour changer de clé, publiez un nouveau sélecteur, signez désormais avec ce sélecteur, puis révoquez l’ancienne clé. Ne réutilisez jamais un sélecteur avec une nouvelle clé : vous perdriez la possibilité de distinguer les anciens messages légitimement signés des falsifications.
Algorithmes et tailles de clé (RFC 8301, RFC 8463)
| Règle | Exigence |
|---|---|
| Algorithme de signature | Les signataires DOIVENT signer avec rsa-sha256. rsa-sha1 NE DOIT PAS être utilisé, ni pour signer ni pour vérifier (SHA-1 est obsolète). |
| Taille de clé RSA — signataires | DOIVENT utiliser des clés ≥ 1 024 bits ; 2 048 bits recommandés (référence opérationnelle actuelle). |
| Taille de clé RSA — vérificateurs | DOIVENT valider les clés de 1 024 à 4 096 bits ; PEUVENT prendre en charge des clés plus grandes. NE DOIVENT PAS considérer comme valides les signatures faites avec des clés < 1 024 bits. |
| Ed25519 (RFC 8463) | a=ed25519-sha256, enregistrement de clé k=ed25519, p= est la clé publique Ed25519 en base64. Les clés font 256 bits → la clé encodée ne fait que 44 octets et tient dans une seule chaîne TXT de 255 octets (les grandes clés RSA exigent souvent des chaînes découpées). |
| Double signature | Pour la compatibilité, signez à la fois avec rsa-sha256 et ed25519-sha256, en utilisant des sélecteurs différents (un enregistrement de clé par sélecteur). La prise en charge d’Ed25519 par les vérificateurs n’est toujours pas universelle. |
Canonicalisation
La canonicalisation normalise le contenu avant le calcul de l’empreinte afin de tolérer les réécritures en transit ; elle ne modifie pas le message transmis.
| Algorithme | Règles |
|---|---|
simple (en-tête) |
Les en-têtes sont pris exactement tels qu’ils apparaissent : toute modification casse la signature. |
relaxed (en-tête) |
Noms d’en-tête en minuscules ; lignes de continuation dépliées ; suites d’espaces réduites à une seule espace ; espaces de fin supprimées ; espaces autour des deux-points supprimées. |
simple (corps) |
Suppression des lignes vides de fin ; le corps doit se terminer par un seul CRLF. |
relaxed (corps) |
Suppression des espaces en fin de ligne ; suites d’espaces internes réduites à une seule espace ; suppression des lignes vides de fin ; CRLF final garanti. |
relaxed/relaxed est la valeur par défaut en pratique : la canonicalisation d’en-tête simple casse dès qu’un MTA replie ou remet en forme les en-têtes.
Comportement de la vérification
- Issues possibles pour chaque signature : SUCCESS, PERMFAIL (irrécupérable : signature incorrecte, clé révoquée ou trop courte, erreur de syntaxe), TEMPFAIL (passager : par exemple, délai d’attente DNS dépassé).
- Une signature en échec est traitée comme si le message n’était pas signé : un échec DKIM ne justifie pas en soi un rejet ; il ne fournit simplement aucun identifiant positif. (C’est DMARC qui transforme « aucun pass aligné » en politique.)
- Les signatures multiples sont évaluées indépendamment, chacune pour elle-même ; les vérificateurs poursuivent jusqu’à ce que l’une d’elles soit vérifiée. Un message peut légitimement porter des signatures du domaine de l’auteur et d’un ou plusieurs intermédiaires.
- Le résultat du vérificateur doit inclure le domaine
d=et le résultat, repris en aval dans l’en-tête Authentication-Results.
Remarques sur la délivrabilité
- Les fournisseurs de messagerie rattachent de plus en plus la réputation au domaine d= de DKIM, et privilégient DKIM plutôt que SPF pour l’alignement DMARC, l’inscription aux feedback loops et les outils destinés aux expéditeurs.
- Les exigences de Gmail et de Yahoo envers les expéditeurs de gros volumes rendent de fait obligatoire, à grande échelle, une signature DKIM alignée avec une clé ≥ 1 024 bits (2 048 bits recommandés).
- DKIM n’empêche pas le rejeu : un spammeur peut renvoyer tel quel un message légitimement signé à de nouveaux destinataires ; la signature reste valide, et c’est la réputation du domaine d= qui en fait les frais. Parades : expirations
x=courtes, sélecteurs par destinataire ou par flux, et surveillance.