Qu'est-ce que le transfert d'e-mails ? Comment ça marche et quelles sont les bonnes pratiques ?

Le transfert d'e-mails est l'une des causes les plus courantes d'échecs de livraison, et la plupart des administrateurs de domaine ne disposent d'aucun indicateur clair leur signalant qu'un problème existe. Le transfert modifie les données du message d'une manière qui compromet les protocoles d'authentification modernes, et cela passe souvent inaperçu. Comme les données ne correspondent plus, les serveurs destinataires considèrent les e-mails transférés comme suspects et les envoient souvent dans le dossier spam ou les bloquent purement et simplement.

Qu'est-ce que le transfert d'e-mails ?

Le transfert d'e-mails est un processus côté serveur qui redirige les e-mails entrants d'une adresse vers une autre. Comme cette opération s'effectue sur le serveur de messagerie, elle est totalement transparente pour l'expéditeur d'origine et ne nécessite aucune intervention manuelle de la part du destinataire. 

Mais avant toute chose, faisons la distinction entre le transfert manuel et le transfert automatique des e-mails. Pour dissiper toute confusion, il est utile de se pencher sur où et quand le transfert a lieu :

• Transfert manuel des e-mails : Cela se produit lorsqu' qu'un message arrive dans votre boîte de réception. Vous ouvrez l'e-mail, cliquez sur « Transférer », saisissez l'adresse du nouveau destinataire, puis cliquez sur « Envoyer ». Cela nécessite une intervention manuelle pour chaque e-mail.
• Transfert automatique des e-mails : C'est une règle que l'on configure une fois pour toutes . Vous la configurez une seule fois (soit dans vos paramètres de messagerie, soit sur le serveur), et le système achemine instantanément les messages entrants vers une autre adresse avant même que vous ne les voyiez.

Les entreprises ont souvent recours au transfert automatique des e-mails dans plusieurs cas de figure courants : 

• Alias de domaine: Rediriger les adresses professionnelles générales directement vers la boîte de réception personnelle d'un employé.
• Règles de transfert automatique: Création de filtres au niveau de l'utilisateur ou du système pour transférer les e-mails vers des comptes distincts. 
• Listes de diffusion: Diffusion simultanée d'un même message à un grand nombre d'abonnés. 
• Routage vers des tiers: Envoi de journaux de transactions ou de tickets d'assistance vers des systèmes externes en vue de leur traitement. 

Transfert d'e-mails ou redirection

Même si ces deux termes sont souvent utilisés de manière interchangeable, ils ont une signification différente pour un serveur de messagerie. 

Lorsqu'un e-mail est transféré, votre serveur de messagerie crée en fait une copie du message et lance une nouvelle transaction. Il ajoute ses propres informations de routage en arrière-plan, mais le nom de l'expéditeur d'origine reste visible dans le champ « De » que vous voyez dans votre boîte de réception. C'est cette différence qui éveille les soupçons des serveurs destinataires. 

Une véritable redirection est plus passive. Au lieu de reformuler le message, votre serveur se contente d'envoyer l'e-mail d'origine vers une nouvelle destination sans modifier l'enveloppe d'origine ni les propriétés de transmission. Pour le serveur destinataire, un e-mail redirigé donne l'impression d'avoir été envoyé directement de la boîte de réception de l'expéditeur d'origine vers la sienne : pas d'intermédiaire, aucune modification des données et aucune authentification compromise. 

En bref : transfert vs redirection

Comment fonctionne le transfert d'e-mails ?

Voici une description étape par étape du parcours d'un message sur Internet : 

• Étape 1 : L'expéditeur initial envoie l'e-mail au serveur de messagerie initial du destinataire. 
• Étape 2 : Le serveur d'origine reçoit le message entrant et le compare à un ensemble de règles de transfert. 
• Étape 3 : L'intermédiaire de transfert établit une nouvelle connexion pour envoyer le message au serveur de destination final, en acheminant le trafic via son propre système et sa propre adresse IP. 
• Étape 4 : Le serveur de destination reçoit le message provenant d'une adresse IP intermédiaire inattendue. 

Le conflit 

Au cours de ce processus, trois changements majeurs se produisent : 

1. L'adresse IP d'origine de la connexion devient celle du serveur de transfert, 
2. L'en-tête « De » reste identique au domaine de l'expéditeur d'origine, et 
3. Le corps du message ou les en-têtes peuvent être modifiés, par exemple pour ajouter des pieds de page de liste de diffusion ou des en-têtes de transit. 

