Lire les en-têtes Received : sauts, délais et ce qu’ils prouvent

Chaque serveur SMTP qui accepte un message ajoute une ligne Received: en tête de celui-ci. Lues ensemble, ces lignes retracent le chemin suivi par le message et le moment où chaque hôte l’a reçu. C’est la première chose à vérifier lorsqu’un message est arrivé en retard ou par un chemin inattendu. Certaines de ces lignes sont des preuves fiables, d’autres ne sont que des affirmations, et cet article explique comment les distinguer.

Les règles viennent de la RFC 5321 §4.4 (informations de trace) et de la RFC 5322 §3.6.7 (champs de trace). Le lien avec Authentication-Results vient de la RFC 8601 (voir l’en-tête Authentication-Results).

D’où viennent les lignes Received

RFC 5321 §4.4 : « Lorsqu’un serveur SMTP reçoit un message à livrer ou à traiter, il DOIT insérer des informations de trace ("time stamp" ou "Received") au début du contenu du message » (When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content). Trois conséquences découlent directement de la même section :

• Chaque ligne est écrite par l’hôte qui reçoit, pas par l’expéditeur. Une ligne Received: enregistre l’acceptation du message par un hôte.
• Les lignes ne sont ajoutées qu’en tête. « Les serveurs SMTP DOIVENT ajouter les lignes Received en tête des messages ; ils NE DOIVENT PAS modifier l’ordre des lignes existantes ni insérer de lignes Received à un autre endroit » (SMTP servers MUST prepend Received lines to messages ; they MUST NOT change the order of existing lines or insert Received lines in any other location).
• Les lignes existantes ne sont ni modifiées ni supprimées. « Un programme de messagerie Internet NE DOIT PAS modifier ou supprimer une ligne Received : ajoutée précédemment à la section d’en-tête du message » (An Internet mail program MUST NOT change or delete a Received : line that was previously added to the message header section).

Ce sont des exigences imposées aux logiciels conformes, pas des garanties valables pour chaque message. La RFC 3848 §3 note que « certaines personnes, dans une tentative malavisée de cacher des informations sur leurs serveurs internes, retirent des informations utiles des en-têtes Received » (some people in a misguided attempt to hide information about their internal servers will strip Received headers of useful information) : une chaîne peut donc présenter des trous.

Lorsque le message quitte SMTP au moment de la livraison finale, le serveur qui livre ajoute aussi Return-Path:, qui contient l’adresse MAIL FROM de l’enveloppe. La RFC 5321 §4.4 indique que le message livré « commence par une ligne de chemin de retour, suivie d’une ou plusieurs lignes d’horodatage » (begin with a return path line, followed by one or more time stamp lines).

La RFC 5322 §3.6.7 considère ces champs comme « strictement informatifs, toute interprétation formelle sortant du cadre de ce document » (strictly informational, and any formal interpretation of them is outside of the scope of this document). Il n’y a rien à valider : une ligne Received: n’est digne de confiance que dans la mesure où l’est l’hôte qui l’a écrite.

Syntaxe du champ

La RFC 5321 §4.4 définit la ligne (version abrégée ; FWS/CFWS désignent les espaces de pliage et les commentaires de la RFC 5322) :

Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp           = From-domain By-domain Opt-info [CFWS] ";" FWS date-time
Opt-info        = [Via] [With] [ID] [For] [Additional-Registered-Clauses]

Une ligne peut être pliée sur plusieurs lignes physiques : dépliez-la avant de la lire. Les clauses, dans l’ordre :

Ne lisez pas le mot-clé with comme une preuve de chiffrement ou d’authentification. La RFC 3848 §3 indique que ces mots-clés « peuvent être modifiés par un attaquant actif » (can be modified by an active attacker) et « n’apportent aucune garantie de sécurité réelle » (do not provide any real-world security assurance).

La grammaire autorise des commentaires (CFWS) entre les clauses, si bien que les implémentations ajoutent du texte libre entre parenthèses. Le contenu de ces commentaires n’est pas normalisé : ne l’analysez pas comme s’il l’était.

Ordre de lecture : de bas en haut

Chaque serveur ajoute sa propre ligne en tête, donc les lignes se lisent de la plus récente à la plus ancienne :

