Adresse IP et e-mails : origine, authentification et hameçonnage

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Un e-mail transporte, en plus de son texte, le journal de son propre voyage. Ce journal dit d'où il vient, mais en partie seulement, et à condition de savoir où s'arrête la zone de confiance. Voici ce que les en-têtes prouvent, ce qu'ils ne prouvent pas, et comment s'en servir pour se protéger.

Le trajet réel d'un e-mail

Un message ne va presque jamais directement de l'expéditeur au destinataire : il traverse une chaîne de machines dont chacune laisse sa signature.

1. Le client de messagerie Logiciel installé ou interface web. Il remet le message à un serveur de soumission, sur le port 587 ou 465, après authentification.
2. Le serveur d'envoi Il accepte le message d'un utilisateur authentifié, ajoute sa propre trace, le signe éventuellement, puis cherche le serveur du destinataire.
3. Les relais éventuels Passerelle antispam d'entreprise, liste de diffusion, redirection d'une ancienne adresse vers une nouvelle, plateforme d'envoi de masse : chacun ajoute une ligne au journal.
4. Le serveur de réception Désigné par l'enregistrement MX du domaine destinataire, il reçoit la connexion sur le port 25, note l'adresse IP en face de lui, exécute les contrôles d'authentification et inscrit leur résultat.
5. La boîte du destinataire Le message est déposé en réception ou en indésirables, selon le score attribué par les filtres.

Un point de vocabulaire commande tout le reste : un e-mail se compose d'une enveloppe et d'un message, indépendants l'un de l'autre. L'enveloppe, c'est le dialogue SMTP entre serveurs : MAIL FROM indique où renvoyer les erreurs, RCPT TO où livrer. Le message, c'est ce que vous voyez : From, To, Subject. Rien n'oblige les deux à concorder, exactement comme rien n'oblige l'adresse écrite au dos d'une enveloppe postale à correspondre à la signature de la lettre. Toute l'histoire de la fraude par e-mail tient dans cet écart.

Les en-têtes Received et la frontière de confiance

Chaque serveur qui prend le message en charge ajoute une ligne Received en tête du bloc d'en-têtes, sans toucher aux précédentes. La conséquence est mécanique : on lit la pile de haut en bas, du plus récent au plus ancien. La dernière étape du voyage est en première position, la prétendue première étape tout en bas.

Anatomie d'une ligne

Received: from smtp-out-4.exemple.fr (smtp-out-4.exemple.fr [203.0.113.24])
        by mx-in-3.fournisseur.fr with ESMTPS id 4Wm9pQ
        for <vous@fournisseur.fr>; Tue, 12 Aug 2026 09:41:11 +0200
# from  : le nom que la machine emettrice a annonce elle-meme (commande HELO)
# (...) : ce que le serveur receveur a MESURE, reverse DNS puis adresse IP reelle
# by    : la machine qui ecrit cette ligne
# with  : le protocole. ESMTPS = chiffre. ESMTPSA = chiffre ET authentifie
# id    : identifiant interne, utile pour retrouver la trace dans les journaux
# for   : le destinataire de l enveloppe
# ;     : date et heure locales du serveur, avec son decalage horaire

La distinction essentielle sépare le nom qui suit from du contenu des parenthèses. Le premier est déclaré par la machine émettrice, qui peut annoncer ce qu'elle veut. Le second est constaté par le serveur qui écrit la ligne : l'adresse IP entre crochets est celle avec laquelle la connexion s'est réellement établie. Une divergence marquée entre les deux n'est pas une preuve de fraude, mais c'est le premier détail à noter.

Ce que la pile ne prouve pas

Voici le point le plus important de ce guide, et celui que la plupart des pages sur le sujet passent sous silence. Un expéditeur malveillant contrôle le bas de la pile. Rien ne l'empêche de composer un message contenant déjà trois ou quatre Received entièrement inventés. Les serveurs suivants les recopieront tels quels : leur rôle est d'ajouter une ligne, pas de vérifier celles qui précèdent.

