En-têtes d’e-mail : lire correctement « Received » — retracer où la livraison casse

novembre 2, 2025 • février 3, 2026 • Lecture : 33 min • Views: 7

Cet article vous a aidé ?

Votre mission : expliquer pourquoi un e-mail n’est pas arrivé. Pas « il a probablement été filtré comme spam. » Pas « Microsoft/Gmail est capricieux. » Vous devez pointer le saut où le message a cessé d’être un message et a commencé à ressembler à une rumeur.

Le chemin le plus rapide passe par la chaîne Received. C’est le plus proche que possède l’e-mail d’un enregistreur de vol — désordonné, incohérent et parfois falsifié. Mais si vous le lisez comme un SRE lit une trace distribuée, vous pouvez généralement délimiter le domaine de défaillance en quelques minutes.

Modèle mental : ce qu’est vraiment un en-tête Received

L’e-mail circule saut par saut. Chaque serveur SMTP qui accepte un message et le transmet est censé apposer un nouveau en-tête Received en haut. Vous obtenez donc une pile : le saut le plus récent en haut, le plus ancien en bas.

Considérez chaque saut comme un petit contrat : « Moi, serveur X, j’ai reçu ce message de Y à l’instant T en utilisant le protocole P et je le transmets à l’étape suivante. » Le contrat est rédigé par X, pas par Y. C’est l’élément clé. Le saut qui écrit la ligne est celui que vous pouvez interroger avec des logs et des métriques.

Si vous êtes familier des traces distribuées, c’est la version e-mail d’une liste de spans sans IDs. Pas d’ID de trace global. Pas de schéma canonique. Beaucoup de ponctuation créative. Pourtant, si vous le lisez avec le bon niveau de scepticisme, c’est suffisant.

Deux règles qui vous éviteront de revenir les mains vides d’une réunion :

Les lignes Received sont des preuves seulement à l’intérieur des frontières de confiance. Tout ce qui se trouve sous votre première entrée de confiance peut être falsifié.
La plupart des cas de « mail manquant » sont en réalité des cas de « mail retardé ». Votre travail est de décider où le retard a été introduit et s’il est attendu (retry) ou pathologique (effondrement de file, blocage de politique, mauvais routage).

Faits intéressants et contexte historique (court, concret)

SMTP précède la plupart des mécanismes d’authentification modernes. Le protocole de base a été normalisé au début des années 1980 ; les extensions d’authentification sont arrivées des décennies plus tard.
Les en-têtes Received sont antérieurs au spam. Ils étaient conçus pour tracer et déboguer le routage du courrier, pas pour des environnements adverses.
Le format d’en-tête est « structuré-ish », pas strict. Les serveurs sont encouragés à ajouter des détails, vous verrez donc des clauses spécifiques aux fournisseurs et des espaces insérés de manière créative.
Les fuseaux horaires sont une source récurrente d’inepties. Les sauts peuvent afficher des heures « qui reculent » quand l’horloge d’un serveur est fausse ou utilise des décalages bizarres.
Message-ID n’est pas garanti unique. La plupart des MTA génèrent des IDs sensés, mais des clients défectueux et certains appliances réutilisent ou altèrent les IDs.
Le greylisting est devenu populaire comme tactique anti-spam à faible coût. Il retarde intentionnellement les premières tentatives de livraison ; les Received montrent souvent des écarts de retry.
SPF vérifie l’enveloppe d’expédition, pas le From visible. Les gens confondent encore cela, y compris des personnes avec le titre « Directeur ».
DKIM signe les en-têtes et le corps, mais pas toute la « vérité ». Il ne valide pas la chaîne Received ; il valide l’intégrité du contenu depuis le signataire.
Les gros fournisseurs exécutent plusieurs couches de traitement du courrier. Vous pouvez voir des sauts internes qui ne correspondent pas 1:1 à ce que vous pensez être « le serveur de mail ».

Anatomie d’une ligne Received : champs utiles, champs trompeurs

Un en-tête Received typique peut ressembler à ceci (ne vous y attachez pas ; votre réalité sera pire) :

cr0x@server:~$ sed -n '1,8p' message.headers
Received: from mail-out.example.net (mail-out.example.net [203.0.113.10])
        by mx.google.com with ESMTPS id x12-20020a17090a000000b003e000000000si1234567pja.12.2026.01.04.10.11.12
        for <user@example.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 04 Jan 2026 10:11:12 -0800 (PST)
Received: from app01.corp.example (app01.corp.example [10.20.30.40])
        by mail-out.example.net (Postfix) with ESMTPA id 4A1B2C3D4E
        for <user@example.com>; Sun, 04 Jan 2026 18:11:10 +0000 (UTC)

Ce qui compte :

« by » : le serveur qui a ajouté cette ligne. C’est votre ancre de logs. Si vous n’avez pas accès aux logs du « by », vos options de dépannage diminuent.
« from » : qui s’est connecté au « by ». Peut être un nom d’hôte + IP. Le nom d’hôte est souvent le reverse DNS ou ce que le pair a revendiqué. L’IP est plus difficile à falsifier au niveau TCP (mais NAT et proxies compliquent les choses).
Clause de protocole (with ESMTP, with ESMTPS, with LMTP) : indique si TLS a été utilisé et si une authentification a eu lieu (ESMTPA indique communément une soumission authentifiée).
Horodatage : critique pour l’analyse des délais. Traitez-le comme n’importe quel timestamp de système distribué : ne lui faites confiance que si les horloges sont sensées.
ID de file : Postfix, Exchange et d’autres apposent souvent un ID interne. Ce sont de l’or car ils se mappent directement aux logs.

Ce qui trompe souvent :

