technique · réponse sourcée
L’en-tête Return-Path expliqué
L’en-tête Return-Path contient l’adresse e-mail à laquelle le serveur de messagerie destinataire envoie les avis de non-remise ou les messages de bounce. Il est issu de la commande SMTP MAIL FROM lors de la transaction d’enveloppe et sert d’adresse de retour réelle pour les notifications système, par opposition à l’adresse From visible par l’utilisateur.
Fonctionnement technique
Pendant le handshake SMTP, le serveur d’envoi fournit un expéditeur d’enveloppe via la commande MAIL FROM. Lorsque le serveur destinataire accepte le message, il insère cette adresse dans l’en-tête Return-Path de l’e-mail remis. L’expéditeur d’enveloppe, utilisé pour le routage et le signalement des erreurs, est ainsi distinct de l’adresse Header From que l’utilisateur final voit dans son client de messagerie.
Rôle dans l’authentification SPF
Le Return-Path est essentiel pour la vérification Sender Policy Framework (SPF). Les serveurs destinataires contrôlent le domaine figurant dans le Return-Path pour déterminer quelles adresses IP sont autorisées à envoyer des e-mails pour ce domaine. Si le domaine du Return-Path ne correspond pas à l’enregistrement SPF de l’IP d’envoi, le message peut échouer à l’authentification SPF, ce qui nuit à la délivrabilité globale.
Gestion des bounces et retours
Lorsqu’un message ne peut pas être livré, le serveur destinataire envoie une notification de bounce à l’adresse indiquée dans le Return-Path. Les organisations utilisent des adresses ou des sous-domaines dédiés aux bounces pour traiter ces échecs de manière automatisée. SendHQ propose des outils gratuits sur https://sendhq.cc/tools pour aider les utilisateurs à vérifier leur configuration DNS et à fluidifier leur flux d’e-mails.
Erreurs opérationnelles courantes
Une erreur fréquente consiste à ne pas aligner le domaine du Return-Path sur le domaine From. Si cet alignement n’est pas strictement requis pour SPF, DMARC exige un alignement entre le Return-Path (ou le domaine DKIM) et l’en-tête From visible. Des Return-Path mal configurés font souvent classer les e-mails comme spam ou échouer aux contrôles DMARC faute d’alignement.
Exemple concret
Si un utilisateur envoie un e-mail depuis info@example.com en passant par un service transactionnel, l’expéditeur d’enveloppe peut être bounces@mail.provider.com. Le destinataire voit info@example.com dans sa boîte de réception, mais l’en-tête Return-Path vaut bounces@mail.provider.com. Tout échec de livraison est envoyé à l’adresse du fournisseur pour traitement.
Les questions que posent les équipes
Le Return-Path est-il la même chose que l’en-tête From ?
Non. L’en-tête From s’adresse au destinataire humain, tandis que le Return-Path sert au serveur de messagerie pour gérer les bounces et les contrôles SPF.
Puis-je modifier le Return-Path ?
Oui, en configurant l’expéditeur d’enveloppe ou l’adresse MAIL FROM dans vos paramètres SMTP ou auprès de votre fournisseur de services e-mail.
Le Return-Path affecte-t-il DMARC ?
Oui. DMARC vérifie l’alignement entre l’en-tête From et soit le domaine du Return-Path, soit le domaine de signature DKIM.
Que se passe-t-il si le Return-Path est invalide ?
Le serveur destinataire ne pourra pas envoyer de notifications de bounce, et l’e-mail risque d’être rejeté ou classé comme spam en raison d’un échec SPF.
Sources primaires
- RFC 5321 : Simple Mail Transfer Protocol — RFC Editor
- RFC 5322 : Internet Message Format — RFC Editor
- RFC 7208 : Sender Policy Framework — RFC Editor
- RFC 7489 : Domain-based Message Authentication, Reporting and Conformance — RFC Editor