Received: from mx-in-3.fournisseur.fr ...        <- ecrit par VOTRE fournisseur : fiable
Received: from inconnu (203.0.113.99) ...       <- derniere ligne verifiable : la vraie source
Received: from mail.banque-exemple.fr ...       <- FRONTIERE DE CONFIANCE
                                                   tout ce qui suit peut etre invente
Received: from siege.banque-exemple.fr ...      <- decor

La méthode de lecture en découle : partez du haut, descendez tant que les lignes ont été écrites par des machines de votre fournisseur ou de votre entreprise. La dernière ligne fiable porte la seule information réellement utile, l'adresse IP que ce serveur de confiance a constatée en face de lui. Tout ce qui apparaît en dessous est du texte fourni par l'expéditeur : intéressant à lire, jamais opposable.

Où trouver les en-têtes bruts

Messagerie	Chemin d'accès
Webmail courant	Menu à droite du message → « Afficher l'original », « Afficher la source » ou « Afficher les détails du message ».
Thunderbird	Ctrl+U, ou menu Affichage → Code source du message.
Outlook (Windows)	Ouvrir le message dans sa fenêtre, puis Fichier → Propriétés → « En-têtes Internet ».
Mail (macOS)	Présentation → E-mail → Tous les en-têtes (⇧⌘H). Sur iOS et iPadOS, l'application Mail ne donne pas accès aux en-têtes bruts : passez par un ordinateur ou par le webmail en version bureau.

Une fois le bloc copié, notre analyseur d'en-têtes d'e-mail le décompose ligne par ligne, remet la chronologie à l'endroit, calcule le temps passé à chaque étape et met en évidence les adresses IP rencontrées. L'analyse est réalisée sur notre serveur, en mémoire : le texte collé n'est ni enregistré ni journalisé, et seules les adresses IP publiques qui en sont extraites sont transmises à notre fournisseur de géolocalisation, dans la limite de huit par analyse.

L'adresse IP d'origine : quand elle existe

Beaucoup d'articles laissent entendre qu'un e-mail contient toujours l'adresse IP de son auteur. C'était vrai il y a quinze ans ; ce ne l'est plus dans la majorité des cas.

Message rédigé dans un navigateur	La première trace est celle du serveur d'envoi du fournisseur. Les grandes messageries web n'inscrivent plus l'adresse du poste de l'expéditeur, précisément pour protéger la vie privée. Vous ne la trouverez pas : ce n'est pas une lacune de votre lecture.
Message envoyé depuis un logiciel	Certains fournisseurs conservent, dans la première ligne Received, l'adresse du client authentifié (repérable au with ESMTPSA). D'autres la remplacent par une adresse interne. C'est le cas le plus variable.
Message d'une plateforme d'envoi	Facture, confirmation de commande, infolettre : l'adresse constatée est celle d'un groupe de serveurs sortants mutualisés. Elle identifie la plateforme, pas son client.
Message d'un serveur autonome	Serveur d'entreprise, machine auto-hébergée, serveur compromis servant de relais : l'adresse constatée est bien celle de la machine émettrice. C'est le cas le plus exploitable.

Certains fournisseurs ajoutent des en-têtes non normalisés comme X-Originating-IP ou X-Sender-IP. Ils sont précieux : à condition d'avoir été ajoutés par un serveur de confiance. Situés sous la frontière de confiance, ils valent autant qu'un Received inventé : n'importe qui peut écrire une ligne commençant par X-.

Ce qu'une adresse IP permet de déduire

Une adresse vous apprend trois choses, pas une de plus : le réseau auquel elle appartient (opérateur ou hébergeur, via le numéro de système autonome), le pays d'enregistrement du bloc, et une localisation approximative dont la précision s'effondre dès qu'on descend sous l'échelle nationale. Notre outil de recherche d'adresse IP affiche ces éléments, et notre guide sur la géolocalisation IP explique pourquoi la ville indiquée est souvent celle d'un point de présence de l'opérateur, parfois à des centaines de kilomètres de l'abonné.

Deux enseignements pratiques. Si l'adresse appartient à un hébergeur, le message vient d'une machine louée et le contact abuse@ de cet hébergeur est le bon interlocuteur. Si elle appartient à un opérateur grand public, il provient probablement d'un ordinateur ou d'une box compromis, dont le propriétaire est lui-même victime. En IPv6, l'adresse identifie un préfixe attribué à un abonnement plutôt qu'un appareil précis ; notre comparatif IPv4 contre IPv6 détaille ce découpage.