• La ligne Received: du bas est le premier saut enregistré : le premier serveur qui a accepté le message et écrit une ligne.
• La ligne Received: du haut est le saut le plus récent.
• Comparez l’hôte by de chaque ligne avec l’hôte from de la ligne située au-dessus. Ils ne seront souvent pas écrits de la même façon, car le nom from est ce qu’annonce le client dans EHLO, et le nom EHLO d’un hôte peut légitimement différer du nom qu’il écrit dans by. Une discordance est une raison d’y regarder de plus près, pas la preuve qu’un saut manque ou qu’une ligne est fausse. Les adresses IP entre les parenthèses de from sont un meilleur fil conducteur.

Pour retracer le chemin, partez du bas et remontez.

Les sauts auxquels se fier

Savoir d’où viennent les lignes indique jusqu’où leur faire confiance.

1. Une ligne n’est fiable que dans la mesure où l’est l’hôte qui l’a écrite. N’importe quel client SMTP peut ouvrir une connexion et écrire ce qu’il veut dans le contenu du message avant la fin de DATA, y compris du texte qui ressemble à des lignes Received: antérieures. RFC 5321 §7.1 : « il est possible, même pour des utilisateurs assez occasionnels, de dialoguer directement avec des serveurs SMTP de réception et de relais et de créer des messages qui feront croire à un destinataire naïf qu’ils viennent d’ailleurs » (it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else).
2. Vos serveurs conservent tout ce qu’on leur a remis. Les lignes existantes « NE DOIVENT PAS » être modifiées ou supprimées : un serveur de réception garde donc les lignes fabriquées avec les vraies.
3. Vous ne pouvez donc vous fier qu’aux lignes ajoutées par votre propre infrastructure de réception. « Votre propre » désigne ici l’ADMD côté réception, le domaine administratif que la RFC 8601 §1.2 décrit comme situé à l’intérieur de sa « frontière de confiance » (trust boundary). Trouvez la ligne la plus basse dont l’hôte by est l’un de vos serveurs. C’est le premier saut de confiance, le moment où le message est entré dans votre infrastructure.
4. Dans le premier saut de confiance, ne vous fiez qu’à ce que votre serveur a observé. C’est-à-dire son horodatage, son id, son protocole with et l’adresse IP entre les parenthèses de from, qui provient de la connexion TCP. Le nom from avant les parenthèses vient de l’EHLO du client et n’est qu’une affirmation.
5. Tout ce qui se trouve sous le premier saut de confiance peut être falsifié. Les lignes situées en dessous étaient déjà dans le message quand votre serveur l’a accepté. Elles peuvent être exactes : les relais d’un expéditeur légitime écrivent des lignes exactes, et elles vous aident à déboguer le côté de cet expéditeur. Mais l’IP qui se connecte dans le premier saut de confiance est la seule adresse de la chaîne que votre infrastructure a vérifiée.

La même logique s’applique quand c’est vous l’expéditeur et que vous lisez une copie arrivée dans une boîte que vous n’exploitez pas. Seules les lignes ajoutées par l’infrastructure du fournisseur de réception sont des observations du récepteur. Les lignes situées en dessous sont les enregistrements de vos propres systèmes, que vous pouvez confronter à vos propres journaux.

Délai de chaque saut

Chaque horodatage marque le moment où cet hôte a reçu le message. La différence entre deux horodatages adjacents est le temps passé par le message entre une réception et la suivante : en file d’attente sur l’hôte inférieur, ou en transit depuis celui-ci.

Normalisez d’abord les fuseaux horaires

La RFC 5321 §4.4 demande aux serveurs d’utiliser des décalages numériques : « Les serveurs SMTP qui créent des champs d’en-tête Received DEVRAIENT utiliser des décalages explicites dans les dates (par exemple -0800) plutôt que des noms de fuseaux horaires, quels qu’ils soient. L’heure locale (avec un décalage) DEVRAIT être utilisée de préférence à l’UT lorsque c’est possible » (SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) SHOULD be used rather than UT when feasible). La RFC 5322 §3.3 définit le décalage : « +hhmm signifie +(hh * 60 + mm) minutes, et -hhmm signifie -(hh * 60 + mm) minutes » (+hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). Un horodatage en -0000 signifie que « l’heure a été générée sur un système qui peut se trouver dans un fuseau horaire local autre que le temps universel, et que la date-heure ne contient aucune information sur le fuseau horaire local » (the time was generated on a system that may be in a local time zone other than Universal Time and that the date-time contains no information about the local time zone).