Ces changements structurels compromettent l'authentification des e-mails. 

Comment le transfert d'e-mails influe sur l'authentification

Lorsque le transfert automatique des e-mails est activé, cela entraîne des modifications qui perturbent la manière dont les protocoles d'authentification des e-mails vérifient un message. 

SPF (Sender Policy Framework) 

SPF les e-mails entrants en vérifiant si l'adresse IP du serveur de connexion figure dans l'enregistrement DNS du domaine indiqué dans le champ « Return-Path » de l'expéditeur de l'enveloppe. 

• Le problème ? Lorsqu'un e-mail est transféré, l'intermédiaire chargé du transfert établit une nouvelle connexion pour envoyer le message et achemine le trafic via sa propre infrastructure et son adresse IP. 
• Résultat ? L'adresse IP du serveur de transfert ne figurant pas dans SPF de l'expéditeur d'origine, la vérification de l'expéditeur de l'enveloppe échoue à la destination finale. Ainsi, SPF presque systématiquement lors d'un transfert. 

DKIM (DomainKeys Identified Mail) 

Le protocole DKIM utilise une signature cryptographique associée au domaine pour vérifier que le contenu du message n'a pas été modifié pendant son acheminement. 

• Le problème ? Cette signature cryptographique reste généralement intacte lors d'un simple transfert si le serveur intermédiaire se contente de relayer le message de manière passive. En revanche, si le serveur de transfert modifie le corps du message ou y ajoute des pixels de suivi ou des en-têtes, les données sous-jacentes sont altérées. 
• Résultat ? Une fois le contenu modifié, la signature DKIM ne correspond plus, ce qui invalide complètement l'authentification. 

DMARC 

DMARC fonctionne comme une couche de politique qui exige qu'un e-mail soit SPF ou DKIM pour passer l'authentification. 

• Le problème ? Étant donné que le transfert de messages compromet par nature la validité SPF, votre e-mail dépend du DKIM pour passer le contrôle DMARC. Si l'intermédiaire chargé du transfert modifie également le corps du message ou les en-têtes, le DKIM échoue, tout comme SPF. 
• Résultat ? Lorsque ces deux protocoles échouent, la validation DMARC échoue en conséquence directe. Si le domaine de l'expéditeur d'origine applique une politique DMARC stricte (p=reject), l'e-mail légitime transféré est bloqué par le serveur de destination.

L'évolution du transfert : de l'ARC au DKIM2

Pour pallier les failles inhérentes au transfert de messages dans le système d'authentification traditionnel du courrier électronique, la communauté Internet a initialement conçu l'ARC (Authenticated Received Chain) afin de permettre aux intermédiaires de se porter garants d'un message par des moyens cryptographiques.

Qu'est-ce que l'ARC ?

En termes simples, ARC est un protocole de messagerie qui fonctionne comme une succession de cachets de notaire. À mesure qu'un e-mail transite par des intermédiaires de transfert (tels qu'une liste de diffusion ou une boîte de réception avec transfert automatique), chaque serveur signe cryptographiquement le message et certifie la validité de son authentification initiale. Cela permet au serveur destinataire final de remonter la chaîne validée et de vérifier que l'e-mail était bien authentique avant d'être transféré.

Le passage à DKIM2

Cependant, le paysage de la sécurité des e-mails est en pleine mutation. Selon le projet de l'IETF du 17 mai 2026 (draft-ietf-dkim-dkim2-spec-02), le secteur est en pleine transition vers DKIM2.

Étant donné que les enseignements opérationnels tirés de l'ARC sont intégrés à cette solution native plus épurée, un projet distinct de l'IETF datant d'avril 2026 a proposé de reclasser officiellement l'ARC en tant que norme historique.

Comment DKIM2 résout nativement les problèmes liés au transfert

Alors qu'ARC fonctionnait comme une solution de contournement expérimentale, DKIM2 corrige les problèmes de transfert directement au sein du protocole de base. Lorsque des listes de diffusion ou des serveurs de transfert modifient un e-mail, DKIM2 gère cette situation en établissant une chaîne de contrôle à chaque étape du parcours du message.

Chaque système intermédiaire enregistre les modifications qui lui sont propres et y ajoute sa propre signature. Cela permet aux serveurs destinataires de retracer sans difficulté le parcours du message jusqu'à son expéditeur d'origine, sans rompre la chaîne d'authentification.

Principales améliorations apportées dans la mise à jour de mai 2026 :