Noms fournis par le client. Certains MTA incluent ce que le client a dit en HELO/EHLO. Ce n’est pas une identité ; c’est une chaîne de caractères.
Sauts inférieurs non fiables. Tout ajout par un serveur en dehors de votre périmètre de confiance peut être fabriqué par un spammeur ou un relais défectueux.
Confiance excessive dans le format. Certains serveurs replient les lignes de manière étrange ; d’autres omettent des champs ; certains entassent tout sur une seule ligne comme s’ils étaient payés au caractère.

Blague #1 : Les en-têtes d’e-mail sont comme des chronologies d’incident : tout le monde ajoute une ligne, et pourtant ça ne répond toujours pas à « qui a touché la prod en dernier ? »

Règles d’ordonnancement : de bas en haut, avec des bords vifs

Le saut le plus ancien est en bas. Le saut le plus récent est en haut. Cela signifie que vous lisez les en-têtes Received du bas vers le haut pour suivre le trajet du message dans le temps.

Bords vifs :

Dérive d’horloge peut faire apparaître le temps comme allant à reculons. Si un serveur a cinq minutes de décalage, vous verrez des temps de transit négatifs. Ne paniquez pas ; vérifiez NTP.
La livraison locale peut ne pas ajouter une ligne Received. Parfois la remise finale est à un magasin de boîtes ou à une étape de filtrage sans nouvel en-tête.
Les passerelles peuvent écraser des sauts. Une passerelle de sécurité mail peut accepter le courrier entrant puis le réinjecter en interne, ajoutant des lignes qui ressemblent à « from gateway by internal-mx », mais vous ne verrez pas la complexité en amont.
Listes de diffusion et réexpéditeurs peuvent créer des « nouveaux » messages avec de nouveaux Message-ID et des en-têtes modifiés, tout en donnant l’impression de conserver le même contenu visible par l’utilisateur.

Frontières de confiance : quelles lignes Received vous pouvez croire

Les seuls en-têtes Received que vous devriez considérer comme fiables sont ceux ajoutés par des systèmes que vous contrôlez ou en qui vous avez confiance : votre MX, votre passerelle entrante, vos relais internes, votre service de soumission.

Tout ce qui se trouve avant le premier saut de confiance est une « chaîne soumise par l’utilisateur ». Utile, mais pas admissible. Ce n’est pas de la paranoïa ; c’est un mardi.

Approche pratique :

Identifiez le premier saut que vous contrôlez. C’est typiquement votre MX, passerelle entrante, ou l’ingress d’un fournisseur hébergé.
Marquez tout ce qui est en dessous comme chaîne non fiable.
Corrélez le saut de confiance avec les logs en utilisant l’ID de file, le Message-ID et l’horodatage.

Si vous exploitez un système qui reçoit du mail depuis Internet directement, imposez des bonnes pratiques qui rendent vos propres lignes Received utiles : incluez l’IP connectante, incluez l’info TLS quand présente, incluez l’ID de file, et gardez des horloges précises.

Retards : comment repérer la mise en file, les retries, le greylisting et la contre-pression

Les « ruptures » de livraison sont souvent simplement des périodes d’attente. Votre travail est de classifier l’attente :

1) Délai en file côté expéditeur

Symptôme : grand écart temporel entre le Received le plus bas « client → MTA expéditeur » et le saut suivant « MTA expéditeur → MX destinataire ».

Interprétation : l’expéditeur a accepté le message mais ne l’a pas délivré rapidement. Causes : congestion de la file sortante, problèmes DNS, limites de taux, blocages de politique, ou l’expéditeur étant throttlé par les destinataires.

2) Greylisting / refus temporaires

Symptôme : tentatives répétées reflétées dans les logs (pas généralement dans les en-têtes), avec un intervalle de plusieurs minutes avant acceptation. Dans les en-têtes vous pouvez voir seulement la tentative finale, avec un horodatage bien plus tard que l’heure d’envoi initiale revendiquée par l’utilisateur.

Interprétation : le destinataire a refusé les premières tentatives avec un 4xx. L’expéditeur a retenté. C’est normal-ish dans certains écosystèmes ; en pratique c’est une décision métier déguisée en SMTP.

3) Mise en file entrante à votre passerelle ou MX

Symptôme : le message est accepté par votre périmètre mais arrive tardivement dans la boîte. Les en-têtes montrent un transit rapide jusqu’à votre passerelle, puis des sauts internes « by » avec des horodatages qui progressent lentement.

Interprétation : filtrage interne, scan de contenu, contre-pression du magasin de boîtes, ou problèmes de routage interne. C’est là que vos tableaux de bord importent.

4) Blocages de politique et quarantaine

Symptôme : les en-têtes montrent une acceptation, mais l’utilisateur ne voit jamais le message. Les logs montrent qu’il a été dévié vers une quarantaine, une modération, ou retenu pour revue manuelle.

Interprétation : ce n’est pas une « rupture de livraison ». C’est une décision de politique. Traitez-la comme telle : trouvez la règle, justifiez-la, ajustez si nécessaire.

5) Suppression silencieuse (rare, mais réelle)

Les suppressions silencieuses sont moins fréquentes que la plupart des gens le pensent parce que SMTP est transactionnel. Mais elles existent : des filtres peuvent jeter, des boîtes peuvent perdre, et des systèmes mal configurés acceptent puis perdent. Cherchez l’endroit du dernier accusé de réception fiable, puis ce que le système a fait ensuite.

Signaux de sécurité autour de Received : SPF, DKIM, DMARC, ARC, et pourquoi ils importent pour les ruptures de livraison

Les en-têtes Received vous donnent le chemin. Les résultats d’authentification vous indiquent si l’histoire d’identité du message correspond à la réalité — au moins suffisamment pour que les fournisseurs acceptent.

Authentication-Results est votre ami

