Un courriel ne va pas de votre ordinateur à celui de votre correspondant. Il traverse au moins quatre machines, porte deux adresses d’expéditeur différentes, et laisse une trace horodatée à chaque saut.
Un courriel ne va pas de votre ordinateur à celui de votre correspondant. Il est remis à votre serveur de soumission, qui le relaie au serveur de réception désigné par le DNS du domaine destinataire, lequel le dépose dans une boîte que vous consultez ensuite en IMAP. Chaque saut ajoute une ligne horodatée en haut de l’en-tête. Le message porte deux adresses d’expéditeur, celle de l’enveloppe et celle qui s’affiche, et l’écart entre les deux explique la plupart des messages rejetés, perdus ou classés en indésirables.
Vous cliquez sur « Envoyer ». Deux secondes plus tard, le message s’affiche chez votre correspondant. Ou il tombe dans son dossier « indésirables ». Ou il ne se passe rien, et trois heures après un message automatique revient avec une ligne obscure du genre 550 5.7.1 Message rejected.
Entre le clic et l’affichage, le courriel a changé de mains au moins quatre fois. Il a été inspecté par autant de logiciels différents, et chacun a laissé une trace horodatée dans le message lui-même. Ces traces sont visibles, gratuitement, dans n’importe quel client de messagerie. Presque personne ne les ouvre.
Savoir lire ce trajet sert à quelque chose de très concret : déterminer, quand un message n’arrive pas, s’il faut appeler son fournisseur, corriger une ligne dans la configuration d’un domaine, ou simplement attendre un quart d’heure.
La représentation courante est celle d’un tuyau direct entre deux personnes. La réalité tient en quatre rôles, tenus par quatre logiciels distincts, souvent hébergés par quatre organisations différentes.
Le premier est votre client, l’application ou la page web où vous écrivez. Il ne parle jamais au destinataire. Il remet le message à un serveur de soumission, celui de votre fournisseur de messagerie, après vous avoir authentifié. Ce serveur devient responsable du message : c’est lui qui le mettra en file d’attente et le réessaiera si besoin.
Le serveur de soumission cherche ensuite, dans le DNS, quel serveur de réception accepte le courrier pour le domaine visé, et lui transmet le message. Ce troisième serveur applique ses filtres, puis dépose le message dans une boîte. Le destinataire vient enfin le lire avec son propre client, qui interroge cette boîte en IMAP.
Quatre acteurs, donc, et trois transmissions. Chacune peut échouer pour une raison qui lui est propre, et c’est pourquoi « le mail ne marche pas » n’est jamais un diagnostic. La même logique de couches vaut pour tout le reste du réseau, comme le montre la méthode de diagnostic quand la connexion tombe.
Le protocole qui assure les deux premières transmissions s’appelle SMTP. Son dialogue est étonnamment simple, et lisible par un humain. Le serveur émetteur se présente, annonce l’adresse d’enveloppe de l’expéditeur avec la commande MAIL FROM, puis une ou plusieurs adresses de destination avec RCPT TO, puis envoie le contenu après la commande DATA. Le serveur d’en face répond à chaque étape par un code à trois chiffres.
Point essentiel : SMTP ne connaît que le saut suivant. Il ne planifie pas d’itinéraire, il ne sait pas si le message arrivera, et il ne conserve aucune garantie de bout en bout. Chaque serveur accepte la responsabilité du message, puis la transfère au suivant. C’est ce modèle de relais successifs qui rend le courriel extraordinairement robuste et absolument incapable de prouver quoi que ce soit sur son origine, sauf couche d’authentification ajoutée par-dessus.
| Protocole | Port usuel | Qui parle à qui | Ce que ça fait |
|---|---|---|---|
| SMTP soumission | 587 (ou 465) | Votre client vers votre fournisseur | Dépose le message après authentification par mot de passe |
| SMTP relais | 25 | Serveur d’envoi vers serveur de réception | Transmet le message entre organisations, sans mot de passe |
| IMAP | 993 | Client du destinataire vers son fournisseur | Consulte une boîte qui reste sur le serveur |
| POP3 | 995 | Client du destinataire vers son fournisseur | Télécharge les messages, et souvent les efface du serveur |
La ligne la plus intéressante est celle du port 25. Entre organisations, personne ne présente de mot de passe. Le serveur de réception accepte un message d’un inconnu, exactement comme une boîte aux lettres physique accepte une enveloppe déposée par n’importe qui. Toute la lutte contre la falsification consiste à ajouter, autour de ce dépôt anonyme, des vérifications qui n’existaient pas à l’origine.
C’est la distinction que presque tout le monde ignore, et elle explique la moitié des surprises.
L’adresse annoncée par MAIL FROM pendant le dialogue SMTP est l’adresse d’enveloppe. Elle sert au transport et surtout au retour : c’est là que partiront les avis de non-remise. Le serveur de réception la recopie généralement dans un champ Return-Path.
L’adresse affichée par votre logiciel de messagerie, elle, vient du champ From de l’en-tête, à l’intérieur du message. Le protocole ne vérifie aucune correspondance entre les deux. Une lettre d’information légitime exploite d’ailleurs cet écart en permanence : l’enveloppe pointe vers le routeur technique qui gère les retours, l’affichage montre le nom de la marque.
Cet écart est la faille structurelle du courriel. Les trois mécanismes qui la referment, SPF, DKIM et DMARC, font l’objet d’un article séparé : le premier valide l’enveloppe, le deuxième signe le message, le troisième relie enfin les deux au nom que vous lisez à l’écran.
Pour livrer un message à prenom@exemple.fr, le serveur d’envoi interroge le DNS et demande les enregistrements MX du domaine exemple.fr. La réponse est une liste de noms de serveurs, chacun assorti d’un nombre de priorité : le plus petit nombre est essayé en premier, les suivants servent de secours.
Conséquence pratique rarement comprise : le nom de domaine d’une adresse électronique ne dit rien de l’endroit où le courrier est réellement traité. Une mairie peut avoir un domaine en .fr hébergé en France pour son site web et des enregistrements MX pointant vers un service de messagerie étranger. Inversement, changer d’hébergeur de messagerie se résume à modifier deux ou trois lignes dans une zone DNS, sans toucher au site.
Cette même indirection explique une panne courante : un domaine dont les enregistrements MX ont expiré ou été mal recopiés continue d’afficher un site web parfaitement fonctionnel pendant que tous ses courriels rebondissent. Le symptôme est le même que pour un seul site qui refuse de s’ouvrir : la panne n’est pas là où on la cherche.
Chaque serveur qui accepte le message ajoute une ligne Received au sommet de l’en-tête, avant les lignes déjà présentes. La pile obtenue est donc antichronologique : la ligne la plus basse décrit le premier saut, la ligne la plus haute le dernier.
Chaque ligne indique le serveur qui a transmis, celui qui a reçu, le protocole utilisé et un horodatage avec fuseau. En les lisant du bas vers le haut, on reconstitue le trajet complet et on repère où le message a stationné. Un écart de quarante minutes entre deux lignes signale une file d’attente saturée, pas un problème de destinataire.
Cette lecture ne remplace pas la règle de base contre l’hameçonnage, qui reste de ne jamais se connecter depuis un lien reçu. Elle sert à trancher un doute après coup, ou à documenter un signalement. Pour s’entraîner sur des cas concrets, notre quiz de reconnaissance d’arnaque reprend les mêmes indices.
Beaucoup de gens croient que le message leur est « envoyé » jusqu’à leur téléphone. Il n’en est rien : il est déposé dans une boîte, sur un serveur, et votre client vient l’y chercher. IMAP est un protocole de consultation, pas d’acheminement.
La différence avec POP est structurante. POP télécharge et, par défaut, supprime la copie serveur : la boîte vit sur un appareil unique. IMAP maintient l’état sur le serveur et le reflète partout : un message lu sur le téléphone apparaît lu sur l’ordinateur, un dossier créé apparaît des deux côtés.
Ce reflet a un revers que beaucoup découvrent trop tard. Une suppression accidentelle se propage à tous les appareils en quelques secondes, et le dossier « corbeille » se vide tout seul au bout de quelques semaines chez la plupart des fournisseurs. Une boîte IMAP n’est donc pas une archive : c’est exactement le raisonnement développé dans pourquoi la synchronisation ne remplace pas une sauvegarde. Si vos courriels comptent, ils doivent être exportés ailleurs, selon la même logique que la règle de sauvegarde 3-2-1.
Le filtrage ne se joue pas d’abord sur le contenu. Il se joue sur l’émetteur. Un serveur de réception évalue, dans cet ordre, la réputation de l’adresse IP qui se connecte, l’authentification du domaine expéditeur, l’historique de ce domaine auprès de ses propres utilisateurs, puis seulement les signaux internes au message.
C’est pour cela qu’une association qui envoie sa première lettre d’information à huit cents adresses depuis un serveur neuf part en indésirable, alors que son texte ne contient aucun mot suspect. L’adresse IP n’a pas d’historique, le domaine n’est pas authentifié, et le volume soudain ressemble à celui d’un émetteur de courrier non sollicité.
| Réponse du serveur | Sens | Ce qui se passe ensuite | Ce que vous devez faire |
|---|---|---|---|
| 250 | Message accepté | Le serveur suivant en prend la responsabilité | Rien, mais l’acceptation ne garantit pas la boîte de réception |
| 4xx (421, 450, 451) | Refus temporaire | Nouvelles tentatives pendant plusieurs jours | Attendre : liste grise, quota momentané ou serveur saturé |
| 5xx (550, 551, 553) | Refus définitif | Avis de non-remise immédiat | Vérifier l’adresse, l’authentification du domaine et la réputation |
| Accepté puis classé | Aucun code d’erreur | Le message part en indésirable en silence | Vérifier l’authentification et demander au destinataire de marquer comme légitime |
La dernière ligne est la plus traître. Un message accepté avec un code 250 puis rangé en indésirable ne produit aucune alerte côté expéditeur. Vous croyez avoir écrit, votre correspondant croit que vous ne l’avez pas fait, et rien dans votre dossier « envoyés » ne signale l’écart. C’est faute de retour fiable que les envois en nombre recourent aux pixels de suivi, qui signalent l’affichage du message plutôt que son acceptation.
Presque tous les sauts sont aujourd’hui protégés par TLS, la même famille de mécanismes que celle décrite dans HTTPS et les certificats. Le client chiffre sa soumission, les serveurs chiffrent leur relais quand ils le peuvent.
« Quand ils le peuvent » est le mot important. Sur le port 25, le chiffrement est historiquement opportuniste : le serveur émetteur demande, et si l’autre ne propose rien, la transmission se fait en clair plutôt que d’échouer. Des extensions plus récentes permettent à un domaine de déclarer qu’il exige le chiffrement, mais leur déploiement reste partiel.
Les métadonnées, elles, restent visibles dans tous les cas et pour tout le monde sur le trajet : qui écrit à qui, à quelle heure, avec quel objet, depuis quelle adresse IP. C’est la même dissymétrie que pour les fichiers déposés chez un prestataire, décrite dans notre article sur le cloud. Elle explique aussi pourquoi une adresse compromise est un désastre : elle commande la réinitialisation de tous vos autres comptes, d’où l’intérêt d’y placer une double authentification avant tout le reste.
Trois questions, dans cet ordre, isolent la panne sans tâtonner.
Ai-je reçu un avis de non-remise ? Si oui, le message a été refusé et l’avis contient un code. Un code commençant par 4 se règle en attendant, un code commençant par 5 exige une correction. Si aucun avis n’est revenu, le message a été accepté quelque part, et le problème est un classement, pas un acheminement.
Le problème vise-t-il un destinataire ou tous ? Un seul destinataire concerné oriente vers son filtre ou son quota. Tous les destinataires concernés orientent vers votre domaine : authentification manquante, réputation dégradée, enregistrements MX ou de sortie mal configurés.
Que disent les en-têtes du dernier message passé ? La ligne d’authentification et la pile des lignes Received répondent en dix secondes à des questions sur lesquelles on discute parfois pendant des jours. Si la réponse est un échec d’authentification, la suite se joue dans la configuration du domaine, et non dans le texte du message.
Le plus souvent à cause de la liste grise. Le serveur de réception refuse temporairement le premier contact avec un code 4xx, en pariant que les logiciels d’envoi en masse ne réessaieront pas. Un serveur légitime, lui, remet le message en file et rappelle quelques minutes plus tard, parfois un quart d’heure. Le message finit donc par arriver, avec un retard qui ne se reproduit pas pour les envois suivants entre les deux mêmes serveurs. Un retard qui dépasse plusieurs heures traduit plutôt une file d’attente saturée ou une réputation dégradée.
La fonction existe dans tous les clients, sous un nom différent : « Afficher l’original », « Afficher la source du message », « Propriétés » puis « En-têtes Internet ». Elle ouvre le texte brut du message, en-têtes compris. Vous y cherchez les lignes Received, la ligne Return-Path, la ligne Authentication-Results et le champ From. C’est le seul endroit où l’on peut établir par quels serveurs un message est réellement passé, et donc distinguer un message authentique d’une imitation.
Non. L’accusé de réception normalisé est une demande facultative : le client du destinataire peut l’ignorer, et la plupart le font ou demandent l’autorisation. Ce qui remonte réellement, dans les envois commerciaux, c’est le chargement d’une image invisible, un mécanisme détaillé dans notre article sur les pixels de suivi. Là encore, une ouverture n’est pas une lecture, et le pré-chargement automatique de certains services fausse complètement la mesure.
POP télécharge les messages sur un appareil et, dans sa configuration d’origine, les efface du serveur : la boîte vit sur votre ordinateur. IMAP laisse les messages sur le serveur et se contente de refléter leur état sur chaque appareil : les dossiers, les messages lus et les suppressions sont les mêmes partout. IMAP est le choix par défaut dès que vous relevez votre courrier sur un téléphone et un ordinateur. En revanche, la copie IMAP n’est pas une sauvegarde, puisqu’une suppression se propage.
Techniquement, oui, pour tout ce qui n’est pas chiffré de bout en bout : le message est en clair dans son stockage. Juridiquement, il est responsable de traitement ou sous-traitant au sens du RGPD et n’a pas le droit d’en exploiter le contenu sans base légale. Les métadonnées, elles, restent visibles dans tous les cas : qui écrit à qui, quand, avec quel objet et quelle taille. Le seul moyen de soustraire le contenu à l’hébergeur est un chiffrement appliqué avant l’envoi.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Adresse IP, DNS, wifi, fibre, 5G, cookies : le réseau démonté pièce par pièce.