En revanche, elle ne donnera jamais une identité, un nom ni une adresse postale. Seul l'opérateur qui l'a attribuée à un instant donné peut faire ce lien, et uniquement sur réquisition d'une autorité judiciaire. C'est ce qui fonde son statut de donnée personnelle, détaillé dans notre guide adresse IP et RGPD. Analysez donc pour comprendre et pour signaler, jamais pour enquêter vous-même sur une personne.

SPF, DKIM et DMARC sans jargon

Ces trois mécanismes reposent sur des enregistrements publiés dans le DNS du domaine expéditeur et répondent chacun à une question différente. Pour la syntaxe générale, reportez-vous à notre table des types d'enregistrements DNS et à notre guide du DNS.

SPF : quels serveurs ont le droit d'envoyer

exemple.fr.  IN  TXT  "v=spf1 ip4:203.0.113.24 include:_spf.hebergeur.net -all"
# ip4:     une adresse ou un bloc autorise
# include: delegue la liste a un autre domaine (plateforme d envoi)
# -all  tout le reste est refuse   |  ~all  tout le reste est douteux
# ?all  le domaine ne se prononce pas  |  +all  autorise n importe quel serveur, a proscrire

Ce qu'il vérifie : que l'adresse IP du serveur qui se connecte figure dans la politique du domaine de l'enveloppe, celui du MAIL FROM que vous retrouvez dans le Return-Path. Ses limites : il ne dit rien du From affiché à l'écran ; il casse sur les transferts automatiques, puisque le serveur qui retransmet n'est pas prévu dans la politique d'origine ; et il tolère au maximum dix résolutions DNS, plafond qu'un include de trop fait dépasser, provoquant un permerror.

DKIM : une signature qui voyage avec le message

sel1._domainkey.exemple.fr.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

# Et dans le message :
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exemple.fr; s=sel1;
        h=from:to:subject:date:message-id; bh=47DEQpj8...; b=Xk3pLm...
# d= domaine signataire    s= selecteur a chercher dans le DNS
# h= en-tetes couverts par la signature (lisez-la : From y figure-t-il ?)
# bh= empreinte du corps   b= la signature elle-meme

Ce qu'il vérifie : que le détenteur de la clé privée du domaine d= a bien signé ce message, et que ni le corps ni les en-têtes listés dans h= n'ont été modifiés depuis. Son avantage : la signature survit au transfert, car elle ne dépend pas du chemin emprunté. Ses limites : elle se brise dès qu'un intermédiaire modifie le message, une liste de diffusion qui ajoute un pied de page ou préfixe le sujet invalide la signature d'origine. Surtout, elle ne dit rien de la légitimité du domaine signataire : n'importe qui peut déposer un nom de domaine, y publier une clé et signer correctement ses propres messages indésirables. Un dkim=pass sur un domaine inconnu signifie qu'un inconnu a signé dans les règles.

DMARC : relier l'authentification à l'adresse affichée

_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr; adkim=s; aspf=r"
# p=    none (observer) | quarantine (indesirables) | reject (refuser)
# rua=  adresse de reception des rapports agreges quotidiens
# adkim / aspf : alignement strict (s) ou relache (r)

DMARC ne réalise aucune vérification nouvelle. Il fait deux choses que ni SPF ni DKIM ne savent faire : il impose l'alignement et il publie une politique. L'alignement exige que le domaine validé corresponde à celui du From affiché : soit le domaine du Return-Path validé par SPF, soit le domaine d= de la signature DKIM. En mode relâché, un sous-domaine suffit ; en mode strict, la correspondance doit être exacte. Un message passe DMARC si au moins un des deux contrôles réussit et est aligné.

Pourquoi un message peut afficher « SPF : pass » et rester frauduleux

