Source: https://once-email.com/fr/blog/read-received-headers Livraison et authentification · 3 août 2026Mis à jour 9 août 2026 # Comment lire les en-têtes reçus et tracer un chemin de livraison d'e-mails Suivez les champs d'en-tête Reçus dans le bon ordre, comparez les horodatages en toute sécurité et reconnaissez les limites des noms d'hôte, des adresses IP et des données de trace non fiables. [Rédaction Once Email, Once Email author Rédaction Once Email]() Relu par Rédaction spécialisée Once Email Ce que ce guide vous aide à faire Les lecteurs peuvent créer un chemin de livraison horodaté, repérer les points de retard plausibles et décrire les limites des noms d'hôtes, des adresses et des horloges non synchronisées. Guide de l’article Pourquoi cet article mérite votre attention **Analyse originale** La méthode de trace lit les sauts depuis la limite de réception approuvée vers l'arrière et sépare les preuves de relais observées des lignes qu'un expéditeur non fiable pourrait fabriquer. **Contexte des tendances** Les relais cloud, les passerelles de filtrage et les proxys de confidentialité ajoutent davantage de sauts et de réécriture, mais chaque récepteur de confiance ajoutant sa propre trace reste le point d'ancrage utile. **Valeur pratique** Les lecteurs peuvent créer un chemin de livraison horodaté, repérer les points de retard plausibles et décrire les limites des noms d'hôtes, des adresses et des horloges non synchronisées. Un email peut transiter par un serveur d'applications, un relais sortant, un service de filtrage et l'échangeur de messagerie du destinataire avant d'atteindre une boîte de réception. Chaque serveur SMTP récepteur ajoute normalement un champ ` Received `. La lecture de ces champs peut aider à localiser un retard, à identifier le serveur qui a remis le courrier à votre fournisseur et à établir un calendrier de livraison. Les champs constituent une preuve de diagnostic et non une chaîne de traçabilité complète. Un expéditeur peut ajouter de fausses lignes avant la transmission, les horloges peuvent être en désaccord et une infrastructure privée peut masquer ou réécrire des détails. Utilisez la trace avec les journaux du fournisseur, les résultats d'authentification et le contexte du message. ## [Qu'est-ce qu'un champ Reçu enregistre]() [RFC 5321 section 4.4]() nécessite qu'un serveur SMTP qui reçoit un message pour livraison ou traitement ultérieur ajoute les informations de trace au début. Un champ typique ressemble à ceci : ``` Received: from outbound.example.com (outbound.example.com [192.0.2.10]) by mx.example.net with ESMTPS id ABC123 for ; Mon, 03 Aug 2026 10:30:04 +0000 ``` Les clauses communes répondent à différentes questions : - ` from ` décrit l'hôte présenté par le côté expéditeur et peut inclure l'adresse observée sur la connexion réseau ; - ` by ` identifie le serveur qui a accepté ce saut et écrit le champ ; - ` with ` décrit la variante de transport ou de protocole, telle que ESMTP ou SMTP chiffré ; - ` id ` est un identifiant de file d'attente ou de transaction utile lorsqu'un administrateur peut rechercher les journaux de ce serveur ; - ` for ` peut identifier un destinataire d'enveloppe, bien que cela soit facultatif et puisse être supprimé pour des raisons de confidentialité ; - la date après le point-virgule qui enregistre le moment où le serveur de réception a accepté le message, y compris un décalage horaire numérique. Tous les champs ne contiennent pas toutes les clauses. Les passerelles et les systèmes non SMTP peuvent produire des formats inconnus. La RFC 5321 indique explicitement aux systèmes de réception d'être robustes face à un formatage de trace inattendu plutôt que de rejeter un message simplement parce qu'une ligne de trace semble inhabituelle. ## [Lisez l'itinéraire de bas en haut]() Les serveurs SMTP ajoutent de nouveaux champs ` Received ` au-dessus de ceux existants. Le saut de réception le plus récent se trouve donc en haut du bloc d'en-tête ; le premier saut enregistré se trouve généralement en bas. Considérez cette trace simplifiée : ``` Received: from filter.example.net by mx.recipient.example; Mon, 03 Aug 2026 10:30:07 +0000 Received: from outbound.sender.example by filter.example.net; Mon, 03 Aug 2026 10:30:04 +0000 Received: from app.internal.example by outbound.sender.example; Mon, 03 Aug 2026 10:29:59 +0000 ``` Lisez-le comme suit : 1. ` app.internal.example ` a transmis le message à ` outbound.sender.example `. 2. Le serveur sortant l'a transmis à ` filter.example.net `. 3. Le filtre l'a transmis au serveur ` mx.recipient.example ` du destinataire. Ne triez pas les champs en fonction de leurs horodatages visibles. L'ordre des champs défini par le protocole est plus utile car les horloges du serveur peuvent être erronées ou non synchronisées. Convertissez chaque horodatage en un seul fuseau horaire lors de l'estimation du délai et conservez la valeur d'origine dans tout enregistrement de preuve. ## [Calculez soigneusement le délai]() Pour chaque paire adjacente, soustrayez l’heure de réception précédente de l’heure ultérieure après avoir appliqué les décalages numériques. Un écart positif important peut indiquer une file d'attente, une limitation de débit, une panne temporaire du réseau ou un traitement lors du prochain service. Il n’identifie pas la cause par lui-même. Un écart négatif indique généralement un décalage d’horloge, une erreur d’analyse ou un champ non fiable – et non un voyage dans le temps ni une preuve automatique de contrefaçon. Vérifiez si les décalages ont été gérés correctement et si les deux lignes ont été écrites par les systèmes que vous contrôlez. Lorsque vous étudiez votre propre application, corrélez la trace avec : - l'heure UTC à laquelle l'application a demandé le message ; - l'identifiant de file d'attente de l'expéditeur et le journal de livraison ; - le premier champ ` Received ` écrit par une infrastructure de confiance ; - l'heure à laquelle le prestataire destinataire déclare l'accepter ou l'afficher ; - tout état de nouvelle tentative ou réponse SMTP enregistré par le système expéditeur. La [liste de contrôle des tests de courrier électronique des développeurs]() explique comment enregistrer le calendrier de la demande d'arrivée sans traiter une observation de la boîte de réception comme l'ensemble du système de livraison. ## [Décidez à quel saut vous pouvez faire confiance]() Le champ ` Received ` le plus haut a été ajouté par le serveur le plus proche de la boîte aux lettres que vous consultez. Si ce fournisseur de messagerie est fiable, ce champ constitue généralement le point de départ le plus solide : il peut indiquer l'adresse réseau à partir de laquelle le fournisseur a réellement accepté le message. Travaillez vers le bas uniquement dans la mesure où les champs restent cohérents avec l'infrastructure que vous reconnaissez. Les lignes prétendument créées avant que le message ne parvienne à un fournisseur de confiance peuvent être fabriquées par l'expéditeur. Un expéditeur malveillant ne peut normalement pas réécrire les champs déjà ajoutés ultérieurement par les systèmes du destinataire, mais il peut placer un texte de trace d'apparence plausible dans le message avant que ces systèmes ne le voient. Les noms d'hôtes nécessitent également du contexte. Un nom ` from ` peut provenir d'un message d'accueil SMTP, d'un DNS inversé ou d'une configuration locale. Une adresse privée telle que ` 10.0.0.0/8 ` peut décrire un saut interne mais ne peut pas être tracée directement sur l'Internet public. Un résultat de géolocalisation IP est approximatif et n’établit pas l’identité ou la localisation physique de l’auteur. ## [Les champs reçus ne remplacent pas l'authentification]() Les champs ` Received ` décrivent les sauts de transport. SPF, DKIM et DMARC évaluent différentes preuves concernant l'autorisation de domaine, les signatures et l'alignement. Un itinéraire qui semble ordinaire peut transporter un message malveillant, et un message transféré légitime peut avoir un itinéraire compliqué. Utilisez le guide [SPF, DKIM et DMARC]() pour interpréter les résultats d'authentification séparément. N'en déduisez pas que l'adresse ` From ` visible contrôlait chaque hôte de la route, ou qu'un relais familier sécurise le contenu. ## [Utilisez l'analyseur d'en-tête local sans trop partager]() L'[analyseur d'en-tête d'e-mail Once Email]() extrait les sauts ` Received `, les résultats d'authentification et les champs répétés dans le navigateur. Collez uniquement les champs d’en-tête – jamais un mot de passe, un code de vérification, un corps de message ou une pièce jointe. L'outil ne contacte pas les serveurs répertoriés, ne vérifie pas leurs journaux et ne prouve pas qu'un champ est authentique. Avant de partager les résultats, remplacez les adresses personnelles, les adresses IP publiques, les ID de file d'attente et les noms d'hôte internes tout en conservant l'ordre et les décalages horaires nécessaires pour reproduire le problème. Le [guide de rédaction des preuves de test]() fournit un modèle de déclaration plus sûr. ## [Une liste de contrôle d'interprétation fiable]() Commencez par le haut pour identifier le système de réception final, puis reconstruisez le chemin de bas en haut. Faites confiance à l'ordre sur le terrain avant l'horloge. Normalisez les fuseaux horaires, signalez les intervalles négatifs ou inhabituellement longs et marquez la frontière entre l'infrastructure fiable et contrôlée par l'expéditeur. Corrélez les ID de file d’attente avec les journaux de serveur autorisés lorsqu’ils sont disponibles. Plus important encore, indiquez la limite de la conclusion. Une trace peut prendre en charge « le fournisseur destinataire a accepté cette connexion de ce relais à ce moment-là ». Il ne peut généralement pas prouver qui a écrit le message, si chaque saut précédent est authentique ou si ses liens et pièces jointes sont sûrs. ## Guides associés L'e-mail de vérification n'arrive pas ? Une liste de contrôle de dépannage sécurisé Gérez les erreurs d'adresse, les retards des expéditeurs, les tentatives, le filtrage et les limites des boîtes aux lettres sans demander de codes à plusieurs reprises ni affaiblir la sécurité du compte. [L'e-mail de vérification n'arrive pas ? Une liste de contrôle de dépannage sécurisé]() Comment lire les résultats SPF, DKIM et DMARC dans un en-tête d'e-mail Comprenez ce qu'authentifient SPF, DKIM et DMARC, pourquoi l'alignement est important et pourquoi un résultat réussi est une preuve utile plutôt qu'une preuve qu'un message est sûr. [Comment lire les résultats SPF, DKIM et DMARC dans un en-tête d'e-mail]() Postfix vs Dovecot : rôles différents dans la réception des e-mails Situez Postfix, Dovecot, LMTP, la file et IMAP dans le trajet entrant, puis localisez une panne à partir de preuves. [Postfix vs Dovecot : rôles différents dans la réception des e-mails]() ## Outils e-mail axés sur la confidentialité Analyseur d’en-têtes d’e-mail Explique les étapes de livraison et résume SPF, DKIM et DMARC sans garantir une authenticité absolue. [Analyseur d’en-têtes d’e-mail]() [Pourquoi certains sites Web rejettent les adresses e-mail jetables Comprenez les raisons de récupération de compte, d'abus, d'assistance et de risque derrière les restrictions de courrier électronique jetables, et ce que les utilisateurs légitimes devraient faire au lieu de les contourner.]() [Une liste de contrôle sûre avant de télécharger une pièce jointe à un e-mail Vérifiez la demande, l'expéditeur, le nom du fichier, le type et l'environnement de traitement avant de télécharger une pièce jointe et sachez ce que les aperçus et les scanners d'e-mails ne peuvent pas prouver.]()