RFC 5322 – Format des messages Internet

Norme actuelle SMTP central et format de message Obsoletes RFC 2822 Published March 2026

ELI5: Si [RFC 5321](5321) (SMTP) est le camion postal qui livre votre lettre, RFC 5322 est le format de la lettre elle-même — où vous écrivez l'adresse de retour, l'adresse du destinataire, la date, la ligne d'objet, et ensuite le message réel ci-dessous. Chaque courrier électronique que vous ouvrez dans votre boîte de réception est structuré selon cette spécification.

Pourquoi cette RFC existe

La RFC 5322 définit la syntaxe d'un message électronique — le texte qui circule via SMTP pendant la phase DATA. Son ancêtre, la RFC 822 (1982), était l'une des toutes premières normes Internet. La RFC 5322 a actualisé le format avec des règles de syntaxe plus strictes, une gestion plus claire des syntaxes obsolètes et un alignement avec les pratiques modernes.

Cette RFC concerne uniquement le format du message — elle ne dit rien sur la façon dont le message est transporté (c'est la RFC 5321) ou sur le fonctionnement des pièces jointes (c'est la RFC 2045 et la famille MIME). Elle définit les champs d'en-tête, le corps et les règles pour les adresses, les dates et l'identification des messages.

Comment ça fonctionne

Un message électronique est divisé en deux parties séparées par une ligne vide :

Section d'en-tête : Une séquence de champs d'en-tête, chacun au format Nom : valeur, terminée par CRLF.
Corps : Le contenu du message, qui est simplement du texte non structuré (MIME ajoute de la structure par-dessus).

Structure du message

# Section d'en-tête From: Alice Smith <alice@example.com> To: Bob Jones <bob@example.net>, Carol White <carol@example.org> Cc: Dave <dave@example.com> Subject: Quarterly Report Date: Wed, 11 Mar 2026 15:30:00 -0500 Message-ID: <unique-id-12345@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" # Une ligne vide sépare les en-têtes du corps Hi Bob and Carol, Please find the quarterly report attached.

Champs d'en-tête obligatoires

La RFC 5322 stipule que chaque message DOIT contenir ces champs :

Champ	Description	Exemple
`From:`	L'auteur ou les auteurs du message	`From: Alice <alice@example.com>`
`Date:`	Quand le message a été composé	`Date: Wed, 11 Mar 2026 15:30:00 -0500`

De plus, chaque message DEVRAIT contenir un champ Message-ID — un identifiant globalement unique. Les messages sans Message-ID causent des problèmes avec le threading, la déduplication et la signature DKIM.

Champs d'en-tête courants

Champ	Objectif
`To:`	Destinataires principaux
`Cc:`	Destinataires en copie carbone
`Bcc:`	Copie carbone masquée (supprimée avant livraison)
`Subject:`	Sujet du message
`Reply-To:`	Adresse pour les réponses (remplace From:)
`Sender:`	Expéditeur réel quand From: contient plusieurs auteurs ou diffère de l'agent de transmission
`In-Reply-To:`	Message-ID du message auquel on répond
`References:`	Chaîne de Message-ID pour le threading
`Message-ID:`	Identifiant globalement unique pour ce message
`Return-Path:`	Ajouté par le système de livraison final à partir de MAIL FROM
`Received:`	En-tête de trace ajouté par chaque serveur qui traite le message

Détails techniques clés

Formats d'adresse

La RFC 5322 définit deux formats d'adresse valides :

Addr-spec : alice@example.com — juste la boîte aux lettres.
Name-addr : Alice Smith <alice@example.com> — un nom d'affichage plus une adresse entre crochets.

Les noms d'affichage contenant des caractères spéciaux doivent être mis entre guillemets : "O'Brien, Alice" <alice@example.com>. La partie locale (avant le @) est sensible à la casse selon la spécification, mais traitée comme insensible à la casse par pratiquement tous les systèmes de messagerie en pratique.

Format de date

Le format de date est spécifique et ne tolère pas les erreurs :

Date: Thu, 11 Mar 2026 15:30:00 -0500