Pour calculer un délai, convertissez chaque horodatage en UTC en soustrayant son décalage (09:00:02 -0400 correspond à 13:00:02 UTC), puis soustrayez les valeurs adjacentes. Si vous comparez les heures affichées sans conversion, un saut peut sembler durer des heures, voire se produire avant le saut situé en dessous.

Décalage des horloges

Chaque horodatage vient de l’horloge de l’hôte qui l’a écrit, et rien dans la RFC 5321 n’exige que ces horloges concordent. La RFC 5321 indique bien que « la comparabilité des champs d’en-tête Received est importante pour détecter les problèmes, en particulier les relais lents » (comparability of Received header fields is important for detecting problems, especially slow relays), et c’est pourquoi les décalages comptent. Ce qui suit est un raisonnement pratique fondé sur la façon dont les horodatages sont produits, pas une exigence de la RFC :

• Un délai négatif, où l’horodatage d’un saut ultérieur est antérieur à celui du saut situé en dessous, signifie que les deux horloges ne concordent pas. Il ne peut pas signifier que le message a remonté le temps. Signalez ce saut comme un « désaccord d’horloges » plutôt que comme un délai.
• Un petit délai entre des hôtes gérés par des opérateurs différents peut rester dans la marge d’erreur des horloges. Accordez plus de poids à un petit délai entre deux hôtes de la même infrastructure.

Ce qu’un long délai peut indiquer

Un long écart entre deux sauts signifie que le message a attendu quelque part entre ces deux réceptions. Causes connues compatibles avec un tel écart :

• Un échec temporaire suivi d’une nouvelle tentative. Après une réponse 4xx, l’hôte d’envoi conserve le message et réessaie plus tard. RFC 5321 §4.5.4.1 : « En général, l’intervalle entre les tentatives DEVRAIT être d’au moins 30 minutes ; toutefois, des stratégies plus élaborées et variables seront bénéfiques lorsque le client SMTP peut déterminer la raison de la non-livraison » (In general, the retry interval SHOULD be at least 30 minutes ; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery). C’est une recommandation, pas un plancher. Un report de remise retenté conformément à cette recommandation laisse un écart d’environ 30 minutes ou plus, mais un expéditeur qui suit une autre stratégie peut réessayer plus tôt. Voir Réglage de la livraison par le MTA.
• La liste grise. La RFC 6647 la décrit comme une « dégradation du service pour une source inconnue ou suspecte, pendant une période (généralement de l’ordre de quelques minutes ou de quelques heures) » (degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours)), et note que « certains MTA répandus ne retentent pas les livraisons échouées avant une heure ou plus » (Some popular MTAs do not retry failed delivery attempts for an hour or more). Voir liste grise.
• L’hôte inférieur qui garde le message dans sa file d’attente avant sa première tentative. L’en-tête n’en enregistre pas la raison. Voir Réglage de la livraison par le MTA pour la façon dont les files d’attente d’envoi ordonnancent le travail.

Ce qu’un long délai ne prouve pas

• Il ne vous donne pas la cause. La RFC 6647 §3 le dit clairement : « Un client ne sait pas, et n’a pas à savoir, pourquoi le code d’état d’échec temporaire est renvoyé ; une liste grise peut être en place, ou il peut s’agir d’un problème de ressources locales sur le serveur » (A client does not know, nor is it entitled to know, the reason for the temporary failure status code being returned ; greylisting could be in effect, or it could be caused by a local resource issue at the server). L’en-tête montre où le temps s’est écoulé. Le pourquoi se trouve dans les codes et textes de réponse journalisés par l’hôte qui a gardé le message : consultez ses journaux à l’aide de l’id de la ligne qu’il a écrite. Voir Procédures de dépannage de la livraison.
• Il ne prouve rien sous le premier saut de confiance. Un délai entre deux lignes auxquelles vous ne pouvez pas vous fier peut être inventé.
• Il ne dit rien de ce qui s’est passé après la ligne du haut. Le temps écoulé entre le dernier horodatage Received: et le moment où une personne a vu le message n’est pas enregistré ici.
• Il ne dit rien du dossier de placement ni du filtrage. Les lignes Received: n’enregistrent que l’acceptation et la chronologie.