Beaucoup de systèmes ajoutent un en-tête Authentication-Results. Il peut inclure les évaluations SPF, DKIM, DMARC. Il est écrit par un receveur, donc dans les frontières de confiance il a de la valeur.

Ce que vous en faites :

Si SPF échoue, vérifiez l’enregistrement SPF du domaine d’enveloppe et l’alignement de l’IP d’envoi.
Si DKIM échoue, vérifiez le domaine signataire, le selector, les problèmes de canonicalization, et si un intermédiaire a modifié le corps/les en-têtes.
Si DMARC échoue, vérifiez l’alignement entre le domaine From et les domaines SPF/DKIM ; vérifiez aussi la politique (reject/quarantine/none).

ARC peut expliquer « le forwarding a cassé mon DMARC »

Les réexpéditeurs et listes de diffusion cassent souvent DKIM (en modifiant le message) et SPF (car ils renvoient depuis leur propre IP). ARC (Authenticated Received Chain) est un moyen pour les intermédiaires de préserver les résultats d’auth upstream. Lors du diagnostic de ruptures impliquant du forwarding, la présence et la validation d’ARC peuvent faire la différence entre « mystérieux » et « évident ».

Utilisez les signaux d’auth pour décider si la rupture vient du transport ou de la politique. Si le transport semble ok mais que DMARC échoue avec une politique stricte, vous ne debuggez pas le réseau. Vous debuggez l’identité et l’alignement.

Méthode de diagnostic rapide

Vous voulez de la vitesse ? Arrêtez de lire tout le roman d’en-têtes. Faites ceci :

Première étape : identifiez le dernier saut « by » de confiance

Localisez la ligne Received la plus haute écrite par le système destinataire en qui vous avez confiance (votre MX / passerelle / ingress de fournisseur).
Extraire : horodatage, ID de file (si présent), IP connectante, et « for <recipient> ».
Décision : si vous n’avez pas de saut de confiance, vous n’avez pas de preuve. Demandez à l’expéditeur les en-têtes complets depuis son élément envoyé, ou demandez les logs à son admin.

Deuxième étape : classifiez le domaine de défaillance

Non accepté par votre périmètre : pas de ligne Received de confiance → côté expéditeur ou transport Internet (DNS, routage, blocages de réputation).
Accepté par le périmètre mais pas délivré : Received de confiance existe → pipeline interne (filtrage, boîte, routage, quarantaine).
Délivré mais « manquant » : les en-têtes montrent la remise finale mais l’utilisateur ne le trouve pas → règles client, recherche de boîte, dossiers, ou archivage aval.

Troisième étape : mesurez les délais saut par saut

Lisez les en-têtes Received du bas vers le haut dans le segment de confiance.
Calculez les deltas temporels entre sauts adjacents.
Décision : le saut avec le plus grand delta est où vous cherchez pour la mise en file, le throttling ou les retenues.

Quatrième étape : corrélez avec les logs en utilisant les IDs

Queue IDs, Message-ID et adresse destinataire sont vos clés de jointure. Choisissez-en deux ; utilisez trois si possible.

Cinquième étape : décidez ce que vous dites aux humains

Ne dites pas « l’e-mail est en retard. » Dites « accepté par notre passerelle à 10:11:12 PST, retenu en scan de contenu pendant 34 minutes à cause d’un backlog du bac à sable des pièces jointes, puis délivré. » Les gens détestent l’incertitude plus que les mauvaises nouvelles.

Tâches pratiques (avec commandes, signification des sorties et décisions)

Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter sur des MTA Linux courants et des boîtes à outils. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Extract and view just the Received chain (quick sanity)

cr0x@server:~$ awk 'BEGIN{RS="";FS="\n"} {for(i=1;i<=NF;i++) if($i ~ /^Received:/) print $i}' message.eml
Received: from app01.corp.example (app01.corp.example [10.20.30.40]) by mail-out.example.net (Postfix) with ESMTPA id 4A1B2C3D4E for <user@example.com>; Sun, 04 Jan 2026 18:11:10 +0000 (UTC)
Received: from mail-out.example.net (mail-out.example.net [203.0.113.10]) by mx.google.com with ESMTPS id x12-... for <user@example.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jan 2026 10:11:12 -0800 (PST)

Ce que cela signifie : Vous avez une chaîne courte ; probablement seulement deux sauts enregistrés dans l’exemple. En vrai, vous en verrez plus.

Décision : Si la chaîne est étonnamment courte, suspectez que le message a été généré à l’intérieur d’un fournisseur, ou que des en-têtes ont été retirés par une passerelle ou un client. Demandez les « en-têtes originaux complets » depuis l’UI de la boîte, pas une copie transférée.

Task 2: Identify the first trusted hop (pattern match your MX/gateway)

cr0x@server:~$ grep -n '^Received:' -n message.eml | head
12:Received: from mail-out.example.net (mail-out.example.net [203.0.113.10]) by mx-inbound.corp.example with ESMTPS id 9F3A2B1C for <user@corp.example>; Sun, 04 Jan 2026 18:11:12 +0000 (UTC)
18:Received: from unknown (HELO sender.example) (198.51.100.23) by mail-out.example.net with SMTP; Sun, 04 Jan 2026 18:11:10 +0000 (UTC)

Ce que cela signifie : La ligne « by mx-inbound.corp.example » est votre entrée d’ingress de confiance. Tout ce qui est en dessous peut être réel ou fictif.

Décision : Commencez la corrélation à partir de cet ID de file (9F3A2B1C) et de cet horodatage. Ignorez l’« unknown (HELO …) » en amont pour les décisions de blâme, sauf s’il correspond à d’autres preuves.

Task 3: Parse timestamps and compute hop delays (cheap “distributed trace”)