Le format est : jour-de-la-semaine, JJ Mois AAAA HH:MM:SS zone. Le jour de la semaine est facultatif mais conventionnel. Le fuseau horaire doit être un décalage numérique (-0500), pas un nom comme « EST ». Bien que la spécification tolère les anciennes abréviations de fuseau horaire comme syntaxe obsolète, leur génération n'est pas recommandée.

Format de Message-ID

Un Message-ID doit être globalement unique et suivre la forme :

Message-ID: <unique-part@domain>

La meilleure pratique est d'utiliser un UUID ou une partie unique basée sur un timestamp combinée avec votre domaine d'envoi : <20260311153000.a1b2c3@mail.example.com>.

Pliage d'en-tête

Les longues valeurs d'en-tête peuvent être « pliées » en insérant un CRLF suivi d'au moins un espace ou une tabulation (espace blanc). C'est ainsi que les longues listes de destinataires ou les lignes d'objet restent dans la limite de 998 caractères par ligne :

To: Alice <alice@example.com>, Bob <bob@example.com>, Carol <carol@example.com>

Les analyseurs doivent « déplier » ces lignes en les joignant où la continuation commence par un espace blanc.

En-têtes de trace

Chaque serveur de messagerie qui traite un message ajoute un en-tête Received:. Ils forment une piste de haut en bas — l'en-tête Received: le plus haut a été ajouté en dernier. L'en-tête Return-Path: est ajouté uniquement par le système de livraison final et contient l'expéditeur d'enveloppe de MAIL FROM.

Erreurs courantes

En-tête Date manquant ou malformé. Certains filtres anti-spam pénalisent les messages sans en-tête Date approprié ou avec une date loin dans le futur/passé. Générez-le toujours au moment de l'envoi.
Message-ID manquant. Sans un Message-ID unique, les réponses ne s'enchaîneront pas correctement, les signatures DKIM peuvent ne pas couvrir le champ, et certains filtres anti-spam signalent le message.
Guillemets d'adresse incorrects. Les noms d'affichage avec des virgules, des points ou des caractères spéciaux doivent être mis entre guillemets. O'Brien, Alice <alice@example.com> est invalide — cela doit être "O'Brien, Alice" <alice@example.com>.
Utilisation incorrecte de BCC. L'en-tête BCC doit être supprimé avant la transmission. Si vous incluez les destinataires BCC dans l'en-tête qui est livré, vous avez annulé l'objectif de la copie carbone masquée.
Dépassement de la longueur de ligne. Les lignes d'en-tête et les lignes de corps ne doivent pas dépasser 998 caractères. Utilisez le pliage d'en-tête pour les longs en-têtes et l'encodage MIME approprié pour le contenu du corps long.
Confusion entre From et Sender. L'en-tête Sender: n'est requis que lorsque l'entité de transmission réelle diffère de l'auteur From:. N'ajoutez pas d'en-tête Sender redondant qui correspond à From — c'est inutile et peut confondre les filtres.
Format de fuseau horaire incorrect. L'utilisation de EST au lieu de -0500 est une syntaxe obsolète. Utilisez toujours des décalages numériques.

Impact sur la délivrabilité

La signature DKIM dépend des en-têtes. DKIM (RFC 6376) signe des champs d'en-tête spécifiques. Les en-têtes manquants ou malformés signifient que la signature peut ne pas couvrir ce que vous attendez, ou le message peut échouer la vérification.
Les vérifications d'alignement DMARC vérifient l'en-tête From. DMARC (RFC 7489) compare le domaine dans l'en-tête From: avec les résultats SPF et DKIM. Un From manquant ou incompatible signifie un échec DMARC automatique.
Threading et expérience utilisateur. Les en-têtes appropriés Message-ID, In-Reply-To et References assurent que vos messages s'enchaînent correctement dans les clients de messagerie des destinataires. Le threading interrompu rend vos messages peu professionnels.
Heuristiques des filtres anti-spam. Les filtres vérifient la conformité à la RFC 5322. Les en-têtes manquants requis, les dates malformées et le formatage non standard sont tous des signaux négatifs qui augmentent votre score de spam.
Usurpation de nom d'affichage. Les fournisseurs de messagerie affichent de plus en plus souvent des avertissements quand l'adresse From semble suspecte. L'utilisation d'un en-tête From propre et cohérent avec un nom d'affichage reconnaissable améliore les taux d'ouverture et la confiance.