Vous venez de recevoir un e‑mail dont l’expéditeur semble être… vous ? Pas de panique : dans la très grande majorité des cas, il s’agit d’une usurpation (« spoofing »). Voici comment le reconnaître, le signaler et empêcher sa répétition, tout en sécurisant votre compte.
Vue d’ensemble de la question
Un utilisateur reçoit un message de phishing dont le champ De/From affiche sa propre adresse. Il craint que son compte ait été piraté ou cloné et ne sait pas comment déclarer ce message ni quelles mesures prendre. Cette situation est fréquente : le protocole e‑mail autorise techniquement n’importe quel expéditeur à écrire ce qu’il veut dans l’entête From, d’où l’importance des mécanismes modernes d’authentification (SPF, DKIM, DMARC) et des bonnes pratiques de sécurité côté utilisateur.
Résumé actionnable en 30 secondes
- Ne répondez pas, n’ouvrez aucune pièce jointe et ne cliquez sur aucun lien.
- Signalez le message via le bouton « Signaler phishing / spam » de votre webmail. Si absent, transférez-le comme pièce jointe au service « abuse / spam » de votre fournisseur.
- Changez votre mot de passe par précaution et activez la double authentification (2FA).
- Vérifiez vos connexions récentes, règles de transfert et délégations de boîte.
- Si vous possédez un domaine : mettez en place ou durcissez SPF + DKIM + DMARC (politique « reject » à terme).
Tableau récapitulatif : problèmes, explications et actions
| Problème | Explication | Actions recommandées |
|---|---|---|
| Usurpation d’adresse (« spoofing ») | Des expéditeurs malveillants peuvent placer librement n’importe quelle adresse dans From. Cela n’implique pas un piratage du compte. | Aucun signe direct de compromission. Restez vigilant, poursuivez les vérifications de sécurité. |
| Signalement difficile (l’e‑mail semble venir de soi‑même) | Certains clients bloquent la fonction de report quand l’expéditeur est « vous ». D’autres l’acceptent. | Utilisez « Signaler » s’il existe ; sinon transférez comme pièce jointe au service sécurité (abuse@…, spam@…). |
| Protection du domaine | Une mauvaise configuration ou l’absence de SPF, DKIM, DMARC facilite l’usurpation. | Vérifier et déployer : • SPF : liste des serveurs autorisés. • DKIM : signature cryptographique. • DMARC : politique à appliquer si SPF/DKIM échouent. |
| Sécurité du compte | Le message provient souvent d’un spoofing simple, mais il faut écarter toute compromission. | Changer le mot de passe (fort et unique), activer 2FA, examiner connexions/appareils et règles de boîte. |
| Formation et prévention | Comprendre le spoofing rassure et réduit les clics malveillants. | Ne jamais répondre ni cliquer ; vérifier l’URL réelle des liens ; sensibiliser les équipes. |
Pourquoi le champ « From » peut mentir
Historiquement, SMTP n’exige aucune preuve que l’expéditeur possède l’adresse indiquée. Un attaquant peut donc écrire :From: "Vous" <prenom.nom@exemple.com>
et poster le message via un serveur quelconque. Sur le serveur du destinataire, ce sera le rôle des mécanismes d’authentification de trancher :
- SPF (Sender Policy Framework) : vérifie si l’IP émettrice est autorisée pour le domaine du Mail From / Return‑Path.
- DKIM (DomainKeys Identified Mail) : vérifie une signature cryptographique liée au domaine.
- DMARC : impose une politique (none/quarantine/reject) si SPF et/ou DKIM échouent, avec notion d’alignement entre le
From:visible et le domaine authentifié.
Diagnostiquer : indices visuels et lecture des en‑têtes
Indices visibles
- Ton pressant, menaces (ex. « Nous avons piraté votre appareil »), demandes d’argent en cryptomonnaie.
- Liens masqués par des ancres génériques (« Cliquez ici »), erreurs de grammaire.
- Adresse « Répondre à » (Reply‑To) différente de votre adresse.
Lire les en‑têtes bruts
Ouvrez le message et affichez l’original (Afficher l’original / Afficher la source du message). Repérez :
Return-Path: bounce@malware.tld
From: "Moi" <vous@exemple.com>
Reply-To: arnaque@evil.tld
Authentication-Results: votre-serveur.tld;
spf=fail (ip 203.0.113.5 not permitted) smtp.mailfrom=malware.tld;
dkim=none (no signature);
dmarc=fail (p=reject) header.from=exemple.com
À retenir : si spf=fail et dkim=none ou non aligné, et dmarc=fail, il s’agit quasi sûrement d’un spoofing. Un spf=pass + dkim=pass alignés avec votre domaine doit vous alerter davantage : poursuivez les vérifications de compte.
Procédure immédiate de réponse
- Signaler le message : utilisez le bouton « Signaler phishing / spam ». Si indisponible, transférez comme pièce jointe (
.eml) à l’équipe sécurité ou à l’adresse « abuse@… / spam@… » du fournisseur. - Conserver une preuve : sauvegardez le message complet (
.eml) et une capture des en‑têtes si vous devez remonter l’incident. - Changer le mot de passe de la messagerie et des services majeurs associés (compte Microsoft/Google, compte de votre hébergeur, etc.). Utilisez un gestionnaire de mots de passe.
- Activer la 2FA (application d’authentification ou clé de sécurité) et désactiver les méthodes obsolètes (SMS si possible, mots de passe d’application inutilisés).
- Revue de sécurité :
- Connexions et appareils récents ; déconnectez les sessions inconnues.
- Filtres, règles de transfert, réponses automatiques, délégations de boîte.
- Applications tierces OAuth ayant accès à la messagerie ; révoquez ce qui est superflu.
- Adresse e‑mail/numéro de récupération : mettez‑les à jour.
Comment signaler selon votre fournisseur
Les menus varient, mais l’idée reste la même : signaler comme phishing/spam et, si nécessaire, transférer comme pièce jointe.
| Fournisseur | Signaler | Prouver (en‑têtes) | Transférer comme pièce jointe |
|---|---|---|---|
| Gmail | Icône « Plus » → Signaler le phishing | Icône « Plus » → Afficher l’original | Sélectionnez le message → Transférer comme pièce jointe |
| Outlook.com / Microsoft 365 | Junk → Phishing | Afficher les détails du message / Afficher la source | Transférer en pièce jointe (client de bureau : nouveau message > glisser le mail) |
| Yahoo Mail | Menu → Signaler → Phishing | Menu → Afficher l’en‑tête complet | Utiliser Transférer comme pièce jointe si disponible |
| iCloud / Apple Mail | Menu → Déplacer vers Indésirables / Signaler le phishing | Menu → Afficher les en‑têtes | Glisser le message dans un nouveau courriel pour l’attacher |
Différencier spoofing et compromission effective
| Indice | Plausible spoofing | Plausible compromission |
|---|---|---|
| Activité de connexion | Rien d’inhabituel | IP/appareils inconnus, connexions récentes anormales |
| Dossier « Envoyés » | Vide (le message n’a pas été envoyé depuis votre compte) | Messages inconnus dans « Envoyés » |
| Règles/Transferts | Rien d’ajouté | Nouvelles règles suspectes (ex. transfert silencieux) |
| En‑têtes d’authentification | spf=fail, dkim=none, dmarc=fail | spf=pass et/ou dkim=pass alignés sur votre domaine |
Protéger votre domaine : SPF, DKIM, DMARC sans douleur
Si vous gérez votre propre domaine (ex. exemple.com), déployer correctement ces enregistrements DNS réduit drastiquement l’usurpation. Procédez par étapes pour éviter les faux positifs.
Plan de déploiement recommandé
- Phase 1 — Observation (J0 → J7) : publier DMARC en
p=noneafin de recevoir des rapports (rua). Exemple :_dmarc.exemple.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemple.com; fo=1; aspf=s; adkim=s" - Phase 2 — Quarantaine (J8 → J21) : corrigez les sources d’envoi, ajoutez DMARC
p=quarantine; pct=50, puis 100 % si tout est propre. - Phase 3 — Rejet (J22 → J35) : durcissez en
p=reject, maintenezaspf=setadkim=s(alignement strict), ajoutezsp=rejectpour les sous‑domaines si nécessaire.
Exemples d’enregistrements (à adapter)
| Mécanisme | Objectif | Type DNS | Exemple de valeur | Conseils |
|---|---|---|---|---|
| SPF | Autoriser les IP/plateformes légitimes | TXT | v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all | Un seul enregistrement SPF par domaine. Respecter la limite de 10 recherches DNS (include, a, mx, ptr, exists, redirect). |
| DKIM | Signer cryptographiquement | TXT sous un sélecteur | selector1._domainkey.exemple.com TXT "k=rsa; p=MIIBI…" | Générer des clés robustes (2048 bits). Faire tourner les sélecteurs régulièrement. |
| DMARC | Politique d’alignement et de traitement | TXT | _dmarc.exemple.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@exemple.com; ruf=mailto:dmarc@exemple.com; fo=1; aspf=s; adkim=s; sp=reject; pct=100" | Monter progressivement vers reject. Utiliser rua (agrégés) et ruf (forensiques) si acceptable. |
Pièges courants à éviter
- Publier plusieurs enregistrements SPF : il n’en faut qu’un (mergez les valeurs).
- Oublier une plateforme d’envoi (outil marketing, CRM, helpdesk) : ajoutez son
include:SPF et signez DKIM depuis cette plateforme. - Alignement DMARC non respecté : vérifiez que le domaine visible dans
From:est le même que celui passé par SPF ou DKIM. - Rester indéfiniment en
p=none: sans montée en puissance, votre domaine restera spoofable.
Créer des règles pour limiter les « From: moi »
En plus de l’anti‑spam natif, vous pouvez créer des règles côté client/serveur (à manier avec précaution pour éviter les faux positifs) :
- Idée de règle : si From = mon‑adresse@mon‑domaine.tld ET l’entête
Authentication-Resultscontientspf=failOUdkim=fail/noneALORS déplacer en Courrier indésirable. - Outlook (bureau) : créer une règle « avec des mots spécifiques dans l’entête du message » ; chercher
spf=failet votre domaine dansheader.from. - Gmail : utilisez les filtres avancés (texte : has:header n’est pas accessible, mais vous pouvez filtrer sur From: = vous + mots du sujet/du corps utilisés dans la campagne de phishing).
Attention : les transferts manuels ou certains relais peuvent casser SPF (faux négatifs). DKIM et DMARC aident à limiter ce problème.
Gérer un afflux de messages usurpés
- Durcir DMARC vers
p=quarantinepuisp=rejecten s’appuyant sur les rapportsrua. - Activer les politiques anti‑phishing de votre plateforme (ex. détection d’usurpation interne, « spoof intelligence », bannière d’avertissement).
- Former les utilisateurs (ateliers courts, scénarios réalistes, faux e‑mails d’entraînement) : le meilleur filtre reste l’utilisateur informé.
- Surveiller les taux de faux positifs et ajuster les exceptions (ex. serveurs légitimes envoi‑app).
Modèles prêts à l’emploi
Message de signalement (utilisateur → support interne)
Objet : Signalement phishing – usurpation de mon adresse
Bonjour,
Je viens de recevoir un e-mail dont le champ « From » affiche mon adresse.
Je n’ai pas envoyé ce message. Vous trouverez en pièce jointe le .eml et les en‑têtes.
Merci de vérifier et de bloquer la campagne.
Cordialement,Réponse type (support → utilisateur)
Bonjour,
Merci pour votre signalement. Après analyse des en‑têtes, il s’agit d’un spoofing (SPF/DKIM non conformes).
Nous avons ajusté nos filtres. Changez votre mot de passe et activez la 2FA si ce n’est déjà fait.
Restez vigilant et continuez de signaler les messages suspects.
Cordialement,FAQ pratique
Pourquoi les filtres n’ont-ils pas bloqué le message ?
Les filtres antispam combinent plusieurs signaux. En l’absence ou mauvaise configuration de SPF/DKIM/DMARC, certains spoofings passent encore, surtout si le contenu est court ou peu typique.
Puis‑je empêcher totalement le spoofing ?
Pas à 100 %. En revanche, SPF + DKIM + DMARC en p=reject (avec alignement strict) réduisent drastiquement l’impact ; et la formation des utilisateurs complète la défense.
Que faire si je reçois beaucoup de ces e‑mails ?
Durcissez DMARC, renforcez l’antiphishing, ajoutez des règles spécifiques « From: moi », monitorez les rapports DMARC pour identifier les sources illégitimes.
Le message contient un ancien mot de passe « me concernant » : est‑ce que j’ai été piraté ?
Probablement non : les campagnes de « sextorsion » réutilisent des données issues d’anciennes fuites. Changez tous les mots de passe réutilisés et activez la 2FA.
Dois‑je prévenir mes contacts que “mon adresse a été piratée” ?
Seulement si vous constatez des envois réels depuis votre compte (éléments « Envoyés », connexions suspectes). Sinon, expliquez calmement qu’il s’agit d’une usurpation d’adresse.
Les bounces (“mail delivery failed”) reviennent à mon adresse : normal ?
Oui, si l’attaquant a mis votre adresse dans Return‑Path ou From. DMARC en reject et une bonne réputation d’expéditeur réduisent ces retours.
Checklist de sécurité (à cocher)
- [ ] Signaler le message comme phishing / spam
- [ ] Sauvegarder le message en
.emlsi besoin - [ ] Changer le mot de passe et activer la 2FA
- [ ] Revoir connexions récentes et déconnecter les sessions inconnues
- [ ] Vérifier filtres, transferts, délégations
- [ ] Révoquer l’accès OAuth des apps inutiles
- [ ] Mettre à jour e‑mail et numéro de récupération
- [ ] Si propriétaire de domaine : vérifier SPF, DKIM, DMARC et planifier le passage à
p=reject
Glossaire express
- From : champ affiché à l’utilisateur indiquant l’expéditeur ; non fiable sans authentification.
- Return‑Path / Mail From : adresse de rebond technique utilisée par SPF.
- SPF : autorise les serveurs émetteurs pour un domaine.
- DKIM : signature cryptographique prouvant que le message n’a pas été altéré et qu’il provient d’un domaine détenteur de la clé.
- DMARC : politique qui impose l’alignement et dicte quoi faire en cas d’échec (aucune action, quarantaine, rejet).
- Alignement : concordance entre le domaine visible dans
Fromet le domaine validé par SPF/DKIM.
Exemples concrets d’analyse d’en‑têtes
Cas A : spoofing évident
Authentication-Results: mx.exemple.com;
spf=fail smtp.mailfrom=evil.tld;
dkim=none;
dmarc=fail (p=reject) header.from=exemple.com
Received: from 203.0.113.5 (unknown)Lecture : tout échoue, c’est une usurpation claire. Signaler et supprimer.
Cas B : possible compromission
Authentication-Results: mx.exemple.com;
spf=pass smtp.mailfrom=exemple.com;
dkim=pass header.d=exemple.com;
dmarc=pass (p=reject) header.from=exemple.com
Received: from o365-outbound.mail (ip autorisée)Lecture : le message semble réellement être parti d’une plateforme autorisée de votre domaine, avec signature valide. Vérifiez de toute urgence votre boîte (« Envoyés », connexions, règles) et changez votre mot de passe.
Bonnes pratiques durables
- Gestionnaire de mots de passe pour éviter la réutilisation.
- 2FA partout (clé FIDO2 ou application d’authentification).
- Hygiène e‑mail : désabonnement des listes inutiles (moins de bruit = plus de vigilance).
- Sensibilisation régulière (campagnes de phishing simulé, quiz trimestriels).
- Surveillance DMARC : lecture des rapports
rua, traitement des sources inconnues.
Mythes vs réalités
| Mythe | Réalité |
|---|---|
| « Si l’e‑mail affiche mon adresse, mon compte est piraté. » | La plupart du temps, c’est uniquement du spoofing (From falsifié). |
| « DMARC en p=none suffit. » | Non : p=none ne bloque rien. Il faut évoluer vers quarantine puis reject. |
| « SPF pass garantit l’authenticité. » | Non : SPF peut passer via des relayeurs ; seule la combinaison SPF/DKIM alignés & DMARC est fiable. |
| « Les bannières d’avertissement suffisent. » | Utile mais insuffisant : il faut des contrôles techniques + formation. |
En résumé
Recevoir un e‑mail « de soi‑même » est presque toujours le signe d’une usurpation d’adresse, pas d’un piratage. La riposte adéquate consiste à (1) signaler le message et ne pas interagir, (2) sécuriser son compte par précaution (mot de passe, 2FA, contrôle des sessions et des règles), et (3) protéger son domaine via un trio SPF + DKIM + DMARC correctement configuré et progressivement durci jusqu’à p=reject. En combinant ces approches techniques et humaines, vous réduirez très fortement l’impact de ces tentatives d’usurpation.