cr0x@server:~$ grep '^Received:' -n message.eml
12:Received: ...; Sun, 04 Jan 2026 18:11:12 +0000 (UTC)
18:Received: ...; Sun, 04 Jan 2026 18:11:10 +0000 (UTC)

Ce que cela signifie : Deux secondes entre le relay expéditeur et votre MX. C’est normal.

Décision : Si vous voyez des minutes ou des heures entre sauts de confiance adjacents, c’est votre goulot d’étranglement. Allez sur le MTA/passerelle responsable du saut ultérieur et vérifiez les files et les refus.

Task 4: On Postfix, search logs by queue ID

cr0x@mailgw01:~$ sudo grep '9F3A2B1C' /var/log/mail.log | tail -n 5
Jan  4 18:11:12 mailgw01 postfix/smtpd[22110]: 9F3A2B1C: client=mail-out.example.net[203.0.113.10], sasl_method=PLAIN, sasl_username=
Jan  4 18:11:13 mailgw01 postfix/cleanup[22122]: 9F3A2B1C: message-id=<CAO9z9kGx12345@mail-out.example.net>
Jan  4 18:11:14 mailgw01 postfix/qmgr[1211]: 9F3A2B1C: from=<noreply@example.net>, size=48212, nrcpt=1 (queue active)
Jan  4 18:47:02 mailgw01 postfix/smtp[23110]: 9F3A2B1C: to=<user@corp.example>, relay=mbx01.corp.example[10.0.10.25]:25, delay=2149, delays=0.2/0.1/2130/18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7C8D9E0F)
Jan  4 18:47:02 mailgw01 postfix/qmgr[1211]: 9F3A2B1C: removed

Ce que cela signifie : Le message est principalement resté en file avant la livraison à mbx01. La répartition delays=0.2/0.1/2130/18 indique le temps dans différentes phases ; le troisième nombre énorme est la piste fumante.

Décision : Arrêtez d’accuser l’expéditeur. Investiguer pourquoi votre passerelle a retenu le message ~35 minutes : intégration du filtre de contenu, limitation de débit, réponses lentes de la boîte en aval, ou retenue de politique.

Task 5: Check the Postfix queue for backlog

cr0x@mailgw01:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9F3A2B1C       48212 Sun Jan  4 18:11:12  noreply@example.net
                                         user@corp.example
A1B2C3D4        1200 Sun Jan  4 18:12:01  alerts@vendor.example
                                         oncall@corp.example

Ce que cela signifie : Il y a une file active. La présence de plusieurs messages autour du même horaire suggère un retard systémique, pas un incident isolé.

Décision : Si la file augmente et que l’ancienneté augmente, traitez comme incident : vérifiez la disponibilité en aval, la latence du filtre de contenu, la résolution DNS et les limites de taux.

Task 6: Postfix queue age distribution (is it “old mail”?)

cr0x@mailgw01:~$ sudo postqueue -p | awk 'BEGIN{count=0} /^[A-F0-9]/ {id=$1} /[0-9][0-9]:[0-9][0-9]:[0-9][0-9]/ {count++} END{print "queue_entries="count}'
queue_entries=42

Ce que cela signifie : Compte rapide et approximatif des entrées en file. Pas parfait, mais c’est un seuil d’alerte.

Décision : Si les entrées explosent par rapport à la normale, vérifiez pourquoi le mail ne s’écoule pas : timeouts de relay=, échecs de handshake TLS, ou service de filtre lent.

Task 7: Verify DNS for recipient MX and sender reverse DNS (reputation basics)

cr0x@server:~$ dig +short MX corp.example
10 mx-inbound.corp.example.

cr0x@server:~$ dig +short A mx-inbound.corp.example
192.0.2.55

cr0x@server:~$ dig +short -x 203.0.113.10
mail-out.example.net.

Ce que cela signifie : MX est résolvable ; l’expéditeur a un PTR. L’absence de PTR ou des noms non concordants peuvent déclencher des réceptions plus strictes et conduire à des échecs temporaires ou placements en spam.

Décision : Si la résolution MX est instable ou si le PTR manque, corrigez le DNS. Si vous ne pouvez pas corriger le PTR de l’expéditeur, attendez-vous à des variations de livraison et utilisez des voies de soumission authentifiées.

Task 8: Check SPF alignment for the envelope sender domain

cr0x@server:~$ dig +short TXT example.net | sed -n '1,3p'
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

Ce que cela signifie : Le domaine indique quelles IP peuvent envoyer. Si votre Received montre une IP d’envoi différente, SPF échouera chez les destinataires qui appliquent la politique.

Décision : Si SPF n’inclut pas les IPs sortantes réelles, mettez à jour SPF. Si l’expéditeur utilise un tiers, assurez-vous qu’il est inclus et ne dépasse pas les limites de requêtes DNS.

Task 9: Inspect Authentication-Results from the recipient side

cr0x@server:~$ grep -i '^Authentication-Results:' -n message.eml | head -n 2
25:Authentication-Results: mx-inbound.corp.example; spf=pass smtp.mailfrom=noreply@example.net; dkim=pass header.d=example.net; dmarc=pass header.from=example.net

Ce que cela signifie : Le transport peut encore échouer, mais les contrôles d’identité sont passés. Cela oriente l’analyse loin d’un rejet DMARC et vers le routage, la mise en file ou le filtrage de contenu.

Décision : Si DMARC échoue et que la politique est stricte, ne perdez pas des heures sur les traces réseau. Corrigez l’alignement ou ajustez la politique pour les expéditeurs légitimes.

Task 10: On Exchange (or Exchange-like logs), grep message tracking (Linux collector example)

