Vous savez que DKIM signe vos emails. Mais que contient exactement cet en-tête DKIM-Signature ? Décortiquons chaque champ et suivons le processus de vérification de bout en bout.

Un en-tête DKIM réel, disséqué

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector2024;
  h=from:to:subject:date:mime-version:content-type;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  t=1714123456;
  b=dHJ5aW5nIHRvIHJlYWQgdGhpcyBzaWduYXR1cmU/IE5pY2Ug
    dHJ5IDspIFRoaXMgaXMganVzdCBhIGR1bW15IGV4YW1wbGU=

Chaque champ expliqué

v=1 : version

La version du protocole DKIM. Il n’existe qu’une seule version (1), définie par la RFC 6376. Ce champ est obligatoire.

a=rsa-sha256 : algorithme

Deux éléments combinés :

  • Cryptosystème : rsa (le plus courant) ou ed25519 (émergent, RFC 8463)
  • Fonction de hachage : sha256 (standard) ou sha1 (obsolète et vulnérable, à ne plus utiliser)
CombinaisonStatut
rsa-sha256Standard, recommandé
rsa-sha1Obsolète, certains fournisseurs le rejettent
ed25519-sha256Futur standard, support partiel

c=relaxed/relaxed : canonicalization

Définit comment le contenu est normalisé avant le calcul de la signature. Le format est headers/body :

Mode Simple :

  • Headers : aucune modification (sensible à la casse, aux espaces)
  • Body : supprime les lignes vides dupliquées en fin de message

Mode Relaxed :

  • Headers : convertit en minuscules, réduit les espaces multiples, supprime les espaces de fin de ligne
  • Body : idem + réduit les espaces multiples sur chaque ligne

En pratique, relaxed/relaxed est le choix standard car il tolère les modifications mineures effectuées par les serveurs relais (ajout d’espaces, changement de casse).

d=example.com : domaine signataire

Le domaine responsable de la signature. C’est ce domaine qui doit s’aligner avec le From: pour que DMARC valide l’alignement DKIM.

La clé publique sera cherchée dans la zone DNS de ce domaine.

s=selector2024 : sélecteur

Identifie quelle clé publique utiliser parmi celles publiées pour le domaine. Le record DNS complet sera :

selector2024._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Les sélecteurs permettent la rotation de clés sans interruption : publiez une nouvelle clé sur un nouveau sélecteur avant de basculer.

h=from:to:subject:date:... : headers signés

La liste des en-têtes inclus dans la signature. Seul From: est techniquement obligatoire, mais en pratique on inclut toujours :

  • from, to, subject, date (intégrité de base)
  • mime-version, content-type (structure du message)
  • message-id (unicité)
  • reply-to, cc (si présents)

Un en-tête non listé peut être modifié en transit sans casser la signature. Un en-tête listé qui change invalidera la signature.

bh=2jUSOH9N... : body hash

Le hash du corps du message canonicalisé, encodé en Base64. Calculé avec l’algorithme de hachage défini dans a= (sha256).

Ce champ permet de vérifier que le corps n’a pas été modifié indépendamment de la signature complète.

t=1714123456 : timestamp

L’horodatage Unix du moment de la signature. Permet au serveur destinataire de vérifier que la signature n’est pas trop ancienne (certains fournisseurs rejettent les signatures de plus de quelques jours).

b=dHJ5aW5n... : la signature

Le résultat final : la signature RSA (ou Ed25519) des headers canonicalisés + body hash, encodée en Base64. C’est cette valeur qui est déchiffrée avec la clé publique pour vérification.

Le processus de vérification, étape par étape

Quand un serveur destinataire reçoit un email avec une signature DKIM :

1. Validation du format Le serveur vérifie que tous les champs obligatoires sont présents (v, a, b, bh, d, h, s).

2. Canonicalization du body Le corps est normalisé selon l’algorithme défini dans c= (partie droite).

3. Calcul et comparaison du body hash Le hash du body canonicalisé est calculé avec sha256 et comparé à bh=.

  • Si mismatch → body hash did not verify → DKIM fail

4. Récupération de la clé publique Le serveur fait une requête DNS pour s=._domainkey.d= et récupère le record TXT contenant la clé publique.

5. Canonicalization des headers Les en-têtes listés dans h= sont canonicalisés selon l’algorithme défini dans c= (partie gauche).

6. Vérification de la signature La signature b= est déchiffrée avec la clé publique. Le résultat est comparé avec un hash calculé des headers canonicalisés + body hash.

  • Si match → DKIM pass
  • Si mismatch → signature did not verify → DKIM fail

Champs optionnels

ChampDescription
x=Expiration de la signature (timestamp Unix)
i=Identité de l’agent signataire (ex: user@example.com)
l=Nombre d’octets du body inclus dans le hash (dangereux, déconseillé)
q=dns/txtMéthode de récupération de la clé (seul dns/txt existe)
z=Copie des headers originaux (pour diagnostic)

Attention : le champ l= est une faille connue. S’il est présent, un attaquant peut ajouter du contenu en fin de message sans casser la signature. Ne l’utilisez jamais.

Comment analyser une signature DKIM

  • Header Analyzer : collez les en-têtes bruts pour une analyse visuelle de chaque champ DKIM
  • DKIM Checker : vérifiez le record DNS publié pour votre sélecteur
  • Audit gratuit : envoyez un test et voyez le résultat complet

Pour aller plus loin