Le lien entre Received et Authentication-Results

Le récepteur qui a vérifié SPF, DKIM et DMARC consigne son verdict dans un champ Authentication-Results: (RFC 8601). Les deux types de champ font face au même problème de falsification, et partagent la même solution : ne se fier qu’aux champs ajoutés à l’intérieur de votre propre frontière de confiance. La RFC 8601 §5 admet une exception : un MTA de bordure « PEUT choisir de ne pas supprimer » (MAY elect not to delete) les résultats d’un hôte amont auquel il fait explicitement confiance, « même s’ils se trouvent dans des frontières administratives totalement disjointes » (even though they exist in completely disjoint administrative boundaries).

• Authentication-Results se comporte comme un champ de trace. RFC 8601 §4.1 : il « DOIT être traité comme s’il s’agissait d’un champ d’en-tête de trace tel que défini à la section 3.6.7 de [MAIL], et par conséquent NE DOIT PAS être réordonné et DOIT être ajouté en tête du message, afin qu’il y ait généralement, à la livraison, une indication de l’endroit de la chaîne de MTA où l’authentification du message a été effectuée » (MUST be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL] and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done).
• Les copies falsifiées sont retirées à la frontière. RFC 8601 §5 : un MTA « DOIT supprimer toute occurrence découverte de ce champ d’en-tête qui prétend, par son identifiant de service d’authentification, avoir été ajoutée à l’intérieur de sa frontière de confiance mais qui ne provient pas directement d’un autre MTA de confiance » (MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA). La section 1.6 en donne la raison : « un usage valide du champ d’en-tête exige de retirer toutes ses occurrences qui prétendent être associées à l’ADMD lorsque le message entre dans l’ADMD » (valid use of the header field requires removing any occurrences of it that claim to be associated with the ADMD when the message enters the ADMD).
• La position peut servir de test de validité. La RFC 8601 §7.1 la cite parmi plusieurs approches proposées, dont aucune n’est normalisée. Le test suppose que « les MTA internes sont entièrement conformes » (internal MTAs are fully compliant) et utilisent leurs propres noms d’hôte ou le domaine de l’ADMD comme authserv-id. Dans cette hypothèse, « ce champ d’en-tête devrait toujours apparaître au-dessus d’un en-tête Received ajouté par un MTA de confiance. Cela peut servir de test de validité du champ d’en-tête » (this header field should always appear above a Received header added by a trusted MTA. This can be used as a test for header field validity).
• La confiance est une liste explicite, pas un comportement par défaut. RFC 8601 §7.1 : « Il est acceptable qu’un MUA qui connaît cette spécification dispose d’une liste explicite de noms d’hôte dont les champs d’en-tête Authentication-Results sont dignes de confiance ; cette liste devrait toutefois être vide au départ » (It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy ; however, this list should initially be empty).

Le point d’ancrage de la confiance est donc le récepteur qui a ajouté à la fois votre première ligne Received: de confiance et un champ Authentication-Results: dont il possède l’authserv-id. Lisez cette paire ensemble :

• La ligne Received: donne l’IP de connexion qu’il a observée.
• La ligne Authentication-Results: donne les verdicts qu’il a calculés pour cette connexion.

Un champ Authentication-Results: situé sous le premier saut de confiance, ou portant l’authserv-id de quelqu’un d’autre, est l’affirmation d’un tiers. Pour savoir comment les résultats d’authentification peuvent survivre à un service de transfert, voir ARC.

Même un pass de confiance a une portée limitée. RFC 8601 §7.2 : « l’existence de ce champ d’en-tête indiquant un "pass" ne rend pas le message digne de confiance » (the existence of this header field indicating a "pass" does not render the message trustworthy).

Exemple commenté

Le message ci-dessous a été envoyé par un client de la plateforme d’envoi d’example.net à un destinataire chez example.com. Les noms, identifiants et adresses sont fictifs ; les IP proviennent des plages réservées à la documentation. La section d’en-tête est présentée de haut en bas telle qu’elle apparaît dans le message livré, sans les champs autres que de trace :

Return-Path: <bounce-7731@bounce.example.net>
Received: from mx1.example.com (mx1.example.com [192.0.2.25])
        by store.example.com with LMTP id 9KcQ2
        for <reader@example.com>; Thu, 10 Sep 2026 13:31:11 +0000