C'est le malentendu le plus répandu. Un fraudeur dépose un domaine quelconque, disons envois-securises.example, et le configure impeccablement : SPF correct, DKIM signé, serveur à bonne réputation. Il envoie ensuite un message dont l'enveloppe utilise ce domaine, mais dont l'en-tête visible affiche From: Service client <contact@banque-exemple.fr>. Le contrôle SPF s'exécute sur envois-securises.example, qui lui appartient : il passe. La ligne Authentication-Results affichera spf=pass. Rien n'a été vérifié au sujet de banque-exemple.fr.

Seul DMARC détecte la manœuvre : l'alignement échoue, puisque le domaine authentifié n'est pas celui du From. Si le domaine usurpé publie p=reject, le message est refusé ; s'il n'a publié aucun DMARC, il passe. Variante encore plus simple : seul le nom affiché est trompeur, comme From: "Service des impôts" <a7f2@boite-jetable.example>. Là, tous les contrôles réussissent : le message vient réellement de cette adresse. L'authentification prouve une origine, jamais une honnêteté.

Un quatrième mécanisme, ARC, existe pour les intermédiaires légitimes : il permet à une liste de diffusion ou à un service de redirection de sceller le résultat des contrôles qu'il a constatés avant de modifier le message, afin que le destinataire final puisse en tenir compte malgré la rupture de SPF et de DKIM. Il apparaît sous la forme d'en-têtes ARC-Seal et ARC-Authentication-Results.

Lire l'en-tête Authentication-Results

C'est la ligne la plus dense du message : elle résume en un seul endroit le verdict des trois mécanismes précédents.

Authentication-Results: mx-in-3.fournisseur.fr;
        spf=pass smtp.mailfrom=envois.exemple.fr;
        dkim=pass header.d=exemple.fr header.s=sel1;
        dmarc=fail (p=NONE) header.from=banque-exemple.fr

Le premier élément, avant le point-virgule, est le nom du serveur qui a rendu ce verdict. Il est capital : ne faites confiance qu'à une ligne portant le nom d'un serveur de votre fournisseur. Un expéditeur malveillant peut inclure sa propre ligne Authentication-Results: tout=pass dans le message qu'il compose. Les serveurs sérieux suppriment celles qui portent leur propre nom avant d'ajouter la leur, mais rien n'empêche d'en fabriquer une au nom d'un tiers.

Lisez ensuite les propriétés qui suivent chaque verdict : smtp.mailfrom= pour SPF, header.d= pour DKIM, header.from= pour DMARC. Elles indiquent quel domaine a été contrôlé. Dans l'exemple ci-dessus, SPF et DKIM passent tous deux, sur exemple.fr, alors que l'adresse affichée est banque-exemple.fr : c'est exactement le scénario d'usurpation décrit plus haut, et seul le dmarc=fail le révèle.

Reconnaître un hameçonnage dans les en-têtes

La démarche qui suit sert à décider si vous pouvez faire confiance à un message qui vous est adressé. Elle ne sert pas à remonter jusqu'à une personne.

1. Comparez From, Reply-To et Return-Path Le premier est ce que vous voyez, le deuxième détermine où partira votre réponse, le troisième est le domaine réellement utilisé dans l'enveloppe. Sur un message légitime, les trois relèvent de la même organisation. Un Reply-To pointant vers un domaine sans rapport, ou vers une messagerie gratuite quand le message se réclame d'une administration, est un signal de premier ordre.
2. Lisez le domaine réel derrière le nom affiché Le nom affiché est un texte libre : il peut contenir une adresse e-mail complète et crédible. Ce qui compte est ce qui figure entre chevrons. Attention aux domaines composés : dans banque-exemple.fr.espace-client.example, le domaine réel est espace-client.example, les labels de gauche ne sont que des sous-domaines choisis par leur propriétaire. Méfiez-vous aussi des variantes typographiques : tiret ajouté, lettre doublée, extension changée, caractères d'un autre alphabet visuellement identiques.
3. Vérifiez l'alignement DMARC Dans Authentication-Results, cherchez dmarc= et lisez header.from=. C'est le seul verdict qui porte sur l'adresse affichée. Un dmarc=fail sur un message se présentant comme votre banque, votre opérateur ou une administration doit conduire au signalement, pas à un clic.
4. Regardez le serveur d'origine Repérez la dernière ligne Received écrite par votre fournisseur et notez l'adresse IP entre crochets. Une grande organisation française envoie depuis ses propres infrastructures ou depuis une plateforme professionnelle identifiable. Une adresse appartenant à un hébergeur bon marché, ou à un réseau grand public d'un pays sans rapport avec le message, contredit la présentation.
5. Méfiez-vous d'un Message-ID incohérent Cet identifiant unique se termine normalement par le nom de domaine du serveur qui l'a créé. Une partie droite sans rapport avec l'expéditeur annoncé, un identifiant absent ou visiblement fabriqué à la main trahissent un envoi par un outil de masse plutôt que par la messagerie de l'organisation citée.
6. Repérez une absence totale d'authentification Aucune ligne Authentication-Results, aucun DKIM-Signature, aucun Received-SPF : le message n'apporte aucune garantie vérifiable. Chez un petit expéditeur mal configuré c'est banal ; de la part d'une banque ou d'un service public, c'est incompatible avec leurs pratiques.
7. Recoupez avec le contexte Urgence artificielle, menace de suspension, pièce jointe inattendue, lien dont le texte affiché diffère de la cible réelle, demande de coordonnées bancaires ou d'un code reçu par SMS. Les en-têtes ne sont qu'une pièce du dossier : c'est la convergence des indices qui décide.

