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.
Référence8 min de lecture
À qui cela s’adresse Opérateurs ESP, Expéditeurs
S’applique aux expéditeurs, quelle que soit leur plateforme
SommaireSur cette page : 7 sections
DKIM permet à votre domaine de prendre la responsabilité d’un message en le signant. Les serveurs de réception vérifient la signature avec une clé publique que vous publiez dans le DNS. Une signature valide prouve que le contenu signé n’a pas été modifié après la signature, et elle rattache le message au domaine d=, l’identifiant dont DMARC vérifie l’alignement (voir DMARC). Contrairement à SPF, DKIM résiste au transfert, tant que le contenu signé n’est pas modifié.
DKIM est défini dans la RFC 6376. Il authentifie le contenu du message : le signataire ajoute un en-tête DKIM-Signature qui contient des empreintes cryptographiques d’une sélection d’en-têtes et du corps.
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 | L’empreinte du corps canonicalisé (limité par l= s’il est présent), en base64. |
c= |
Facultatif | Canonicalisation, écrite header/body, où chaque partie vaut simple ou relaxed. La valeur par défaut est simple/simple, et 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 | Une liste ordonnée des champs d’en-tête signés, séparés par des deux-points. 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 qui n’existent pas (voir la sursignature ci-dessous). |
i= |
Facultatif | AUID, l’identité de l’agent ou de l’utilisateur : une adresse dont le domaine doit être identique à d= ou en être un sous-domaine (strictement identique si l’enregistrement de clé porte l’indicateur t=s). La valeur par défaut est @ suivi de la valeur de d=. |
l= |
Facultatif | Longueur du corps : le nombre d’octets du corps canonicalisé couverts par bh=. La valeur par défaut est le corps entier. C’est un risque de sécurité ; voir ci-dessous. |
q= |
Facultatif | La méthode de récupération de la clé. Seule dns/txt est définie (la valeur par défaut). |
s= |
Obligatoire | Le sélecteur, qui désigne la clé au sein du domaine (voir l’enregistrement de clé ci-dessous). |
t= |
Recommandé | L’horodatage de la signature, en secondes Unix. Les vérificateurs peuvent ignorer les signatures dont l’horodatage est dans le futur. |
x= |
Recommandé | Un horodatage d’expiration absolu, qui doit être > t=. Ce n’est pas une protection contre le rejeu. |
z= |
Facultatif | Une copie 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 : citer un nom d’en-tête dans
h=une fois de plus que l’en-tête n’apparaît signe une instance « nulle » de cet en-tête. Tout en-tête de ce nom ajouté plus tard (par exemple un second From: ou Subject: inséré en cours de route) casse alors la signature. C’est recommandé pour From, Subject, To et Reply-To. - Lorsqu’un en-tête apparaît plusieurs fois, ses instances sont signées de bas en haut. Vous ne pouvez pas choisir de n’en signer qu’une seule.
Le risque de la balise de 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 casser la signature. Par conséquent, 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 à la fin, 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
La clé est publiée 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 | Les 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 signifie le mode test ; s signifie que le domaine de i= doit être strictement identique à d= (pas d’AUID sur des sous-domaines). |
n= |
vide | Des notes 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 vous permettent d’avoir plusieurs clés en même temps (par système, par ESP ou par date). Pour changer de clé, publiez un nouveau sélecteur, faites passer la signature sur ce sélecteur, puis révoquez l’ancienne clé. Ne réutilisez jamais un sélecteur avec une nouvelle clé, car 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é pour signer ni pour vérifier (SHA-1 est historique). |
| Taille de clé RSA pour les signataires | DOIVENT utiliser des clés de ≥ 1 024 bits. 2 048 bits sont recommandés (la référence opérationnelle actuelle). |
| Taille de clé RSA pour les vérificateurs | DOIVENT valider les clés de 1 024 à 4 096 bits, et PEUVENT prendre en charge des clés plus grandes. NE DOIVENT PAS considérer comme valides les signatures faites avec des clés de < 1 024 bits. |
| Ed25519 (RFC 8463) | a=ed25519-sha256, enregistrement de clé k=ed25519, et p= est la clé publique Ed25519 en base64. Les clés font 256 bits, donc 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 doivent souvent être réparties sur plusieurs chaînes). |
| 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 que la signature tolère les réécritures en transit. Elle ne modifie pas le message envoyé.
| Algorithme | Règles |
|---|---|
simple (en-tête) |
Les en-têtes sont pris exactement tels qu’ils apparaissent, donc toute modification casse la signature. |
relaxed (en-tête) |
Les noms d’en-tête sont mis en minuscules, les lignes de continuation sont dépliées, les suites d’espaces sont réduites à une seule espace, les espaces de fin sont supprimées, et les espaces autour des deux-points sont supprimées. |
simple (corps) |
Les lignes vides de fin sont supprimées, et le corps se termine par un seul CRLF. |
relaxed (corps) |
Les espaces en fin de ligne sont supprimées, les suites d’espaces à l’intérieur des lignes sont réduites à une seule espace, les lignes vides de fin sont supprimées, et le corps se termine par un CRLF. |
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
- Chaque signature a l’une de ces trois issues : SUCCESS, PERMFAIL (un échec irrécupérable : signature incorrecte, clé révoquée ou trop courte, erreur de syntaxe) ou TEMPFAIL (un échec passager, par exemple un 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 le rejet du message. Il ne fournit simplement aucun identifiant positif. C’est DMARC qui transforme l’absence de pass aligné en décision de politique.
- Les signatures multiples sont évaluées chacune séparément. Les vérificateurs continuent jusqu’à ce que l’une d’elles soit vérifiée. Un message peut légitimement porter une signature du domaine de l’auteur et des signatures d’un ou de plusieurs intermédiaires.
- Le résultat du vérificateur doit inclure le domaine
d=et le résultat. Il apparaît plus loin 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 préfèrent DKIM à 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é de ≥1 024 bits (2 048 recommandés).
- DKIM n’empêche pas le rejeu. Un spammeur peut renvoyer tel quel un message légitimement signé à de nouveaux destinataires, et la signature reste valide, ce qui consomme la réputation du domaine d=. Les parades sont des expirations
x=courtes, des sélecteurs par destinataire ou par flux, et la surveillance.
Voir aussi
Vérifier votre propre enregistrement
Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.
Dans ce thème
- SPF (Sender Policy Framework)
- Rotation des clés DKIM
- Attaques par rejeu DKIM
- DKIM2 (travaux de l’IETF en cours)