Authentication-Results: mx1.example.com;
        spf=pass smtp.mailfrom=bounce.example.net;
        dkim=pass header.d=example.net;
        dmarc=pass header.from=example.net
Received: from out1.example.net (out1.example.net [198.51.100.20])
        by mx1.example.com with ESMTPS id 4Q8kx2
        for <reader@example.com>; Thu, 10 Sep 2026 15:31:10 +0200
Received: from submit.example.net (submit.example.net [198.51.100.5])
        by out1.example.net with ESMTP id A71F3;
        Thu, 10 Sep 2026 13:00:03 +0000
Received: from workstation.example.net (workstation.example.net [203.0.113.10])
        by submit.example.net with ESMTPSA id 0e2c9;
        Thu, 10 Sep 2026 09:00:02 -0400

Étape 1 : lire de bas en haut et vérifier la continuité. Le chemin est workstation → submit.example.net → out1.example.net → mx1.example.com → store.example.com. L’hôte by de chaque ligne est l’hôte from de la ligne suivante : la chaîne est continue.

Étape 2 : trouver le premier saut de confiance. L’infrastructure de réception est example.com. La ligne la plus basse écrite by un hôte example.com est la ligne de mx1.example.com. C’est le premier saut de confiance, et l’IP de connexion qu’il a observée est 198.51.100.20. Les deux lignes situées en dessous ont été écrites par des hôtes example.net. Ce sont les propres enregistrements de la plateforme d’envoi : utiles à ses opérateurs et vérifiables dans leurs journaux, mais des affirmations non vérifiées du point de vue du récepteur.

Étape 3 : rattacher Authentication-Results. Le champ Authentication-Results: porte l’authserv-id mx1.example.com et se trouve directement au-dessus de la ligne Received: écrite par mx1. Cela correspond au test de position de la RFC 8601 §7.1. Ses verdicts SPF, DKIM et DMARC sont le jugement de mx1 sur le message arrivé depuis 198.51.100.20.

Étape 4 : normaliser les horodatages et calculer les délais.

Lu en heures locales, le saut mx1 semble arriver 2,5 heures après out1. L’écart réel est de 31 minutes, et le message les a passées entre sa réception par out1.example.net et son acceptation par mx1.example.com.

Étape 5 : interpréter avec prudence. Un écart de 31 minutes correspond à un seul échec temporaire suivi d’une nouvelle tentative conforme à l’intervalle d’au moins 30 minutes recommandé par la RFC 5321. Il correspond aussi à une liste grise, ou à une attente en file sur out1. L’en-tête seul ne permet pas de les distinguer. Le journal de livraison de la plateforme d’envoi pour l’identifiant de file A71F3 sur out1 indique si une tentative a été reportée et quel était le texte de la réponse. Et comme l’horodatage d’out1 vient du côté expéditeur, un désaccord d’horloges entre les deux opérateurs fait partie de la marge.

Liste de contrôle

• Dépliez chaque ligne Received:, puis lisez de bas en haut.
• Comparez chaque hôte by avec l’hôte from de la ligne située au-dessus. Une discordance est une raison d’y regarder de plus près, pas la preuve d’un saut manquant ou faux.
• Trouvez la ligne la plus basse écrite by votre infrastructure de réception. Fiez-vous à cette ligne et à celles du dessus ; traitez tout ce qui est en dessous comme une affirmation.
• Dans le premier saut de confiance, fiez-vous à l’IP entre les parenthèses de from, pas au nom EHLO.
• Convertissez chaque horodatage en UTC avant de soustraire. Traitez les délais négatifs comme un désaccord d’horloges.
• Servez-vous d’un long délai pour localiser l’hôte qui a gardé le message, puis cherchez la cause dans les journaux de cet hôte à l’aide de l’id de la ligne.
• Lisez le champ Authentication-Results: dont l’authserv-id appartient au récepteur et qui se trouve au-dessus de la propre ligne Received: de ce récepteur.

Voir aussi

• RFC 5321 : SMTP · RFC 5322 : format des messages · RFC 5598 : architecture de l’email
• L’en-tête Authentication-Results · ARC · SPF · DKIM
• Liste grise (RFC 6647) · Réglage de la livraison par le MTA · TLS pour SMTP en pratique
• Procédures de dépannage de la livraison