cr0x@loghost:~$ grep -R "CAO9z9kGx12345@mail-out.example.net" /var/log/exchange-message-tracking.log | tail -n 3
2026-01-04T18:11:12Z,RECEIVE,SMTP,MBX01,user@corp.example,CAO9z9kGx12345@mail-out.example.net,192.0.2.55
2026-01-04T18:45:50Z,AGENTINFO,TRANSPORT,MBX01,user@corp.example,CAO9z9kGx12345@mail-out.example.net,ContentFilter=SandboxWait
2026-01-04T18:47:02Z,DELIVER,STOREDRIVER,MBX01,user@corp.example,CAO9z9kGx12345@mail-out.example.net,Inbox

Ce que cela signifie : Le message a été reçu rapidement, puis est resté en attente pour sandboxing. C’est un retard de traitement interne.

Décision : Scalez ou ajustez l’étape de sandbox/AV, ou exonérez les flux à faible risque si le métier le tolère. Demander à l’expéditeur de « renvoyer » n’est pas une stratégie.

Task 11: Confirm TLS negotiation failures when a hop shows ESMTPS but delivery stalls

cr0x@mailgw01:~$ sudo grep -E "TLS|handshake|SSL" /var/log/mail.log | tail -n 5
Jan  4 18:20:11 mailgw01 postfix/smtp[24001]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading
Jan  4 18:20:11 mailgw01 postfix/smtp[24001]: warning: TLS policy lookup failed
Jan  4 18:20:11 mailgw01 postfix/smtp[24001]: warning: TLS handshake failed for mbx01.corp.example[10.0.10.25]:25: unexpected EOF
Jan  4 18:20:12 mailgw01 postfix/smtp[24001]: 9F3A2B1C: to=<user@corp.example>, relay=mbx01.corp.example[10.0.10.25]:25, delay=540, delays=0.2/0.1/520/20, dsn=4.4.2, status=deferred (lost connection with mbx01.corp.example[10.0.10.25] while sending end of data -- message may be sent more than once)
Jan  4 18:20:12 mailgw01 postfix/qmgr[1211]: 9F3A2B1C: deferred: lost connection with mbx01.corp.example[10.0.10.25] while sending end of data

Ce que cela signifie : Votre passerelle ne peut pas compléter TLS ou la connexion avec l’hôte en aval. Cela provoquera des reports et de longues files, que les utilisateurs interpréteront comme un « e-mail disparu ».

Décision : Corrigez la politique TLS, les certificats ou les resets du load balancer. Si nécessaire, assouplissez temporairement l’application TLS en interne pendant la correction (prudemment, avec mesures compensatoires).

Task 12: Validate local system time and NTP (stop time-travel debugging)

cr0x@mailgw01:~$ timedatectl
               Local time: Sun 2026-01-04 18:52:10 UTC
           Universal time: Sun 2026-01-04 18:52:10 UTC
                 RTC time: Sun 2026-01-04 18:52:10
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est saine. Si elle ne l’était pas, les timestamps Received deviennent peu fiables et vous poursuivriez le mauvais saut.

Décision : Si l’horloge n’est pas synchronisée, corrigez NTP d’abord. Puis réévaluez la chronologie des en-têtes.

Task 13: Confirm whether a message is quarantined (example: local mail gateway quarantine DB/log)

cr0x@mailgw01:~$ sudo grep -R "CAO9z9kGx12345@mail-out.example.net" /var/log/mailgw/quarantine.log | tail -n 2
2026-01-04T18:12:02Z action=quarantine reason="AttachmentSandboxPending" queue_id=9F3A2B1C msgid=CAO9z9kGx12345@mail-out.example.net
2026-01-04T18:46:55Z action=release reason="SandboxVerdictClean" queue_id=9F3A2B1C msgid=CAO9z9kGx12345@mail-out.example.net

Ce que cela signifie : Le message n’a pas « échoué ». Il a été retenu. Vous avez désormais une explication claire et un réglage possible.

Décision : Si la quarantaine est trop lente pour les besoins métier, scalez le bac à sable ou ajustez la politique pour les expéditeurs et types de fichiers de confiance.

Task 14: Track a message using Message-ID across multiple hosts (grep + ssh)

cr0x@ops:~$ for h in mailgw01 mailgw02 mbx01; do echo "== $h =="; ssh $h "sudo grep -R \"CAO9z9kGx12345@mail-out.example.net\" /var/log/mail.log | tail -n 2"; done
== mailgw01 ==
Jan  4 18:11:13 mailgw01 postfix/cleanup[22122]: 9F3A2B1C: message-id=<CAO9z9kGx12345@mail-out.example.net>
Jan  4 18:47:02 mailgw01 postfix/smtp[23110]: 9F3A2B1C: to=<user@corp.example>, relay=mbx01.corp.example[10.0.10.25]:25, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7C8D9E0F)
== mailgw02 ==
== mbx01 ==
Jan  4 18:47:02 mbx01 postfix/smtpd[18001]: 7C8D9E0F: client=mailgw01.corp.example[10.0.10.5]
Jan  4 18:47:03 mbx01 postfix/local[18012]: 7C8D9E0F: to=<user>, orig_to=<user@corp.example>, relay=local, status=sent (delivered to mailbox)

Ce que cela signifie : Trace de bout en bout dans votre parc. L’absence sur mailgw02 suggère que le routage ne l’a pas impliqué.

Décision : Si le Message-ID apparaît à l’ingress mais pas en boîte, concentrez-vous sur l’étape relais. S’il apparaît en boîte et que l’utilisateur ne le trouve pas, pivotez vers les règles client, le classement de dossiers et l’indexation de recherche.

Task 15: Inspect content filter latency (example: amavis/milter stats log)

