Résumé

  • Un succès DKIM valide des éléments canonisés sous la clé désignée par s= et le domaine d=. Il n'autorise pas automatiquement le domaine visible dans From.
  • RFC 9989 ajoute l'alignement DMARC pour le domaine auteur ; même ce succès ne garantit ni vérité, ni innocuité, ni fraîcheur, ni autorisation métier.

Le bon résultat appliqué au mauvais nom

Le vérificateur a trouvé la clé DNS de l'attaquant, recalculé les empreintes et validé la signature. Le moteur de décision a ensuite transformé « signature valide de receipt-alert.example » en « expéditeur bancaire vérifié ». Aucun protocole n'avait fourni ce pont.

DKIM permet à un domaine de revendiquer une responsabilité de transmission. d= nomme ce domaine, s= le sélecteur de clé, h= les champs signés, bh= l'empreinte du corps canonisé et b= la signature. From doit figurer dans h=, ce qui empêche sa modification après signature. Cela ne prouve pas que le domaine d= possède le domaine écrit dans From : un attaquant peut signer fidèlement une fausse adresse.

La vérification doit conserver ses étapes. Le corps est canonisé, son empreinte comparée à bh=, puis les en-têtes sélectionnés et le champ DKIM sont vérifiés avec la clé DNS. Si bh= ne correspond pas, toute la signature échoue, même si le calcul sur les en-têtes aurait réussi.

La canonisation n'évalue pas le sens

Les modes simple et relaxed tolèrent des transformations différentes. Une variation d'espacement sans effet pour le lecteur peut casser un mode ; une instruction malveillante inchangée peut passer les deux. Il faut donc journaliser l'entrée canonisée, pas promettre que « le message » entier est intact.

Le tag facultatif l= limite la couverture à un préfixe du corps canonisé. Du texte peut être ajouté après cette limite sans modifier bh=. Cette possibilité aidait certains intermédiaires à ajouter un pied de page, mais elle ouvre aussi une zone non signée ; avec l=0, tout le corps l'est. Une interface ne doit pas poser un badge unique sur le corps complet si seule sa première partie est couverte.

L'alignement appartient à DMARC

RFC 9989, publiée en mai 2026, remplace RFC 7489. Elle compare le domaine auteur RFC5322.From à un identifiant DKIM ou SPF authentifié. L'alignement DKIM strict exige l'identité des domaines ; le mode relaxed accepte le même domaine organisationnel.

Notre message passe donc DKIM pour le domaine de l'attaquant et échoue l'alignement avec bank.example. Les deux résultats doivent rester visibles. RFC 9989 rappelle aussi qu'un succès DMARC valide l'usage autorisé du domaine auteur, sans déclarer le message bon, sûr ou souhaitable.

Le SMTP envelope, l'identifiant SPF, d=, l'éventuel i=, From et le compte SMTP authentifié répondent à des questions différentes. Authentication-Results peut les transporter, mais uniquement depuis un producteur reconnu par le domaine administratif destinataire. Un champ externe imitant ce résultat doit être supprimé ou isolé.

Mutation, médiation et rejeu

Une liste peut ajouter un pied de page, réencoder le corps ou modifier le sujet et casser DKIM/DMARC. ARC transporte les évaluations observées avant ces transformations, mais le destinataire doit encore décider s'il fait confiance au signataire ARC et à la chaîne.

Les tags temporels n'empêchent pas davantage le rejeu. RFC 6376 précise que x= n'est pas une défense anti-rejeu. Un message intact peut être distribué de nouveau. Identifiant de transaction, état du processus et confirmation humaine restent nécessaires pour une action irréversible.

Le test décisif signe un message hostile avec un domaine contrôlé tout en affichant un autre domaine From : DKIM doit passer et l'alignement échouer. Il faut ensuite tester un contenu hostile mais aligné, un suffixe après l=, les champs signés et non signés, plusieurs signatures, la rotation du sélecteur, un faux Authentication-Results, une transformation de liste et le rejeu.