Comment lire les en-têtes reçus et tracer un chemin de livraison d'e-mails

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 <[email protected]>;
        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.