Les en-têtes d’un email contiennent toute l’histoire de son parcours : qui l’a envoyé, par quels serveurs il est passé, si l’authentification a réussi, et pourquoi il a atterri en spam. Savoir les lire, c’est savoir diagnostiquer.

Comment accéder aux en-têtes

  • Gmail : ouvrez l’email → ⋮ → “Afficher l’original”
  • Outlook : ouvrez l’email → Fichier → Propriétés → “En-têtes Internet”
  • Apple Mail : Présentation → Message → Tous les en-têtes
  • Thunderbird : Affichage → Code source du message

Ou collez-les directement dans le Header Analyzer de Sender Audit pour une analyse visuelle.

Les en-têtes essentiels

From:

L’adresse affichée dans le client mail du destinataire. C’est le domaine que DMARC protège.

From: Simon Bressier <simon@example.com>

Attention : le From: est facilement falsifiable. C’est exactement ce que SPF, DKIM et DMARC combattent.

Return-Path: (Envelope From)

L’adresse utilisée pour les bounces (messages de non-délivrance). C’est ce domaine que SPF vérifie.

Return-Path: <bounces+12345@esp-domain.com>

Si le Return-Path est un domaine différent du From:, l’alignement SPF pour DMARC échouera. C’est très courant avec les ESP. C’est pourquoi DKIM est indispensable en complément.

Received:

Chaque serveur qui manipule l’email ajoute un en-tête Received:. Ils se lisent de bas en haut : le premier Received: (en bas) est le serveur d’origine.

Received: from mx2.dest.com (mx2.dest.com [203.0.113.50])
    by mx1.dest.com with ESMTPS id abc123
    for <user@dest.com>; Sat, 26 Apr 2026 10:30:00 +0000

Received: from smtp.esp.com (smtp.esp.com [198.51.100.42])
    by mx2.dest.com with ESMTPS id def456
    for <user@dest.com>; Sat, 26 Apr 2026 10:29:58 +0000

Chaque Received: contient :

  • from : le serveur qui envoie
  • by : le serveur qui reçoit
  • with : le protocole utilisé (ESMTP, ESMTPS = avec TLS)
  • for : le destinataire
  • date : l’horodatage

Si vous voyez ESMTP sans le S, l’email a transité sans TLS sur ce tronçon.

Authentication-Results:

Ajouté par le serveur de réception, c’est le verdict d’authentification :

Authentication-Results: mx.google.com;
    dkim=pass header.i=@example.com header.s=selector1 header.b=xjAWgYt1;
    spf=pass (google.com: domain of bounce@esp.com designates 198.51.100.42 as permitted sender) smtp.mailfrom=bounce@esp.com;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
RésultatSignification
dkim=passLa signature DKIM est valide
spf=passL’IP est autorisée par le record SPF
dmarc=passL’alignement DMARC est vérifié
dis=NONEDisposition : aucune action (pas de quarantine/reject)

DKIM-Signature:

La signature cryptographique elle-même. Pour une analyse détaillée de chaque champ, consultez Anatomie d’une signature DKIM.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=selector1;
    h=from:to:subject:date;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=xjAWgYt1qLwxzeO4C58+...

En-têtes avancés

ARC-* (Authenticated Received Chain)

Quand un email est transféré (forwarding, mailing list), SPF casse souvent car l’IP du forwarder n’est pas dans le SPF de l’expéditeur original. DKIM peut aussi casser si le message est modifié (ajout de footer, par exemple).

ARC (RFC 8617) résout ce problème en créant une chaîne de confiance. Chaque serveur intermédiaire ajoute :

  • ARC-Seal: : signature du serveur intermédiaire
  • ARC-Message-Signature: : signature du message au moment du passage
  • ARC-Authentication-Results: : résultats d’authentification à ce point

Le serveur final peut remonter la chaîne ARC pour vérifier que les résultats d’authentification étaient bons au départ, même si SPF/DKIM ont cassé en route.

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arc-key; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.com; ...
ARC-Authentication-Results: i=1; mx.forwarder.com;
    dkim=pass header.d=example.com;
    spf=pass smtp.mailfrom=example.com;
    dmarc=pass header.from=example.com

Le tag cv= (chain validation) indique :

  • none : premier maillon (pas de chaîne antérieure)
  • pass : la chaîne précédente est valide
  • fail : la chaîne est brisée

X-Spam-Status: et X-Spam-Score:

Ajoutés par les filtres anti-spam (SpamAssassin, Rspamd) :

X-Spam-Status: No, score=-2.1 required=5.0
X-Spam-Score: -2.1

Un score négatif est bon. Un score élevé (au-dessus du seuil required) déclenche le marquage spam.

List-Unsubscribe:

Requis par les exigences Google/Yahoo 2024 pour les envois en masse :

List-Unsubscribe: <https://example.com/unsub?id=123>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Son absence peut impacter la délivrabilité.

Diagnostic rapide avec les headers

SymptômeOù regarder
Email en spamAuthentication-Results, X-Spam-Score
DMARC failAuthentication-Results (vérifier alignement From: vs Return-Path / d=)
DKIM failDKIM-Signature (le d= correspond-il ? La clé DNS est-elle publiée ?)
SPF failReceived (quelle IP a envoyé ?) + record SPF du Return-Path
Email modifié en transitReceived (chercher des relais suspects) + DKIM body hash fail

Pour aller plus loin