• En-têtes exclus : Les en-têtes « Authentication-Results » Les en-têtes seront désormais exclus de la signature afin d'éviter des échecs de vérification inutiles lorsque le courrier franchit les frontières.
• Indicateurs de contrôle renforcés : Les expéditeurs peuvent utiliser des indicateurs donotmodify et donotexplode pour empêcher toute modification non autorisée des messages ou tout routage fractionné.
• Code simplifié : La spécification supprimera la recette du corps z afin de simplifier la manière dont les implémentations compatibles sont construites.

Remarque importante : DKIM2 est encore un projet de l'IETF en cours d'élaboration et n'a pas encore été officiellement déployé. La spécification devrait faire l'objet de modifications techniques et d'améliorations supplémentaires avant d'être officiellement publiée en tant que norme Internet définitive. 

Bonnes pratiques en matière de transfert d'e-mails

Voici les meilleures pratiques en matière de transfert d'e-mails que les administrateurs de domaine devraient suivre :

• Privilégiez l'alignement DKIM : Utilisez DKIM comme principale méthode d'alignement. Étant donné que SPF susceptible d'échouer lors du transfert, une signature DKIM valide et non modifiée constitue souvent votre meilleure défense pour passer la validation DMARC. 
• Configurer la canonicalisation assouplie : Définissez la canonicalisation DKIM de votre serveur de messagerie sur c=relaxed/relaxed. Cela permet des modifications mineures au niveau des espaces ou de la casse des en-têtes pendant le transit sans compromettre la signature cryptographique.  
• Conserver l'ARC actuel (mais envisager le passage à DKIM2) : Si votre infrastructure de messagerie interne utilise déjà la signature par le protocole ARC, maintenez-le actif pour prendre en charge les passerelles héritées. Cependant, n'investissez pas massivement dans de nouveaux développements ARC. Selon les derniers projets de l'IETF pour 2026, ARC pourrait être reclassé en norme historique, car ses enseignements opérationnels sont intégrés à DKIM2.
• Configurer les (pour l'instant) : pour les environnements Microsoft 365, continuez à ajouter manuellement des intermédiaires de transfert connus et réputés à vos liste des ARC Sealers de confiance dans le portail Microsoft Defender. Cela garantit que les e-mails transférés légitimes ne sont pas rejetés pendant la transition du secteur vers DKIM2.
• Surveiller les rapports agrégés DMARC : Examinez vos données XML agrégées pour identifier les échecs de transfert dus à des problèmes d'alignement SPF. Utilisez ces rapports pour identifier et mesurer l'impact exact du transfert sur vos taux de livraison. L'examen de la les dérogations à la politique DMARC peut aider à comprendre comment les réseaux destinataires traitent ces flux.
• Passage aux boîtes aux lettres partagées : Pour le routage interne, envisagez d'utiliser des boîtes aux lettres partagées plutôt que des règles de transfert automatique de la boîte de réception. Les boîtes aux lettres partagées permettent à plusieurs utilisateurs d'accéder directement aux mêmes flux de messagerie, ce qui évite les problèmes d'authentification liés au transfert de serveur à serveur.  
• Appliquez les politiques progressivement : Commencez par p=none si vous disposez de voies de transfert actives. Ne passez à des niveaux de politique plus stricts (quarantine p=reject) qu'après avoir vérifié vos flux transférés à l'aide de vos rapports de surveillance. 

Consultez notre guide complet guide sur le transfert de courrier ou consultez les directives de Google concernant les expéditeurs ARC pour vous assurer que vos configurations sont conformes aux normes actuelles du secteur.

Types de redirection d'e-mails

Comprendre les différents niveaux opérationnels du transfert permet d'identifier à quel niveau les problèmes d'authentification surviennent. 

Transfert au niveau du serveur

Configuré au niveau de l'agent de transfert de courrier (MTA) ou du serveur de messagerie d'entreprise, ce type de configuration applique des règles de routage globales à tous les messages entrants qui répondent à des critères de domaine spécifiques. Le traitement s'effectue instantanément dès la réception et s'avère très efficace pour les alias d'entreprise. 

Transfert au niveau du client

Cette fonctionnalité est configurée par chaque utilisateur dans son client de messagerie, tel que Gmail ou Outlook. Elle s'appuie sur des règles et des filtres définis par l'utilisateur pour acheminer les messages entrants vers des comptes externes, personnels ou secondaires. 

Alias de domaine

Une configuration technique permettant à un domaine entier ou à une adresse spécifique de rediriger automatiquement tout le trafic entrant vers une boîte de réception distincte. Cette méthode est couramment utilisée en entreprise pour préserver la propreté des identités publiques. 

Listes de diffusion

Système de diffusion dans lequel un e-mail envoyé à une seule adresse centralisée est automatiquement copié et transmis à un grand nombre d'abonnés individuels. Les listes de diffusion sont les plus exposées au risque d'échec de la validation DKIM. 

Transfert d'e-mails dans Gmail et Outlook

Gmail et Microsoft 365 gèrent le transfert d'e-mails à l'aide d'infrastructures cloud distinctes.

Transfert automatique des e-mails dans Gmail

Voici comment transférer des e-mails dans Gmail :

Étape 1 : Rendez-vous dans les Paramètres

Cliquez sur l' icône en forme de roue dentée en haut à droite de Gmail, puis sur « Afficher tous les paramètres », puis accédez à la section Transfert et POP/IMAP .

Étape 2 : Associer la nouvelle adresse

1. Cliquez Ajouter une adresse de transfert et saisissez l'adresse e-mail de destination.
2. Rendez-vous dans la boîte de réception de cette adresse, ouvrez l'e-mail de confirmation envoyé par Google, puis cliquez sur le lien de vérification.

Étape 3 : Choisissez le mode de transfert

• Pour tout transférer : Cochez Transférer une copie des e-mails entrants vers…, décidez si vous souhaitez conserver ou supprimer la copie dans votre boîte de réception d'origine, puis cliquez sur Enregistrer les modifications en bas de la page.
• Pour transférer des e-mails spécifiques : Cliquez sur « Créer un filtre » (ou utilisez le menu déroulant de la barre de recherche), définissez vos critères (comme un expéditeur spécifique), cochez Transférer vers, puis cliquez sur Créer un filtre.

Que se passe-t-il en coulisses ?

Lorsque Google transfère un message, il le fait passer par ses propres serveurs. Voici comment cela affecte la sécurité des e-mails à leur destination finale :

• La vérificationSPF d'échouer : Comme l'e-mail provient des serveurs de Google plutôt que de ceux de l'expéditeur d'origine, SPF standard échouent généralement.
• La validation DKIM est généralement réussie : Gmail ne modifie pas le corps de l'e-mail, de sorte que la signature DKIM de l'expéditeur d'origine reste intacte.
• Gmail ajoute automatiquement des en-têtes ARC aux e-mails transférés (pour l'instant), ce qui permet au serveur destinataire de vérifier que l'e-mail est légitime malgré SPF .

Petite astuce pour les administrateurs de l'espace de travail : Gardez un œil sur vos rapports agrégés DMARC pour suivre et gérer ces SPF liés au transfert.

Transfert d'e-mails dans Outlook / Microsoft 365

Microsoft 365 (M365) offre un large éventail d'options de routage des e-mails, mais la gestion de leur interaction avec les filtres de sécurité du courrier électronique nécessite une configuration minutieuse.

1. Types de redirection des e-mails dans M365

Les administrateurs et les utilisateurs peuvent configurer le transfert de messages de trois manières différentes :

• Règles de la boîte de réception : Règles individuelles créées au niveau de l'utilisateur dans Outlook.
• Règles de transport : Règles détaillées de niveau administrateur configurées dans Exchange Online.
• Transfert de boîte aux lettres SMTP : Configurations de transfert SMTP (Simple Mail Transfer Protocol) appliquées à des boîtes aux lettres spécifiques.

2. Le problème d'authentification : échecs des protocoles SPF ARC

Étant donné que le transfert modifie le cheminement du courriel, il entre intrinsèquement en conflit avec les protocoles d'authentification standard du courrier électronique :

• SPF : Lors d'un transfert, l'adresse IP de connexion change pour celle du réseau Microsoft. Par conséquent, la vérificationSPF(Sender Policy Framework) de l'expéditeur d'origine échouera à la destination finale.
• Paramètre par défaut de l'en-tête ARC : Par défaut, les règles de transport M365 ajoutent des en-têtes ARC (Authenticated Received Chain) aux e-mails sortants transférés afin de faciliter la validation de l'historique du message.
• Résultat : Malgré les en-têtes ARC, le changement d'adresse IP entraîne souvent des erreurs de statut « arc=fail » pour les locataires Microsoft à l'autre bout de la connexion.

3. Solutions et politiques administratives

Pour garantir la délivrabilité des e-mails et éviter les blocages liés à la sécurité, les administrateurs M365 en entreprise doivent gérer deux paramètres essentiels :

• Définir les « Trusted ARC Sealers » : Les administrateurs doivent explicitement répertorier les intermédiaires externes de confiance en tant que « Trusted ARC Sealers » dans leur portail Microsoft Defender afin d'améliorer la délivrabilité.
• Autoriser le transfert externe : Microsoft applique une politique de sécurité globale qui bloque par défaut le transfert automatique vers l'extérieur dans les nouveaux locataires. En raison de cette mesure de sécurité, les règles de transfert créées par les utilisateurs échoueront silencieusement jusqu'à ce qu'un administrateur autorise explicitement le transfert vers l'extérieur.

Résumé

Les outils de sécurité de base d'Internet n'ont pas été conçus pour les messages qui transitent par plusieurs serveurs. Lorsqu'un serveur transmet un e-mail à un autre serveur, il modifie l'adresse IP de l'expéditeur et désactive vos SPF .

Mais vous n'avez pas besoin de sacrifier l'acheminement des e-mails au profit d'une sécurité optimale. Des configurations DKIM robustes et les protocoles ARC peuvent vous aider à garantir que vos e-mails transférés parviennent bien dans les boîtes de réception prévues. 

Avec PowerDMARC, vous pouvez visualiser d'un seul coup d'œil l'ensemble de votre configuration de redirection des e-mails. Notre plateforme vous permet de suivre les données agrégées DMARC, de gérer les problèmes complexes liés aux alias d'e-mail et de mettre en place une signature ARC sortante parfaite sur l'ensemble de votre réseau. 

Ne vous demandez plus si vos e-mails sont bien arrivés. Inscrivez-vous dès aujourd'hui à un essai gratuit de PowerDMARC et sécurisez votre flux de messagerie de bout en bout.

Foire aux questions 

Le transfert d'e-mails compromet-il SPF? 

Oui. SPF si l'adresse IP du serveur expéditeur correspond aux adresses IP autorisées dans les enregistrements DNS de l'expéditeur. Comme le transfert fait passer le message par un serveur intermédiaire, la connexion ne correspondra pas à SPF de l'expéditeur d'origine. La vérification échouera donc ! 

Le transfert d'e-mails compromet-il la validité du DKIM ? 

Avec le protocole DKIM traditionnel, le transfert ne fonctionne plus si une liste de diffusion ou un intermédiaire modifie le corps du message, ajoute des pieds de page ou modifie les en-têtes. Le hachage cryptographique étant modifié, la signature d'origine est invalidée, ce qui entraîne des échecs DMARC. Selon le projet de l'IETF du 17 mai 2026, le futur protocole DKIM2 gérera les transferts en établissant une chaîne de contrôle intégrée.

Au lieu de rompre la chaîne d'authentification, chaque système qui traite le courriel enregistre ses modifications et y ajoute sa propre signature. Cela permet aux serveurs destinataires de remonter sans difficulté jusqu'à l'expéditeur d'origine.

Pourquoi mes e-mails transférés finissent-ils dans le dossier « Spam » ? 

Les e-mails transférés finissent souvent dans les dossiers de spam, car le changement d'adresse IP d'envoi entraîne un échec de SPF . Lorsque cet échec provoque l'échec de l'authentification DMARC en aval, les systèmes de messagerie destinataires marquent le message entrant comme non authentifié ou usurpé. 

Quelle est la différence entre le transfert d'e-mails et la redirection d'e-mails ? 

Le transfert d'e-mails modifie le chemin de transmission du message en le faisant passer par un serveur intermédiaire doté d'une nouvelle adresse IP, tout en conservant les coordonnées de l'expéditeur d'origine dans les en-têtes visibles. La redirection d'e-mails demande au système d'envoyer le message d'origine directement à une adresse secondaire sans modifier les propriétés de l'expéditeur figurant dans l'enveloppe ni compromettre la cohérence de l'authentification. 

Le transfert d'e-mails est-il sécurisé ? 

Le transfert standard des e-mails expose les en-têtes de routage du message d'origine à des systèmes tiers, ce qui complique le suivi et perturbe les protocoles d'authentification tels que SPF DMARC. Cela permet aux acteurs malveillants d'exploiter plus facilement les flux non alignés, à moins que des protections telles que l'ARC ne soient correctement mises en place.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Sécurité des e-mails et de la paie des RH : bonnes pratiques pour les équipes internationales - 22 juin 2026
• Comment bloquer les agents IA à haut risque dans Microsoft Entra - 15 juin 2026
• Politique anti-hameçonnage d'Office 365 : comment la configurer - 3 juin 2026