cr0x@mailgw01:~$ sudo grep -E "milter|amavis|scan time" /var/log/mail.log | tail -n 5
Jan  4 18:12:05 mailgw01 amavis[3101]: (03101-02) Passed CLEAN, [203.0.113.10] [203.0.113.10] <noreply@example.net> -> <user@corp.example>, Queue-ID: 9F3A2B1C, Message-ID: <CAO9z9kGx12345@mail-out.example.net>, Hits: -, size: 48212, queued_as: 9F3A2B1C, 92 ms
Jan  4 18:45:49 mailgw01 milter-sandbox[4021]: queue_id=9F3A2B1C verdict=pending wait=2010s
Jan  4 18:46:55 mailgw01 milter-sandbox[4021]: queue_id=9F3A2B1C verdict=clean wait=2066s

Ce que cela signifie : Le scan AV est rapide ; le bac à sable est le goulot et il l’indique explicitement.

Décision : Ajustez la concurrence du bac à sable, réduisez ce qui est sandboxé, ou implémentez des patterns de livraison asynchrone si votre passerelle le permet (livrer puis réparer, si la politique l’autorise).

Task 16: Verify that the user’s mailbox rules didn’t “eat” the mail (server-side rule audit example)

cr0x@mbx01:~$ sudo grep -R "user@corp.example" /var/log/mailbox-rules.log | tail -n 5
2026-01-04T18:47:05Z user=user@corp.example rule="Move vendor mail" match="From contains example.net" action="move" folder="Vendors"
2026-01-04T18:47:05Z user=user@corp.example msgid=CAO9z9kGx12345@mail-out.example.net result="moved" folder="Vendors"

Ce que cela signifie : La livraison a réussi ; la visibilité a échoué. Le message est dans un dossier différent.

Décision : Cessez de traiter ça comme un incident MTA. Aidez l’utilisateur à corriger les règles ou ajustez les paramètres par défaut de l’entreprise.

Trois mini-récits d’entreprise issus des tranchées

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Le ticket disait : « L’e-mail de notre processeur de paiement n’arrive pas. Ça doit être leur panne. » Il venait des finances, donc urgence, ambiguïté et une pièce jointe avec invitation au calendrier.

Le junior admin a fait ce que font les juniors quand la salle est bruyante : il a fixé la ligne Received la plus haute dans le message que le processeur avait transféré comme preuve. Elle montrait le nom d’hôte du processeur, puis rien qui ressemble à notre environnement. Ils ont conclu : « Nous ne l’avons jamais reçu. Problème du processeur. » Ils avaient à moitié raison et entièrement tort, de la seule façon qui compte.

Nous avons demandé les en-têtes d’un message qui est arrivé plus tôt dans la journée et comparé les chaînes. Le mail manquant n’était pas manquant ; il atteignait notre passerelle périmétrique et était mis en quarantaine silencieusement à cause d’un nouveau type de pièce jointe. Notre passerelle avait une retenue de politique qui ne générait pas de notifications visibles pour les expéditeurs externes, parce que quelqu’un s’était déjà plaint des « trop nombreux e-mails de quarantaine ». Cette personne travaillait dans un autre service maintenant, naturellement.

La mauvaise hypothèse était : « si ce n’est pas dans la boîte, nous ne l’avons pas reçu. » La chaîne Received depuis notre passerelle de confiance a prouvé que nous l’avions. Les logs ont montré l’ID de file, l’action de quarantaine et que la libération n’avait pas eu lieu car le service de sandbox était tombé. Cette dernière partie était la vraie panne — et elle était chez nous.

Nous avons restauré le sandbox, libéré les messages mis en quarantaine, et pris une décision durable : la quarantaine sans notification est une dette opérationnelle. Parfois nécessaire, mais alors vous devez des tableaux de bord et des alertes, sinon les utilisateurs brandiront des fourches et vous l’aurez bien mérité.

Mini-récit 2 : L’optimisation qui s’est retournée contre nous

Une entreprise assez grosse voulait « optimiser la latence de la sécurité e-mail ». Le plan semblait raisonnable : passer du sandboxing synchrone des pièces jointes (retenir le mail jusqu’au verdict) à un pipeline plus rapide en augmentant le parallélisme et en durcissant les politiques TLS. Plus rapide et plus sûr. Qu’est-ce qui pouvait mal tourner ?

Le changement est arrivé un vendredi, évidemment. Le parallélisme a augmenté, ce qui a augmenté la charge CPU sur la passerelle. Les politiques TLS se sont durcies, ce qui a augmenté les échecs de handshake avec un relais de boîte interne qui avait une configuration de suites de chiffrement ancienne. La passerelle a commencé à différer les livraisons, mais continuait d’accepter le courrier entrant, l’entassant en file comme des assiettes à un buffet.

Les en-têtes Received étaient parlants : les horodatages d’acceptation entrante étaient normaux, mais le passage interne vers les serveurs de boîte retardait de 20–60 minutes. Les utilisateurs ont accusé les expéditeurs externes, les expéditeurs ont accusé notre réputation, et la direction a accusé « l’e-mail » en général. Pendant ce temps la file a grossi, et le disque de la passerelle s’est rempli, parce que les files sont du stockage que vous le vouliez ou non.

Nous avons rétabli la tolérance TLS interne, réduit le parallélisme du sandbox pour correspondre à la réalité CPU, et ajouté un seuil d’alerte sur la taille de la file liée au paging. La leçon douloureuse : l’optimisation des performances dans les systèmes mail est comme l’optimisation d’une base de données. Vous pouvez déplacer le goulot, mais aussi créer un nouveau mode de panne avec une meilleure communication.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Autre lieu, autre ambiance : ils avaient un runbook de « traçage mail » dont personne ne se vantait. C’était une page d’étapes : extraire la chaîne Received, localiser le premier saut de confiance, corréler l’ID de file, vérifier la quarantaine, confirmer la livraison et le placement en boîte. Ce n’était pas excitant. C’était correct.

