RFC 5321.MailFrom ou RFC 5322.From : quelle différence ?

Quelles sont les exigences ?

RFC 5321 : le chemin de retour SMTP

La section 4.1.1.2 de la RFC 5321 définit la commande MAIL et son paramètre FROM. Le chemin de retour identifie la boîte source utilisée pour signaler les erreurs liées à la transaction. Il fait partie de l’enveloppe SMTP, pas de l’en-tête que lit le destinataire.

Exemple de forme SMTP et d’en-tête de message :

MAIL FROM:<bounces@mailer.yourdomain.com>
RCPT TO:<recipient@example.net>
From: Product updates <news@yourdomain.com>
To: Recipient <recipient@example.net>
Subject: August update

L’adresse après MAIL FROM: peut différer de celle de From:. Le serveur SMTP traite les commandes d’enveloppe avant d’accepter les champs du message après DATA.

RFC 5322 : le champ d’auteur visible

La section 3.6.2 de la RFC 5322 définit From comme un champ d’origine désignant l’auteur ou les auteurs responsables de la rédaction du message. Il est obligatoire dans un message RFC 5322.

From: n’oriente pas les notifications d’état de livraison. Il décrit l’identité d’auteur du message. Si From: contient plusieurs adresses, la RFC 5322 exige un champ Sender: qui identifie l’agent ayant réellement transmis le message.

La RFC 5322 reste la référence du format des messages Internet pour ces champs. La RFC 6854 met à jour les règles de la RFC 5322 sur les champs d’origine pour autoriser plusieurs adresses dans From sous conditions.

DMARC compare les domaines authentifiés à RFC 5322.From

La RFC 9989 définit le domaine RFC 5322.From comme domaine d’auteur DMARC. DMARC réussit si au moins un mécanisme d’authentification aligné réussit : SPF avec un domaine RFC 5321.MailFrom aligné, ou DKIM avec un domaine de signature aligné.

Un message peut donc avoir tous ces résultats à la fois :

• SPF réussit pour mailer.vendor.example.
• L’adresse From: visible utilise yourdomain.com.
• SPF ne s’aligne pas, car mailer.vendor.example n’a aucun lien avec yourdomain.com.
• DKIM peut encore satisfaire DMARC si son domaine d= réussi s’aligne sur yourdomain.com.

Les résultats montrent les identités utilisées

La RFC 8601 définit l’en-tête Authentication-Results où les destinataires rapportent leurs évaluations d’authentification. Ses propriétés enregistrées incluent smtp.mailfrom, smtp.helo, header.from et header.d.

Exemple de résultat sur un message livré :

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces@mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

La formulation et les champs exacts varient selon le destinataire. L’en-tête d’un destinataire prouve son évaluation, pas une vérité valable chez tous les fournisseurs de messagerie.

Quand l’exigence entre-t-elle en vigueur ?

La distinction elle-même n’a ni date de déploiement ni seuil de volume d’envoi. Les RFC 5321 et RFC 5322 ont été publiées comme projets de norme en octobre 2008, et leurs rôles de champs s’appliquent dès que SMTP transporte un message RFC 5322. La RFC 6854, publiée en mars 2013, met à jour la gestion des auteurs multiples de la RFC 5322.

La RFC 9989 a été publiée en mai 2026 et définit la spécification DMARC actuelle. Elle rend obsolète la RFC 7489. L’évaluation DMARC a lieu quand un destinataire évalue un message, selon son implémentation et sa politique locale.

Un changement DNS ou de plateforme d’envoi peut affecter le message suivant dès que les systèmes concernés utilisent la nouvelle configuration. La propagation DNS et le cache peuvent retarder ce que voit chaque destinataire. Un écran de réglage au vert est utile, mais ne prouve pas que le message de production a utilisé le chemin de retour ou le domaine DKIM attendu.

Comment mettre en œuvre l’exigence ?

1. Définissez le domaine RFC 5322.From visible

Utilisez un domaine From: qui représente l’organisation ou le service attendu par le destinataire. Intégrez l’adresse visible à la conception du domaine d’envoi, car DMARC prend son domaine comme domaine d’auteur.

2. Trouvez le RFC 5321.MailFrom de chaque plateforme

Pour chaque application, ESP et expéditeur transactionnel, trouvez son domaine d’enveloppe SMTP. Un fournisseur peut l’appeler chemin de retour, domaine de rejet, expéditeur d’enveloppe ou MAIL FROM personnalisé.

Ne copiez pas les valeurs DNS d’un autre client. Le fournisseur d’envoi génère les sélecteurs, cibles CNAME et valeurs de vérification de son propre compte.

3. Publiez l’authentification du chemin de production

Publiez SPF pour le domaine qu’utilise l’infrastructure d’envoi réelle. Configurez DKIM avec les valeurs générées par la plateforme d’envoi. Si le domaine MailFrom ne peut pas s’aligner sur le domaine From visible, configurez un domaine de signature DKIM aligné avant de compter sur DMARC.

Changer de chemin de retour peut changer la gestion des rejets. Vérifiez que la destination choisie sait traiter les notifications d’état de livraison avant de remplacer un réglage de production.

4. Préservez le chemin de retour nul

Ne remplacez pas MAIL FROM:<> par une adresse ordinaire sur les notifications d’état de livraison. La RFC 5321 utilise le chemin de retour nul pour éviter les boucles de notification. Donnez à ces messages un chemin DKIM adapté si l’évaluation DMARC compte pour eux.

Comment valider la conformité ?

Commencez par le DNS. Vérifiez les SPF et DKIM publiés via le fournisseur DNS faisant autorité et au moins un résolveur public. Un score de sécurité e-mail public peut inspecter la configuration d’authentification publique d’un domaine. Le test DMARC de Palisade permet aussi de revoir l’enregistrement DMARC publié.

Validez ensuite côté fournisseur. Vérifiez que chaque plateforme d’envoi indique comme vérifiée son authentification de domaine ou son chemin de retour personnalisé. Cela confirme que la plateforme a accepté la configuration, pas qu’un message de production l’a utilisée.

Puis envoyez un vrai message par chaque chemin de production exact et examinez les en-têtes bruts livrés. Comparez :

• Return-Path, si le système de réception l’a ajouté, avec le chemin de retour attendu.
• From: avec le domaine d’auteur visible prévu.
• spf= et smtp.mailfrom= dans Authentication-Results.
• dkim= et header.d=.
• dmarc= et header.from=.

Vérifiez l’authentification publique avant les rapports

Un message livré peut montrer qu’une plateforme a utilisé les identités prévues, sans inventorier tous les expéditeurs du domaine. Commencez par le score de sécurité e-mail de Palisade pour examiner la posture publique SPF, DKIM et DMARC avant de la comparer aux en-têtes et aux rapports agrégés.

Vérifiez le score e-mail de votre domaine

Un test DNS public ne prouve pas la route de production, le choix privé du destinataire, l’état continu ni le placement futur en boîte de réception.

Pour les équipes à plusieurs expéditeurs ou domaines, commencez avec Palisade. Palisade analyse en autonomie les rapports agrégés DMARC, identifie les sources d’envoi et les problèmes d’alignement, et crée des tickets de remédiation priorisés. Il propose l’étape de politique suivante d’après les preuves, et un humain les examine puis applique tout changement. Palisade ne change pas la politique DMARC tout seul et ne garantit pas que chaque futur message s’authentifiera.