Le transfert d’e-mails est l’une des activités légitimes les plus courantes qui entraînent des échecs d’authentification DMARC. Lorsqu’une boîte de réception transfère automatiquement un message entrant vers une autre destination – comme une adresse Gmail personnelle transférant vers un compte professionnel, ou un administrateur de bureau transférant des messages aux membres du département – le message transféré peut échouer aux vérifications DMARC même lorsque l’expéditeur d’origine a tout configuré correctement.

Cette rupture d’authentification se produit parce que DMARC s’attend à ce que l’infrastructure d’envoi, les en-têtes de message et l’alignement du domaine restent inchangés pendant la livraison. Le transfert brise cette hypothèse. Résultat : des messages légitimes provenant de domaines authentifiés peuvent être rejetés, mis en quarantaine ou signalés lorsqu’un serveur de transfert les relaie vers le destinataire final.

Comprendre pourquoi le transfert compromet DMARC, ce qui échoue pendant le processus de transfert et comment mettre en œuvre des politiques compatibles avec le transfert aide les organisations à appliquer des protections anti-usurpation sans bloquer les communications commerciales légitimes.

I. Pourquoi le transfert d’e-mails provoque des échecs DMARC

L’alignement DMARC exige que SPF ou DKIM réussisse l’authentification et s’aligne avec le domaine dans l’en-tête From:. Lorsqu’un transfert se produit, les deux mécanismes d’alignement peuvent échouer.

SPF échoue pendant le transfert

SPF authentifie le serveur d’envoi par rapport au domaine listé dans l’adresse MAIL FROM de l’enveloppe. Lorsqu’un message est transféré, le serveur de transfert devient le nouveau serveur d’envoi. L’enregistrement SPF d’origine n’autorise pas l’adresse IP du serveur de transfert, donc l’authentification SPF échoue à la destination finale.

Exemple de flux :

1. [email protected] envoie un e-mail à [email protected]
2. [email protected] transfère le message à [email protected]
3. Le serveur de transfert (office.net) livre le message à personal.com
4. personal.com vérifie SPF pour company.com par rapport à l’IP du serveur de transfert
5. Le serveur de transfert n’est pas dans l’enregistrement SPF de company.com
6. SPF échoue

Le MAIL FROM de l’enveloppe référence toujours company.com, mais l’IP d’envoi appartient maintenant à office.net. La recherche SPF renvoie fail ou softfail.

DKIM peut échouer lorsque le contenu change

DKIM signe les en-têtes et le corps du message à l’aide d’une signature cryptographique. Si le serveur de transfert modifie le message – comme l’ajout d’un pied de page, la modification de la ligne d’objet ou l’altération de la structure MIME – la vérification de la signature DKIM échoue.

Modifications de transfert courantes qui compromettent DKIM :

• Ajout d’un avis de transfert ou d’une clause de non-responsabilité au corps du message
• Ajout de [Fwd:] ou [External] à la ligne d’objet
• Conversion du HTML en texte brut ou modification des limites MIME
• Suppression des pièces jointes ou modification de l’encodage

Même de petits changements invalident la signature. Lorsque DKIM échoue, le message transféré perd sa preuve d’authentification.

L’alignement DMARC échoue même lorsque DKIM réussit

Même lorsque le serveur de transfert ne modifie pas le message et que la vérification DKIM réussit, DMARC peut toujours échouer en raison des exigences d’alignement.

DMARC exige que le domaine dans l’en-tête From: corresponde au domaine dans l’expéditeur d’enveloppe SPF (alignement souple ou strict) ou au domaine dans la signature DKIM (alignement souple ou strict). Si SPF échoue et que DKIM réussit mais utilise un domaine différent (comme le serveur de transfert signant avec son propre domaine), l’alignement DMARC échoue.

Cela se produit généralement lorsque :

• La signature DKIM d’origine reste valide mais le domaine From: diffère du domaine de signature DKIM
• Le serveur de transfert ajoute sa propre signature DKIM, qui ne s’aligne pas avec le domaine From: d’origine
• SPF échoue et aucune signature DKIM alignée n’existe

II. Ce qui échoue, quand et avec quelle visibilité

Les échecs de transfert sont souvent silencieux pour l’expéditeur d’origine et l’utilisateur du transfert. Le message peut être rejeté ou mis en quarantaine sans retour clair.

Conditions d’échec

Quand l’échec est silencieux

• L’utilisateur du transfert ne reçoit pas de notification de rebond ou d’échec
• L’expéditeur d’origine ne voit pas d’échec de livraison car le message a atteint avec succès la boîte de transfert
• La destination finale rejette le message sans en informer l’utilisateur du transfert
• Les rapports agrégés DMARC montrent un échec d’authentification, mais l’expéditeur d’origine peut ne pas corréler l’échec avec le transfert

Quand l’échec est visible

• L’utilisateur du transfert remarque que les messages de certains expéditeurs n’arrivent plus à la destination finale
• Le fournisseur de boîte de réception finale envoie un avis de rejet à la boîte de transfert
• L’expéditeur d’origine reçoit un rebond si la destination finale génère une notification d’échec (rare)