Un après-midi, un VIP a râlé qu’un amendement de contrat « n’était jamais arrivé » et menaçait d’escalade. L’on-call a suivi le runbook. En cinq minutes ils avaient l’ID de file de la passerelle, l’horodatage exact d’acceptation et l’ID du relais interne montrant la livraison finale au magasin de boîtes.

Puis ils ont vérifié les logs de règles de boîte : le message avait été déplacé dans un dossier « Juridique » et marqué comme lu par un client mobile. Ce n’était pas un problème de MTA. C’était un problème de workflow utilisateur. L’on-call a fourni une explication claire : « Délivré à 14:03 UTC, déplacé par la règle X vers le dossier Y. » L’escalade s’est évaporée.

La pratique qui a sauvé la mise n’était pas un outil sophistiqué. C’était une journalisation cohérente, des horloges qui ne mentent pas, et l’habitude de corréler des IDs au lieu de deviner. La fiabilité est souvent juste l’absence de drame obtenue par une bonne hygiène.

Erreurs courantes : symptômes → cause racine → correctif

Symptôme : « Les en-têtes Received montrent une livraison, mais l’utilisateur dit qu’il ne l’a jamais reçu. »
Cause racine : placement visible par l’utilisateur (règles, boîte ciblée, dossier spam, déplacement côté serveur, archivage, client mobile).
Correctif : Corrélez le saut de confiance final + logs de remise en boîte ; vérifiez les actions de règles ; confirmez le chemin du dossier et le comportement du client ; désactivez les règles problématiques.
Symptôme : Les horodatages reculent entre les sauts.
Cause racine : dérive d’horloge ou mauvaise configuration de fuseau horaire sur un serveur ; parfois pliage d’en-tête mal interprété par les outils.
Correctif : Vérifiez NTP (timedatectl) ; corrigez le fuseau ; revérifiez avec les en-têtes bruts.
Symptôme : Pas de ligne Received de confiance depuis votre périmètre.
Cause racine : Vous n’avez jamais accepté le message ; l’expéditeur ne vous a pas atteint ; MX DNS erroné ; blocage de politique en amont ; expéditeur ayant envoyé au mauvais domaine.
Correctif : Vérifiez les enregistrements MX ; confirmez l’adresse destinataire ; demandez à l’expéditeur les logs SMTP / codes de rebond ; vérifiez vos logs périmètre pour des tentatives de connexion.
Symptôme : Grand délai entre acceptation sur votre MX et livraison en boîte.
Cause racine : backlog du pipeline entrant : filtre de contenu, sandbox, AV, DLP, lenteur du magasin de boîtes, échecs TLS du relais interne.
Correctif : Identifiez quel saut interne a introduit le délai ; vérifiez la profondeur de file ; scalez le goulot ; corrigez TLS/cipher mismatch ; ajoutez des alertes sur l’âge des files.
Symptôme : L’expéditeur prétend « nous avons eu un 250 OK » mais vous ne trouvez pas le message.
Cause racine : Le 250 provenait d’un relais intermédiaire (pas de vous), ou vous avez accepté puis mis en quarantaine/réécrit, ou les logs ont été perdus par rotation.
Correctif : Faites correspondre le serveur qui a émis le 250 avec le hop « by » dans Received ; demandez leurs logs ; assurez-vous de conserver les logs mail assez longtemps pour les délais métier.
Symptôme : Certains domaines externes échouent ou retardent systématiquement, d’autres fonctionnent bien.
Cause racine : problèmes de réputation/limitation, mismatch de politique TLS, application DMARC, ou faux positifs de filtre de contenu propres au patron d’expédition.
Correctif : Inspectez Authentication-Results ; vérifiez les logs TLS ; coordonnez l’allowlisting prudemment (préférez les validations DKIM) ; ajustez les règles de contenu avec preuve.
Symptôme : Mail transféré depuis un compte personnel n’arrive pas, mais le mail direct arrive.
Cause racine : SPF échoue et DKIM casse lors du forwarding ; la politique DMARC reject/quarantine est appliquée chez le destinataire.
Correctif : Encouragez l’envoi direct ; implémentez un traitement ARC-aware ; pour les réexpéditeurs internes, utilisez SRS et préservez DKIM si possible.
Symptôme : Plusieurs copies dupliquées arrivent des heures plus tard.
Cause racine : L’expéditeur retente après une livraison incertaine (connexion perdue après DATA), ou une passerelle a réinjecté sur timeout.
Correctif : Vérifiez les logs pour « message may be sent more than once » ; corrigez la stabilité des connexions en aval ; assurez un filtrage idempotent si faisable.

Listes de contrôle / plan étape par étape

Étape par étape : tracer un message unique manquant

Obtenez l’artefact correct : les en-têtes originaux complets depuis l’UI de la boîte du destinataire (pas un message transféré). Si possible, obtenez la source brute.
Extraites les lignes Received et lisez du bas vers le haut.
Identifiez le premier « by » de confiance (votre MX/passerelle/ingress fournisseur). Tout ce qui est en dessous est contexte non fiable.
Enregistrez les clés de jointure : ID de file, Message-ID, adresse destinataire, horodatages.
Vérifiez les logs périmètre pour acceptations, rejets ou reports autour de l’horodatage.
Vérifiez l’état des files (profondeur + ancienneté). Déterminez si c’est systémique.
Vérifiez le pipeline de contenu (AV/sandbox/DLP) pour des retenues et latences.
Vérifiez le handoff du relais interne pour échecs TLS, timeouts ou contre-pression.
Vérifiez les logs de livraison en boîte et le placement final (dossiers/règles/quarantaine).
Rédigez l’explication humaine : « Accepté à X, retardé à Y parce que Z, délivré à T. » Incluez horaires et systèmes.

