# Ce que « dkim=pass » signifie vraiment

> Vous avez lu les en-têtes et l’authentification de l’e-mail est passée.

Canonical: https://vetthisvendor.com/fr/guide/dkim-pass-does-not-mean-genuine
Published: 2026-08-12. Updated: 2026-08-12.
Author: Jose Pollman, VetThisVendor.

Si vous avez ouvert les en-têtes d’un e-mail, y avez trouvé une ligne comme
`dkim=pass header.d=supplier.com; spf=pass; dmarc=pass` et voulez savoir si cela signifie
que le message est sûr : **cela signifie que le message vient bien de ce domaine, et rien de
plus.** Cela ne dit rien de l’authenticité de la facture, de l’exactitude des coordonnées
bancaires, ni du fait que la personne qui écrivait était votre fournisseur.

Ce n’est pas un détail technique. La fraude à la facture la plus coûteuse d’Europe passe les
trois contrôles, à chaque fois, parce qu’elle est envoyée depuis la vraie boîte du
fournisseur. Si vous avez une demande de paiement entre les mains, la
[vérification de courriel fournisseur](/fr/tools/supplier-email-check) lit le message et
indique lesquelles de ces choses elle a réellement pu établir — et, tout aussi important,
lesquelles elle n’a pas pu établir.

## Ce que demande réellement chacun des trois contrôles

On les écrit souvent comme s’ils formaient un seul verdict. Ce sont trois questions
différentes, et aucune n’est « cet e-mail est-il honnête ».

**SPF** demande si le serveur qui a délivré le message fait partie de ceux que le
propriétaire du domaine a déclarés autorisés à envoyer. C’est une question sur une adresse
IP. Elle ne dit rien de qui a écrit le message, ni de ce qu’il contient.

**DKIM** demande si une signature cryptographique portant sur des parties du message
correspond à une clé publique publiée dans le DNS du domaine. Une réussite signifie que
quelqu’un détenant la clé privée de ce domaine a signé ces parties, et qu’elles n’ont pas
été modifiées depuis. C’est le plus fort des trois — et c’est une affirmation sur le
*domaine*, pas sur l’*intention de l’expéditeur*.

**DMARC** demande si SPF ou DKIM a réussi pour un domaine correspondant à l’adresse `From:`
que voit le lecteur, et indique aux serveurs destinataires quoi faire quand ni l’un ni
l’autre n’y parvient. Il rattache les deux autres à l’expéditeur visible. C’est réellement
utile, et ce n’est toujours pas une affirmation sur le contenu.

Donc `dkim=pass header.d=supplier.com` signifie : c’est bien le domaine de votre
fournisseur. Ce qui est exactement ce à quoi vous vous attendriez si un criminel était
installé dans la boîte de votre fournisseur.

## La fraude qui passe tous les contrôles

La version de la fraude à la facture qui réussit n’est pas un domaine sosie. C’est un **vrai
e-mail depuis la vraie boîte du vrai fournisseur**, atteinte le plus souvent avec un mot de
passe issu d’une fuite sans rapport, ou via une page d’hameçonnage remplie des semaines plus
tôt.

Tout s’authentifie, parce que tout est authentique :

- le message est signé par le domaine du fournisseur lui-même, donc DKIM passe ;
- il part du prestataire de messagerie du fournisseur lui-même, donc SPF passe ;
- l’adresse `From:` correspond, donc DMARC passe ;
- l’historique du fil est réel, car c’est le vrai fil.

Seules les coordonnées bancaires sont nouvelles. L’authentification des e-mails n’a aucun
avis sur les coordonnées bancaires.

C’est pourquoi « l’e-mail s’est authentifié » n’est jamais une raison de payer, et pourquoi
chaque résultat sur ce site — y compris ceux qui ne relèvent rien — se termine par la même
phrase sur l’appel à un numéro que vous aviez déjà. Un déroulé plus long figure dans
[un fournisseur demande par e-mail de changer ses coordonnées bancaires](/fr/guide/supplier-changed-bank-details).

## Qui a écrit la ligne que vous lisez

Il y a un second piège, et il est facile à manquer.

