SPF, DKIM, DMARC : ce qu'ils prouvent et ce qu'ils ne prouvent pas
Trois contrôles techniques qu'on vous conseille partout de vérifier, presque jamais en expliquant ce qu'ils disent réellement.
SPF vérifie que le serveur qui a envoyé le message figure sur la liste des serveurs autorisés par le domaine. DKIM vérifie une signature cryptographique apposée par le domaine, qui prouve en plus que le message n'a pas été modifié en route. DMARC lie les deux au domaine visible dans le champ « De » et indique ce que le domaine demande de faire en cas d'échec. Ensemble, ils prouvent que le message vient bien du domaine annoncé. Ils ne prouvent en aucun cas que ce domaine soit honnête : un fraudeur qui achète « impots-remboursement.xyz » peut le configurer parfaitement et passer les trois contrôles.
01Pourquoi la question se pose
- Ces trois sigles reviennent dans tous les conseils de sécurité, presque toujours sans explication de ce qu'ils garantissent exactement.
- Ils vivent dans les en-têtes du message, invisibles à la lecture normale, donc hors de portée sans une manipulation que peu de gens connaissent.
- Le contresens le plus répandu consiste à lire « authentifié » comme « fiable », alors que les deux notions sont indépendantes.
02Ce que chacun vérifie, en français
SPF : ce serveur avait-il le droit d'envoyer ?
Le propriétaire d'un domaine publie la liste des serveurs autorisés à envoyer en son nom. À réception, le serveur destinataire compare l'expéditeur réel à cette liste. Un échec signifie que le message vient d'un serveur non déclaré. Attention : un transfert d'email casse légitimement SPF, puisque c'est alors le serveur de la personne qui transfère qui envoie.
DKIM : la signature tient-elle ?
Le domaine expéditeur signe le message avec une clé privée ; le destinataire vérifie cette signature avec la clé publique publiée par le domaine. Un DKIM valide prouve deux choses : le message vient bien de ce domaine, et il n'a pas été altéré en chemin. Contrairement à SPF, la signature survit à un transfert.
DMARC : le domaine visible correspond-il, et que demande-t-il ?
DMARC exige que le domaine validé par SPF ou DKIM corresponde à celui affiché dans le champ « De ». C'est ce qu'on appelle l'alignement, et c'est le point réellement décisif : sans lui, un message pourrait passer SPF grâce à un domaine technique quelconque tout en affichant « De : impots.gouv.fr ». DMARC indique aussi la politique du domaine en cas d'échec : ne rien faire, mettre en quarantaine, ou rejeter.
Où lire le résultat
Dans Gmail, ouvrez le message, cliquez sur les trois points puis « Afficher l'original » : un tableau affiche SPF, DKIM et DMARC avec la mention PASS ou FAIL. Les autres clients exposent l'en-tête « Authentication-Results », qui contient la même information sous une forme plus brute.
03Ce que cette méthode ne dit pas
- Un domaine frauduleux correctement configuré passe les trois contrôles. L'authentification prouve l'origine, jamais l'intention.
- Un échec SPF sur un message transféré est normal et ne signifie rien : c'est le cas de tous les messages que vous vous transférez à vous-même.
- Beaucoup de domaines publient une politique DMARC permissive, qui n'empêche rien même en cas d'échec.
- Un message parfaitement authentifié envoyé depuis un compte réellement piraté est authentique au sens technique, et frauduleux au sens qui vous intéresse.
04Laisser l'analyse faire le reste
Les contrôles ci-dessus sont ceux que vous pouvez mener seul. Les suivants demandent de lire les en-têtes du message, ce qui se fait mal à la main et bien automatiquement.
- Il lit ces en-têtes pour vous et traduit PASS et FAIL en une phrase compréhensible.
- Il vérifie l'alignement DMARC, c'est-à-dire la correspondance avec le domaine que vous voyez, et pas seulement le résultat brut.
- Il distingue le cas du transfert, où un échec SPF est attendu, du cas d'une usurpation, et le dit explicitement au lieu de conclure au hasard.
- Il combine ce résultat avec l'examen du domaine lui-même et des liens, puisque l'authentification seule ne suffit pas à trancher.
Ce que vous obtenez : Le résultat de chaque contrôle en clair, ce qui a pu être vérifié sur votre message, et le poids de ce constat dans le verdict global.
Analyser un email gratuitement05Questions fréquentes
Un message qui passe SPF, DKIM et DMARC est-il sûr ?
Non, et c'est le malentendu le plus coûteux du sujet. Ces contrôles prouvent que le message vient du domaine qu'il affiche. Si ce domaine est « secure-ameli-remboursement.xyz », acheté et configuré par un escroc, tout sera vert. L'authentification se combine avec l'examen du domaine lui-même, pas l'inverse.
Pourquoi SPF échoue-t-il sur un message que j'ai transféré ?
Parce que le serveur qui l'envoie n'est plus celui du domaine d'origine, mais le vôtre. C'est le fonctionnement normal du transfert. C'est pour cette raison que notre analyse indique ce qu'elle a pu vérifier et ce qu'un transfert lui a fait perdre, plutôt que de compter cet échec comme un signal de fraude.
Comment transférer un message en conservant son authentification ?
En le transférant en pièce jointe plutôt que dans le corps, ce que la plupart des clients proposent sous le nom « Transférer en pièce jointe ». Le message original est alors encapsulé avec ses en-têtes intacts, et les contrôles d'origine redeviennent vérifiables.
06Pour aller plus loin
Les autres méthodes de vérification :
Si votre message se réclame d'une organisation précise, le dossier correspondant décrit son scénario en détail :