Étape par étape : décider si c’est côté expéditeur ou récepteur

Si vous n’avez aucune ligne Received de confiance provenant de votre infrastructure : traitez comme côté expéditeur ou routage Internet. Demandez des codes de rebond ou leurs logs MTA.
Si vous avez une acceptation de confiance mais pas de livraison en boîte : mode incident côté récepteur.
Si vous avez une livraison en boîte mais que l’utilisateur ne le trouve pas : traitez comme problème de visibilité/règles. N’appelez pas l’équipe MTA pour un problème d’UI.

Checklist opérationnelle : rendre les en-têtes Received utiles dans votre environnement

Gardez NTP sain partout où le mail est touché.
Assurez-vous que vos MTAs loggent les queue IDs et Message-IDs et conservent les logs assez longtemps pour les enquêtes métier.
Exposer la profondeur de file et l’âge du message le plus ancien comme métriques avec seuils de paging.
Instrumentez les filtres de contenu avec latence et métriques de verdict.
Documentez les frontières de confiance : quels sauts sont à vous, quels sont des fournisseurs, quels sont l’Internet public.

Blague #2 : La façon la plus rapide de trouver un goulot d’e-mail est de programmer une réunion à ce sujet — le courrier arrivera pendant la réunion, juste pour vous narguer.

FAQ

1) Pourquoi les en-têtes Received apparaissent-ils « à l’envers » ?

Parce que chaque serveur préfixe sa ligne Received en haut. Le trajet du message dans le temps se lit donc de bas en haut.

2) Les en-têtes Received peuvent-ils être falsifiés ?

Tout ce qui se trouve en dehors de votre frontière de confiance peut être falsifié parce qu’un expéditeur peut ajouter des en-têtes arbitraires. La ligne Received ajoutée par votre premier MX/passerelle de confiance est l’ancre sur laquelle vous vous appuyez.

3) Quelle est la différence entre « from » et « by » dans un Received ?

by est le serveur qui a écrit la ligne. from est le pair qui s’est connecté à lui. Lors du dépannage, « by » est l’endroit où vous cherchez les logs.

4) Quel identifiant est le meilleur pour la corrélation des logs : Message-ID ou queue ID ?

L’ID de file est le meilleur au sein d’un seul MTA car il est local et garanti pour se mapper aux logs. Message-ID est meilleur entre systèmes, mais peut manquer ou être dupliqué. Utilisez les deux si possible.

5) Je vois ESMTPA dans une ligne Received. Que cela m’indique-t-il ?

Cela indique souvent une soumission authentifiée (un client s’est connecté). Cela signifie généralement que le mail est entré dans le système de l’expéditeur via un service de soumission, pas un relais ouvert. Ça réduit aussi la recherche au host de soumission.

6) L’expéditeur affirme avoir reçu « 250 OK ». Cela ne prouve-t-il pas la livraison ?

Ça prouve l’acceptation par un serveur SMTP, pas nécessairement la livraison finale dans la boîte destinataire. Vous devez faire correspondre quel serveur a émis le 250 à un hop « by » dans Received, puis tracer la suite.

7) Comment savoir si le retard est dû au greylisting ?

Les en-têtes seules ne montreront souvent pas les retries ; les logs le feront. Cherchez des 4xx dans les logs du destinataire ou de l’expéditeur, suivis d’une livraison réussie plus tard. L’heure d’envoi indiquée par l’utilisateur peut être bien antérieure à votre heure d’acceptation.

8) Pourquoi voit-on parfois beaucoup de sauts internes chez les gros fournisseurs ?

Les gros fournisseurs pipeline le courrier à travers plusieurs services : MTAs d’edge, filtrage anti-spam, moteurs de politique, livraison en boîte. Chaque couche peut ajouter une ligne Received, et chacune est un point de possible délai.

9) Et s’il n’y a aucun en-tête Received ?

C’est inhabituel pour le mail Internet. Vous regardez peut-être un fragment de message, un copier-coller, ou un message transféré où le client a remplacé les en-têtes. Obtenez la source brute via « voir l’original » de la boîte.

10) Comment SPF/DKIM/DMARC se rapportent-ils à « où la livraison casse » ?

Si DMARC échoue avec une politique stricte, la rupture est une application de politique côté récepteur, pas le transport. Les en-têtes Received montrent le chemin, mais les résultats d’auth expliquent pourquoi un saut a refusé, mis en quarantaine ou classé en spam.

Conclusion : prochaines étapes réalisables cette semaine

Le dépannage de la livraison d’e-mail devient beaucoup moins mystique quand vous traitez les en-têtes Received comme une trace de saut et les logs comme votre vérité terrain. Ancrez-vous sur le premier saut de confiance, mesurez les délais entre sauts, et corrélez avec queue ID et Message-ID. Puis parlez en horaires et systèmes, pas en impressions.

Prochaines étapes pratiques :

Rédigez (ou empruntez) un runbook d’une page reprenant la méthode de diagnostic rapide et le plan étape par étape ci-dessus.
Ajoutez deux métriques à votre monitoring : profondeur de file et âge du message le plus ancien sur chaque étape de traitement du mail que vous possédez.
Auditez votre comportement de quarantaine/retenue : si vous retenez du mail, vous avez besoin de visibilité et de notifications, sinon vous récolterez des incidents futurs.
Vérifiez la synchronisation horaire sur MTAs, passerelles et serveurs de boîtes. La dérive transforme l’analyse d’en-têtes en art de la performance.

« L’espoir n’est pas une stratégie. » — idée paraphrasée couramment utilisée dans les cercles opérations et fiabilité