Vérifier l'expéditeur d'un mail : ce qui prouve quoi
Une adresse d'expéditeur ne prouve ni l'authenticité ni la fraude. Ce que le nom affiché, la mention via, SPF, DKIM et DMARC permettent réellement de conclure.
Mis à jour le 5 août 2026En résumé
L'adresse affichée dans le champ « De » ne permet pas de conclure : c'est du texte écrit par l'expéditeur, et beaucoup d'organisations envoient leurs messages depuis un domaine qui ne porte pas leur nom. Ce qui se vérifie, c'est le nom affiché face à l'adresse réelle, puis la ligne Authentication-Results de l'en-tête. La seule vérification qui tranche reste d'ouvrir vous-même le site ou l'application concernée.
Coller une adresse d'expéditeur dans un moteur de recherche ne donnera pas de verdict, parce que cette adresse n'en est pas un. Le champ « De » d'un e-mail est du texte écrit par celui qui envoie le message, et, dans l'autre sens, beaucoup d'organisations font partir leurs courriers depuis un domaine qui ne porte pas leur nom : une adresse impeccable ne prouve pas l'authenticité, un domaine inconnu ne prouve pas la fraude.
Ce qui se vérifie se lit du plus superficiel au plus solide, et seul le dernier niveau tranche : le nom affiché face à l'adresse réelle, la ligne d'authentification écrite par votre propre fournisseur de messagerie, puis ce que vous constatez en ouvrant vous-même le site ou l'application concernée. Cette dernière vérification se fait très bien depuis un téléphone ; la lecture de l'en-tête technique, elle, est facultative.
Pourquoi l'adresse affichée ne décide de rien
Elle n'est pas contrôlée par le transport
Un e-mail voyage en deux parties distinctes. L'enveloppe SMTP, décrite par la RFC 5321, contient l'adresse d'origine à laquelle renvoyer les erreurs et les adresses de destination ; elle sert à l'acheminement. Le contenu, décrit par la RFC 5322, contient l'en-tête et le corps du message, et c'est là que se trouve le champ « De » que votre messagerie vous affiche. La RFC 5321 pose la séparation noir sur blanc : « The SMTP envelope is sent as a series of SMTP protocol units [...] The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. »
Autrement dit, l'adresse que vous lisez appartient au colis, pas au circuit postal. Rien dans le protocole n'impose qu'elle corresponde à l'adresse de l'enveloppe, et une campagne frauduleuse a tout intérêt à y recopier l'adresse officielle exacte de la marque imitée, puisque c'est précisément ce que le destinataire va regarder.
Un domaine inconnu n'est pas une preuve
Une organisation peut parfaitement faire partir ses messages depuis le domaine d'un prestataire d'envoi. Le domaine qui envoie n'est alors pas celui de la marque, et ce décalage est assez courant pour que Gmail le documente et l'affiche. D'après l'aide de Gmail, la mention « via » suivie d'un nom de site apparaît dans deux cas : quand le domaine depuis lequel le message a été envoyé ne correspond pas au domaine de l'adresse indiquée dans le champ « De », et quand le message a été adressé à un groupe Google depuis un domaine dont les règles DMARC mentionnent p=reject ou p=quarantine. Dans les deux cas, c'est une information de circuit, pas une accusation : le « via » peut même apparaître alors que le domaine correspond parfaitement.
LA RÈGLE QUI CIRCULE ET QUI EST FAUSSE
« Le domaine n'est pas celui de la marque, donc c'est une arnaque » : cette règle produit des faux positifs (des messages authentiques routés par un prestataire) et, surtout, des faux négatifs. Un message frauduleux qui affiche l'adresse officielle exacte passe le test haut la main.
Il faut aussi accepter une limite structurelle : il n'existe pas d'annuaire public des adresses e-mail. Un numéro de téléphone appartient à une tranche attribuée à un opérateur, information publique que l'on peut recouper. Une adresse e-mail, non. De l'extérieur, personne ne peut affirmer qu'une adresse « existe » ou « est officielle » à partir de la seule chaîne de caractères.
Ce que vous pouvez réellement lire
1. Le nom affiché contre l'adresse réelle
La RFC 5322 décrit une boîte aux lettres comme la combinaison d'un nom d'affichage optionnel et de l'adresse proprement dite placée entre chevrons. Le nom d'affichage est du texte libre : il peut contenir un nom de marque, un numéro de dossier, ou une autre adresse e-mail entièrement différente de l'adresse réelle.
C'est le point aveugle du mobile, où l'interface montre le nom et masque l'adresse. Dépliez la zone d'en-tête du message pour faire apparaître l'adresse complète. Si le nom affiché est lui-même écrit sous la forme d'une adresse et que l'adresse réelle en diffère, la contradiction est un vrai signal : c'est l'un des rares indices que l'expéditeur affiché fournit par lui-même.
2. L'en-tête complet et sa ligne d'authentification
Sur ordinateur, la procédure est documentée par les éditeurs :
| Messagerie | Chemin officiel |
|---|---|
| Gmail (navigateur) | Ouvrir le message, puis « À côté de Répondre, cliquez sur Plus puis Afficher l'original » |
| Outlook classique | Double-cliquer sur le message pour l'ouvrir hors du volet de lecture, puis « Fichier > Propriétés », zone « En-têtes Internet » |
| Nouveau Outlook et Outlook sur le web | « Plus d'actions » en haut du message, puis « Afficher > les détails du message » |
Ces procédures officielles décrivent la version navigateur ou bureau. Pour lire un en-tête technique, ouvrez donc votre messagerie sur un ordinateur plutôt que dans l'application du téléphone.
Dans cet en-tête, cherchez la ligne Authentication-Results. Elle est normalisée par la RFC 8601 et contient les résultats des vérifications, sous une forme du type spf=pass smtp.mailfrom=... et dkim=pass header.d=.... Une précaution s'impose : cette ligne peut être fabriquée par l'expéditeur. La RFC 8601 prévoit d'ailleurs que le serveur destinataire supprime toute occurrence prétendant avoir été ajoutée à l'intérieur de sa propre zone de confiance sans venir d'un serveur de confiance (section 5), et signale le risque d'usurpation de l'identifiant du service (section 7.1). Ne lisez donc que la ligne du haut, celle qui porte le nom de votre propre fournisseur de messagerie.
Ce que SPF, DKIM et DMARC prouvent exactement
| Mécanisme | Ce qu'il authentifie | Ce qu'il ne dit pas |
|---|---|---|
| SPF (RFC 7208) | Que le serveur émetteur est autorisé à envoyer pour le domaine de l'enveloppe (MAIL FROM) ou pour le nom annoncé en HELO | Il ne regarde pas le champ « De » que vous voyez. La RFC déconseille explicitement de tester d'autres identités que celles-là |
| DKIM (RFC 6376) | Qu'un domaine signataire (d=) assume la responsabilité du message et que le contenu signé n'a pas été modifié depuis la signature | « The signing identity specified by a DKIM signature is not required to match an address in any particular header field » (section 1.2) |
| DMARC (RFC 7489) | Que le domaine du champ « De » soit aligné avec un identifiant authentifié par SPF ou DKIM | « the authentication mechanisms employed by DMARC authenticate only a DNS domain and do not authenticate the local-part of any email address identifier found in a message, nor do they validate the legitimacy of message content » (section 4.2) |
DMARC est donc le seul des trois qui relie l'authentification à ce que vous voyez à l'écran. Il ne relie rien de plus. Un escroc qui enregistre son propre domaine et y configure SPF, DKIM et DMARC obtient exactement les mêmes « pass » qu'une grande entreprise, pour ses propres messages envoyés depuis son propre domaine.
Cette configuration n'a d'ailleurs plus rien d'exceptionnel : depuis le 1er février 2024, Google impose aux expéditeurs de plus de 5 000 messages par jour vers des comptes Gmail de configurer SPF, DKIM et DMARC. Pour tout expéditeur qui envoie en volume, l'authentification est donc devenue une condition d'accès à la boîte de réception, pas un signe distinctif.
L'inverse mérite la même prudence. Un message parfaitement légitime peut échouer à ces contrôles quand il a transité par une liste de diffusion ou une redirection automatique. Le problème est suffisamment connu pour avoir sa propre publication à l'IETF : la RFC 7960, « Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows ».
Vous avez une adresse précise sous les yeux
Trois questions se posent, dans cet ordre, et aucune ne porte sur la chaîne de caractères elle-même.
- Le message vous demande-t-il quelque chose ? Un paiement, une saisie de coordonnées bancaires, une reconnexion, l'ouverture d'une pièce jointe, une réponse, un appel vers un numéro fourni dans le message. Un message qui ne demande rien n'est pas pour autant sans effet : certaines campagnes commencent par une simple notification, dont le seul rôle est de rendre crédible l'appel ou le message qui suivra.
- Cette même adresse figure-t-elle dans des messages que vous avez reçus avant cet événement ? Cherchez-la dans votre propre boîte. C'est un indice de continuité, pas une preuve : une adresse authentique recopiée dans un faux message donnera le même résultat.
- L'information annoncée existe-t-elle dans votre compte ? C'est la seule question qui donne une réponse.
LE POINT DE BASCULE
Il n'existe pas de vérification de l'expéditeur qui autorise à cliquer. La vérification consiste à ne pas passer par le message du tout.
La vérification qui tranche vraiment
Fermez le message. Ouvrez l'application que vous avez déjà installée, ou tapez vous-même l'adresse du site dans votre navigateur, sans passer par le lien reçu. Une facture, un remboursement, un colis : si l'information est réelle, vous la retrouverez sans le message. Et si vous la retrouvez, cela ne valide pas le message pour autant : traitez l'affaire depuis votre espace client, pas depuis le mail. Si vous devez appeler, utilisez le numéro qui figure sur une facture papier ou au dos de votre carte bancaire, jamais celui du message. La recommandation officielle de cybermalveillance.gouv.fr va dans ce sens : aller « directement sur le site de l'organisme en question par un lien favori que vous aurez vous-même créé ».
Pour les messages sur lesquels on nous interroge le plus, nous avons détaillé compte par compte ce qui se vérifie :
- Mail EDF de régularisation, d'impayé ou de trop-perçu
- Avis de remboursement DGFIP reçu par mail ou par SMS
- Compte Amazon bloqué pour activité suspecte
- SMS de colis La Poste et lien sms.laposte.fr
- Faux mails d'opérateurs SFR, Orange, Bouygues et Free
Quand le doute porte sur le lien plutôt que sur l'expéditeur, la logique est la même mais les indices diffèrent : voir notre guide pour reconnaître un site frauduleux.
Signaler, gratuitement
Le signalement ne dépend pas de votre certitude : il est utile même en cas de doute.
- Signal Spam (signal-spam.fr), plateforme associative qui collecte les signalements d'e-mails et les transmet aux autorités publiques et aux professionnels habilités à agir.
- 33700 pour un SMS ou un MMS suspect, par transfert du message. Gratuit, d'après la fiche hameçonnage de cybermalveillance.gouv.fr.
- cybermalveillance.gouv.fr pour le diagnostic de votre situation et les conseils officiels.
- Info Escroqueries : 0 805 805 817, gratuit, du lundi au vendredi de 9h à 18h30, d'après cette même fiche.
- Amazon indique publiquement demander le transfert des messages frauduleux à l'adresse
[email protected], y compris si vous n'êtes pas client.
Les étapes complètes sont décrites dans notre guide pour signaler une arnaque. Si vous avez déjà cliqué et saisi des informations, la priorité n'est plus la vérification de l'expéditeur : voir que faire si vous êtes victime.
Sources
Documents et pages consultés le 5 août 2026.
- RFC 5321, « Simple Mail Transfer Protocol », section 2.3.1 (enveloppe et contenu) : rfc-editor.org
- RFC 5322, « Internet Message Format », sections 3.4 et 3.6.2 (nom d'affichage, champ From) : datatracker.ietf.org
- RFC 7208, « Sender Policy Framework (SPF) », sections 2.2, 2.3 et 2.4 (identités HELO et MAIL FROM) : datatracker.ietf.org
- RFC 6376, « DomainKeys Identified Mail (DKIM) Signatures », sections 1.2 et 2.5 : datatracker.ietf.org
- RFC 7489, « Domain-based Message Authentication, Reporting, and Conformance (DMARC) », sections 3.1 et 4.2 : datatracker.ietf.org
- RFC 8601, « Message Header Field for Indicating Message Authentication Status », sections 2.2, 5 et 7.1 : rfc-editor.org
- RFC 7960, « Interoperability Issues between DMARC and Indirect Email Flows », septembre 2016 : rfc-editor.org
- Aide Gmail, « Informations supplémentaires affichées à côté du nom de l'expéditeur » : support.google.com
- Aide Gmail, « Utiliser l'en-tête complet d'un message pour savoir d'où il provient » : support.google.com
- Aide Gmail, « Consignes pour les expéditeurs de messages » (exigences SPF, DKIM et DMARC depuis le 1er février 2024) : support.google.com
- Microsoft Support, « Afficher les en-têtes de message Internet dans Outlook » : support.microsoft.com
- Cybermalveillance.gouv.fr, fiche réflexe « Hameçonnage / phishing » : cybermalveillance.gouv.fr
- Signal Spam, présentation de l'association et du traitement des signalements : signal-spam.fr
- About Amazon France, « Six conseils pratiques pour se protéger des tentatives d'arnaques par usurpation d'identité », 18 juillet 2025 : aboutamazon.fr
Questions fréquentes
Non. Le champ « De » fait partie du contenu du message, pas du transport : rien dans le protocole SMTP n'impose qu'il corresponde à l'expéditeur réel. Une campagne frauduleuse a tout intérêt à y inscrire l'adresse officielle exacte, puisque c'est ce que le destinataire regarde.
Arnaques concernées par ce guide
Rédaction
L'équipe éditoriale de iarnaque.fr recherche, vérifie et documente les arnaques circulant en France pour protéger les consommateurs.