Pour dérouler cette liste sans rien oublier, collez le bloc d'en-têtes dans notre analyseur d'en-têtes d'e-mail : il isole les champs cités ci-dessus, souligne les divergences entre From et Return-Path et affiche le verdict d'authentification en clair.

Que faire d'un e-mail frauduleux

• Ne répondez pas, même pour dire d'arrêter : une réponse confirme que l'adresse est active et lue.
• Ne cliquez sur aucun lien, y compris celui de désabonnement, et n'ouvrez aucune pièce jointe.
• N'affichez pas les images distantes : elles servent souvent de témoin de lecture. La plupart des messageries les bloquent par défaut ; laissez ce réglage en place.
• Signalez le message dans votre messagerie avec le bouton dédié à l'hameçonnage ou au courrier indésirable. Ce geste alimente directement les filtres du fournisseur et protège les destinataires suivants : c'est de loin l'action la plus efficace à court terme.
• Utilisez les dispositifs français de signalement. Cybermalveillance.gouv.fr oriente les particuliers et les entreprises victimes ; la plateforme PHAROS, sur internet-signalement.gouv.fr, reçoit les signalements de contenus illicites ; l'association Signal Spam collecte les messages indésirables et les redistribue aux acteurs concernés ; le 33700 traite les SMS et appels frauduleux. En cas de préjudice financier, le dépôt de plainte reste possible en commissariat, en gendarmerie ou par la voie du dispositif de plainte en ligne pour les escroqueries.
• Prévenez la marque usurpée. Banques, opérateurs et administrations publient presque tous une adresse ou un formulaire de signalement d'hameçonnage ; à défaut, l'adresse abuse@ du domaine concerné est la voie normalisée. Joignez les en-têtes complets : c'est précisément ce dont leurs équipes ont besoin.

Si vous avez cliqué et saisi des identifiants, agissez sans attendre : changez le mot de passe concerné depuis un autre appareil si possible, activez la double authentification, faites opposition auprès de votre banque le cas échéant. Vérifiez aussi les règles de filtrage de votre boîte : une redirection ou une suppression automatique discrètement ajoutée est une technique classique pour rester dans un compte après en avoir pris le contrôle.

Un dernier point, non négociable : ne menez pas votre propre enquête. L'adresse IP relevée désigne le plus souvent une machine compromise dont le propriétaire ignore tout. Contacter, dénoncer publiquement ou tenter de se venger du titulaire d'une adresse IP expose à se tromper de cible et constitue en soi une infraction. Le rôle du destinataire s'arrête au signalement documenté.

Pourquoi votre courrier part en indésirable

Le même mécanisme joue dans l'autre sens. Si vos messages atterrissent systématiquement dans les indésirables de vos correspondants, la cause figure presque toujours dans cette liste.