III. Comment les organisations découvrent que le transfert compromet DMARC

La plupart des organisations découvrent les problèmes de transfert après être passées de p=none à p=quarantine ou p=reject. Les messages qui étaient livrés sans problème cessent soudainement d’atteindre les destinations transférées.

Chemins de découverte courants :

• Les employés signalent que les messages transférés de clients, fournisseurs ou partenaires n’arrivent plus
• Les équipes commerciales remarquent que les transferts automatiques vers les systèmes CRM échouent
• Les transferts du service d’assistance des systèmes de billetterie vers les e-mails personnels cessent de fonctionner
• Les cadres utilisant le transfert d’e-mails de comptes d’entreprise vers des appareils personnels perdent des messages

Les rapports agrégés DMARC montrent des échecs d’authentification provenant des adresses IP du serveur de transfert, mais les rapports n’identifient pas explicitement le transfert comme cause. L’analyse des rapports nécessite de corréler les sources d’échec avec les configurations de transfert connues.

IV. Comment mettre en œuvre des politiques DMARC compatibles avec le transfert

Les organisations ne peuvent pas contrôler comment les serveurs de transfert tiers gèrent les messages. Cependant, elles peuvent ajuster les politiques DMARC, surveiller les modèles d’échec et éduquer les utilisateurs sur les alternatives au transfert.

Échelonner l’application par flux de courrier, pas par pourcentage

Au lieu d’utiliser pct= pour appliquer progressivement DMARC, échelonnez l’application par domaine, sous-domaine, groupe d’expéditeurs et maturité du flux de courrier. Appliquez p=reject aux domaines de grande valeur utilisés pour les transactions financières, les notifications de compte et les communications des cadres. Appliquez p=quarantine ou p=none aux domaines avec des modèles de transfert connus jusqu’à ce que des solutions alternatives soient mises en œuvre.

Évitez de vous appuyer sur le déploiement basé sur les pourcentages comme stratégie principale. Les programmes actuels compatibles DMARC doivent échelonner l’application par domaine, sous-domaine, groupe d’expéditeurs et fonction commerciale.

Utiliser des sous-domaines pour les flux de courrier à fort transfert

Si un flux de courrier spécifique est fréquemment transféré – comme les bulletins d’information, les rapports automatisés ou les notifications internes – envoyez depuis un sous-domaine avec une politique DMARC moins restrictive. Cela isole les échecs de transfert du courrier transactionnel de grande valeur.

Exemple :

• company.com → p=reject (transactionnel, sécurité du compte)
• reports.company.com → p=none (rapports automatisés, bulletins d’information)

Cette approche préserve la protection anti-usurpation sur le domaine principal tout en permettant aux flux de courrier transférés de passer.

Éduquer les utilisateurs sur les alternatives au transfert

Le transfert est souvent utilisé par commodité, mais des alternatives réduisent les échecs d’alignement DMARC :

• Utiliser l’accès IMAP ou POP natif au lieu du transfert. La plupart des clients de messagerie prennent en charge la gestion de plusieurs comptes.
• Utiliser la délégation d’e-mail (comme « Accorder l’accès à votre compte » de Gmail ou « Envoyer au nom de » de Microsoft 365) pour gérer plusieurs boîtes de réception sans transfert.
• Utiliser des alias d’e-mail dans le même domaine au lieu de transférer vers des adresses externes.
• Utiliser des listes de distribution ou des boîtes de réception partagées pour le routage du courrier d’équipe au lieu de règles de transfert individuelles.

Surveiller les rapports agrégés pour les modèles de transfert

Les rapports agrégés DMARC incluent l’adresse IP source, les résultats d’authentification et le nombre de messages. Les échecs de transfert montrent généralement :

• Échec SPF provenant d’adresses IP appartenant à des fournisseurs de transfert connus (Google Workspace, Microsoft 365, fournisseurs d’hébergement d’e-mails)
• Réussite ou échec DKIM selon que le message a été modifié
• Échec d’alignement si DKIM réussit mais ne s’aligne pas

L’examen de ces modèles aide à identifier quelles destinations de transfert provoquent des échecs et si le volume justifie des ajustements de politique.

Dans un déploiement Skysnag géré, utilisez la destination de rapport générée par Skysnag. Ce qui suit est un exemple manuel uniquement :

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; fo=1

Un enregistrement statique traditionnel peut fonctionner, mais seulement si les rapports sont activement reçus, analysés et exploités. Skysnag Protect agrège et analyse automatiquement les rapports DMARC pour faire ressortir les modèles de transfert et identifier les expéditeurs affectés.

Envisager le support ARC (Authenticated Received Chain)

ARC est un protocole conçu pour préserver les résultats d’authentification à travers les serveurs intermédiaires, y compris les systèmes de transfert. Lorsqu’un message passe par un serveur de transfert prenant en charge ARC, le serveur ajoute un ensemble d’en-têtes ARC qui enregistre les résultats d’authentification d’origine. La destination finale peut évaluer la chaîne ARC pour déterminer si le message a été authentifié avant le transfert.