`Authentication-Results:` est un en-tête écrit par **le serveur de messagerie qui a reçu le
message** — votre propre prestataire, en général. Quand vous y lisez `dkim=pass`, vous lisez
le verdict de quelqu’un d’autre, consigné au moment de la remise. C’est normalement digne de
confiance, parce que c’est votre propre prestataire qui l’a écrit.

Mais les en-têtes ne sont que du texte. Si le bloc vous a été transféré, collé dans un
ticket, recopié depuis la capture d’écran d’un collègue, ou remis par celui-là même qui
demande à être payé, alors la ligne qui dit `dkim=pass` est une affirmation de celui qui a
produit le texte — et n’importe qui peut la taper. Aucune cryptographie ne protège un
en-tête affirmant que la cryptographie a réussi.

La distinction honnête sépare trois situations très différentes :

| Ce dont vous disposez | Ce qui peut être établi |
|---|---|
| Le message brut complet, signature comprise | La signature peut être **vérifiée maintenant**, par vous |
| Seulement les en-têtes, avec une ligne `Authentication-Results` | Le **verdict consigné par le serveur destinataire**, pris sur parole |
| Ni l’un ni l’autre — seulement l’e-mail visible | Uniquement ce que le domaine publie : SPF, DMARC, MX |

Tout outil qui vous montre le deuxième en l’appelant le premier vous dit une chose que vous
n’avez aucun moyen de contrôler. La
[vérification de courriel fournisseur](/fr/tools/supplier-email-check) indique lequel des
trois elle effectue, et n’en promeut jamais un au rang d’un autre : un `dkim=pass` figurant
dans un bloc d’en-têtes collé est rapporté comme le verdict du destinataire, dans ces
termes-là.

## Quand un « fail » compte plus qu’un « pass »

Une réussite est une preuve faible. Un **échec est une preuve forte**, et mérite qu’on
s’arrête.

Si la vérification DKIM s’exécute réellement et contredit — la signature ne correspond pas
au contenu —, le message a été modifié après signature, ou n’a jamais été signé par ce
domaine. Si DMARC est réglé sur `p=reject` et que le message a malgré tout échoué, il
n’aurait pas dû être remis.

Une asymétrie mérite d’être retenue : *impossible à vérifier* n’est pas la même chose
qu’*échoué*. Une requête DNS injoignable, une clé révoquée, une signature expirée ou une
signature ne couvrant qu’une partie du corps signifient toutes que le calcul n’a pas pu
aller à son terme. Ce n’est pas un constat à charge contre l’expéditeur, et un outil qui le
présente ainsi gâche le seul signal sur lequel il aurait valu la peine d’agir.

## Que faire d’un message dont vous n’êtes pas sûr

1. **N’y répondez pas.** Si la boîte est compromise, votre réponse part chez l’attaquant, et
   une règle de boîte peut la cacher au vrai fournisseur.
2. **Appelez le fournisseur** sur un numéro tiré d’une ancienne facture, de votre logiciel
   comptable, ou de son site web auquel vous avez accédé en tapant l’adresse vous-même.
3. **Vérifiez les identifiants séparément** — le numéro de TVA, l’inscription au registre
   des sociétés et, pour un fournisseur polonais, si le compte est
   [sur la liste blanche](/fr/guide/polish-white-list). Le
   [vérificateur de factures](/fr/tools/invoice-checker) fait tout cela à partir du document
   lui-même.
4. **Traitez le changement de coordonnées bancaires comme l’événement**, et non l’e-mail qui
   l’entoure. C’est cela qui mérite un appel, quoi que disent les en-têtes.

## Ce que cela ne peut pas vous dire

L’authentification des e-mails contrôle le *canal*, pas l’*affirmation*. Elle ne peut pas
vous dire que la marchandise a été commandée, que le montant est juste, que la personne qui
écrit travaille encore là, ni que le compte appartient à votre fournisseur. La Pologne est
le seul pays de l’UE à publier une réponse à cette dernière question, raison pour laquelle
[la liste blanche](/fr/guide/polish-white-list) vaut d’être utilisée là où elle s’applique.

Partout ailleurs, le contrôle qui attrape cela est un appel de vive voix à un numéro que
vous aviez déjà.