• La réputation de l'adresse IP d'envoi. Les serveurs de réception tiennent un historique par adresse : volume, taux de plaintes, taux d'adresses inexistantes. Sur un serveur mutualisé, vous héritez du comportement de vos voisins d'envoi, et une hausse brutale de volume depuis une adresse jusque-là silencieuse suffit à déclencher un traitement défavorable.
• L'absence d'enregistrement PTR cohérent. L'adresse d'envoi doit se résoudre en un nom, et ce nom doit se résoudre en retour vers la même adresse. Sans cette double concordance, le message est dégradé, voire refusé d'emblée.
• SPF, DKIM ou DMARC manquants ou désalignés. Cas le plus courant : une organisation confie ses envois à un prestataire sans l'ajouter à son SPF ni activer la signature DKIM du domaine.
• Une adresse résidentielle dynamique. Les blocs attribués dynamiquement aux abonnés grand public figurent par principe dans des listes d'adresses réputées ne pas devoir émettre de courrier directement. Ce n'est pas une sanction, c'est le comportement par défaut. Notre guide sur l'adresse IP fixe expose les options des opérateurs français, et celui consacré au cas où votre IP est bloquée détaille la demande de retrait de liste.
• Le contenu du message. Une seule grande image sans texte, des liens raccourcis masquant leur destination, un From et un Reply-To incohérents, un envoi en masse dépourvu d'en-tête List-Unsubscribe, des pièces jointes de types à risque : chacun ajoute des points au score de suspicion.
• Un nom d'annonce générique. Un serveur qui se présente en HELO sous un nom sans rapport avec son domaine ni avec son reverse DNS se signale immédiatement.

Diagnostic en quatre commandes

Avant de changer quoi que ce soit, mesurez. Envoyez-vous un message vers une boîte hébergée chez un grand fournisseur et lisez votre propre Authentication-Results : en une ligne, vous saurez ce que le monde extérieur constate. Complétez par quelques interrogations DNS.

dig +short TXT exemple.fr                    # politique SPF publiee
dig +short TXT _dmarc.exemple.fr             # politique DMARC publiee
dig +short TXT sel1._domainkey.exemple.fr    # cle publique DKIM du selecteur
dig -x 203.0.113.24 +short                   # enregistrement PTR de l adresse d envoi

Publier un DMARC en p=none avec une adresse rua est la meilleure première étape : la politique ne bloque rien, mais vous recevez chaque jour des rapports agrégés indiquant qui envoie du courrier en votre nom, depuis quelles adresses IP et avec quels résultats. On y découvre régulièrement des services oubliés (outil de facturation, formulaire du site, ancienne application interne) qui expliquent à eux seuls le problème. Le durcissement vers quarantine puis reject ne vient qu'ensuite.

Auto-héberger son serveur de courrier

Techniquement, rien ne s'y oppose : les protocoles sont ouverts et documentés, les logiciels serveurs sont libres et matures, et une machine modeste suffit pour une famille ou une petite association. Pratiquement, l'auto-hébergement complet depuis une ligne résidentielle française se heurte à quatre obstacles concrets.

S'ajoutent deux contraintes de réception : le port 25 entrant doit être joignable, ce qui suppose une redirection sur la box (voir ouvrir un port) et une adresse publique, condition qui n'est plus remplie derrière un partage d'adresse opérateur, sujet traité dans notre guide sur le CGNAT. La disponibilité compte aussi : pendant une coupure, les serveurs distants retentent la livraison plusieurs jours, mais un MX de secours reste préférable. Enfin, un serveur laissé en relais ouvert est repéré et exploité en quelques heures ; vous devenez alors la source du problème plutôt que sa victime.

L'approche raisonnable, pour garder la main sans se battre contre l'écosystème, consiste à héberger la réception chez soi et à faire transiter les envois par un relais authentifié : celui de votre bureau d'enregistrement, de votre hébergeur ou d'un service d'envoi. Le port 25 n'est plus en cause, le PTR est celui du relais, la réputation est déjà établie, et vous conservez la maîtrise de vos messages. Pensez aussi à héberger la zone DNS de votre domaine ailleurs que chez vous, afin de pouvoir rediriger le courrier si la machine tombe. Les termes croisés dans ce guide sont repris dans notre glossaire du réseau.

Questions fréquentes