ARC ne résout pas seul les échecs de transfert. Le serveur de réception final doit honorer les en-têtes ARC, et le serveur de transfert doit implémenter ARC correctement. En 2026, le support ARC se développe parmi les principaux fournisseurs de boîtes de réception, mais il n’est pas universellement déployé.

Les organisations ne peuvent pas contrôler si les serveurs de transfert ou les destinations finales prennent en charge ARC. Cependant, la surveillance des en-têtes liés à ARC dans les rapports forensiques DMARC peut aider à identifier si les systèmes de transfert tentent de préserver l’authentification.

V. Ce qui peut mal tourner après l’ajustement de la politique

L’ajustement des politiques DMARC pour accommoder le transfert introduit de nouveaux risques.

Affaiblir la politique sur le domaine principal

Réduire l’application DMARC sur le domaine principal pour empêcher les échecs de transfert réduit la protection anti-usurpation. Les attaquants peuvent exploiter la politique affaiblie pour envoyer des e-mails non authentifiés depuis le domaine.

Exemple d’échec :

• company.com passe de p=reject à p=quarantine pour autoriser les messages transférés
• Un attaquant usurpe [email protected] pour envoyer un e-mail de phishing
• Le message usurpé échoue DMARC mais est mis en quarantaine au lieu d’être rejeté
• Certains destinataires récupèrent le message de la quarantaine et tombent victimes de l’attaque de phishing

Désalignement de la politique de sous-domaine

L’utilisation de sous-domaines pour les flux de courrier à fort transfert ne fonctionne que si la politique DMARC du sous-domaine est explicitement définie. Si le sous-domaine hérite de la politique p=reject du domaine parent via la balise sp=, les échecs de transfert persistent.

Exemple d’échec :

• company.com → p=reject; sp=reject
• reports.company.com est créé pour le courrier transféré
• reports.company.com hérite de p=reject du domaine parent
• Les messages transférés échouent toujours DMARC et sont rejetés

Publiez toujours un enregistrement DMARC séparé pour les sous-domaines ayant des besoins d’application différents.

Lacunes dans l’éducation des utilisateurs

Recommander des alternatives au transfert ne garantit pas l’adoption par les utilisateurs. Les employés peuvent continuer à utiliser des règles de transfert si les alternatives ne sont pas clairement communiquées, documentées ou soutenues par l’IT.

Exemple d’échec :

• L’IT annonce que le transfert d’e-mails provoque des échecs DMARC et recommande l’accès IMAP
• Les employés ne comprennent pas comment configurer IMAP ou manquent de politiques de gestion des appareils mobiles
• Les employés continuent de transférer des e-mails et signalent que des messages de fournisseurs et clients sont manquants
• L’IT dépanne manuellement les cas individuels sans aborder le comportement racine

Les alternatives au transfert nécessitent une formation des utilisateurs, une documentation claire et un soutien IT pour réussir.

VI. Comment Skysnag Protect aide à identifier et résoudre les échecs de transfert

Skysnag Protect agrège les rapports DMARC, identifie les échecs d’authentification liés au transfert et fait ressortir les modèles indiquant que les flux de courrier légitimes sont affectés par le transfert.

Skysnag Protect :

• Identifie les adresses IP source appartenant à des services de transfert connus et met en évidence les échecs DMARC provenant de ces adresses
• Montre si SPF, DKIM ou les deux ont échoué pendant le transfert
• Suit le volume de messages des sources de transfert pour aider à prioriser les ajustements de politique
• Fournit une visibilité sur les expéditeurs et flux de courrier les plus affectés par le transfert
• Génère des rapports qui aident les équipes IT à éduquer les utilisateurs sur les alternatives au transfert et surveiller l’adoption

Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et progresser vers l’application sans bloquer les messages transférés critiques pour l’entreprise. Commencez la surveillance DMARC sur.

VII. Points clés à retenir

• Le transfert d’e-mails compromet DMARC car SPF échoue lorsque le serveur de transfert n’est pas autorisé par l’enregistrement SPF de l’expéditeur d’origine.
• DKIM peut échouer si le serveur de transfert modifie le corps du message, la ligne d’objet ou la structure MIME.
• Même lorsque DKIM réussit, l’alignement DMARC peut échouer si le domaine From: ne correspond pas au domaine de signature SPF ou DKIM.
• Les échecs de transfert sont souvent silencieux pour l’expéditeur d’origine et l’utilisateur du transfert. La destination finale rejette ou met en quarantaine le message sans retour clair.
• Les organisations doivent échelonner l’application DMARC par domaine et flux de courrier, pas par pourcentage. Utilisez des sous-domaines pour les flux de courrier à fort transfert.
• Éduquez les utilisateurs sur les alternatives au transfert : accès IMAP, délégation d’e-mail, alias et boîtes de réception partagées.
• Surveillez les rapports agrégés DMARC pour identifier les modèles de transfert et quantifier l’impact.
• Skysnag Protect fait ressortir les échecs liés au transfert, suit les flux de courrier affectés et aide à prioriser les ajustements de politique sans affaiblir la protection anti-usurpation.