Le transfert d’e-mails ne fonctionne pas : diagnostic en 6 étapes

Le transfert de vos e-mails ne fonctionne pas. Des messages manquent, l'expéditeur ne voit aucun avis d'échec et les règles semblent correctes dans les consoles consultées. Sans erreur visible, il faut suivre le parcours du message et réunir les traces disponibles.

Un transfert d'e-mail qui ne fonctionne pas peut venir d'une règle, d'une adresse, d'une politique ou de l'authentification SPF, DKIM et DMARC. Le destinataire voit l'adresse IP du relais, qui peut ne pas être autorisée par le domaine d'origine. Selon les contrôles et la politique, le message peut être refusé, classé en spam ou écarté sans avis visible. Examiner les résultats permet de distinguer ces situations.

Parcourez cette liste avant de modifier le DNS. Le guide complet de configuration et de dépannage des transferts explique les limites de SPF et le rôle de SRS et ARC. Cet article propose un diagnostic rapide lorsqu'un transfert pose problème maintenant.

Pourquoi un transfert peut échouer sans erreur visible

Le résultat dépend du moment et du serveur concernés. Un refus SMTP peut produire un avis ; après acceptation, une notification ultérieure, une quarantaine ou un abandon peuvent survenir selon la politique. L'avis suit l'expéditeur d'enveloppe, qui n'est pas nécessairement l'expéditeur affiché. Consultez journaux et files d'attente : l'absence d'avis ne suffit pas à identifier un échec DMARC.

Les en-têtes et les journaux sont utiles quand aucune erreur n'apparaît. Une règle active n'exclut pas un filtrage au destinataire ou une attente dans une file. Les six vérifications suivantes proposent un ordre pratique de contrôle. Vérifier d'abord le spam peut éviter, par exemple, 45 minutes de modifications DNS sans rapport avec le problème.

Diagnostic en 60 secondes : identifier le symptôme

Consacrez 60 secondes, à titre indicatif, à classer le symptôme avant de changer les paramètres. Il oriente les recherches sans prouver une cause à lui seul. Ces quatre situations indiquent une première vérification.

Liste de contrôle d'un transfert défaillant

Commencez par l'étape 1 et l'étape 2 : indésirables et avis de non-remise apportent des indices sans toucher au DNS. Cela peut éviter, par exemple, 45 minutes de changements inutiles. Suivez les étapes et arrêtez-vous lorsque les preuves désignent la cause.

Étape 1 : vérifier les indésirables du destinataire

Contrôle initial  |  Symptôme : aucun message ni avis

Sans avis, le message peut être dans les indésirables, mais aussi en quarantaine ou en attente. Lors d'un transfert de client@gmail.com vers you@outlook.com, le destinataire peut voir l'IP du relais au lieu d'une IP autorisée par le SPF d'origine. SPF peut échouer ; une signature DKIM conservée, valide et alignée peut toutefois suffire à DMARC. Le classement dépend ensuite des contrôles et de la politique du destinataire.

Action : connectez-vous à la boîte finale et examinez spam et courrier indésirable.

Correction : marquez le message légitime comme “Non indésirable”. Côté serveur, Sender Rewriting Scheme (SRS) peut réécrire l'expéditeur d'enveloppe pour que SPF évalue le domaine du relais. Ce domaine n'est pas automatiquement aligné sur le From d'origine. Sans SRS, un DKIM aligné peut aussi permettre la réussite de DMARC ; aucun réglage n'écarte tous les filtres futurs.

Étape 2 : lire l'avis de non-remise et son code NDR

Lecture de l'erreur  |  Symptôme : avis “Non remis”

Le code SMTP et son texte permettent de cibler les recherches. Lisez également le serveur à l'origine de l'erreur et l'adresse concernée. Le sujet seul, ou un code sorti de son contexte, ne donne pas toujours une cause unique.

Étape 3 : contrôler l'alignement DMARC

Contrôle d'authentification vers Gmail, Yahoo et Outlook  |  Symptôme : absence ou refus

DMARC peut être en cause. Une politique p=reject ne signifie pas que les transferts échouent dans 100% des cas sans SRS ou ARC : DKIM peut rester valide et aligné. DMARC réussit si SPF ou DKIM passe avec un domaine aligné sur le From visible. Le destinataire applique sa politique ; SRS n'aligne pas automatiquement l'enveloppe réécrite sur le From d'origine.

Interrogez la politique DMARC du domaine d'origine dans un terminal :

dig _dmarc.originalsender.com TXT +short

La présence de p=reject ne prouve pas le refus de ce message. Examinez les résultats : SPF peut échouer à cause de l'IP du relais, tandis que DKIM peut survivre ou échouer après une modification du contenu signé. L'alignement compare les domaines authentifiés au From, pas l'expéditeur d'enveloppe à la signature DKIM.

Correction : envisagez un transfert côté serveur avec SRS et ARC lorsque pertinent. ARC permet de vérifier une chaîne de résultats antérieurs ; le destinataire décide s'il fait confiance au relais et comment il les utilise. Cela ne garantit ni réussite DMARC ni remise. Filtres Gmail, règles Outlook et redirections cPanel ont des implémentations différentes ; cPanel peut transférer côté serveur. Vérifiez les capacités réelles du service.

Étape 4 : examiner le transfert sortant Microsoft 365

Contrôle des politiques Office 365  |  Symptôme : NDR 550 5.7.520

Une politique Microsoft 365 peut bloquer volontairement le transfert externe pour réduire la sortie non autorisée de données. Une règle utilisateur ne contourne pas les restrictions de l'organisation. Confirmez destination, besoin et approbation avant toute activation. Le parcours suivant est indicatif et peut évoluer ; ne modifiez pas la politique par défaut pour tout le tenant sans justification.

1. Accédez avec autorisation à Microsoft 365 Defender
2. Cherchez E-mail et collaboration → Stratégies et règles → Stratégies de menace → Anti-spam
3. Examinez la stratégie anti-spam sortante et son périmètre ; préférez une exception approuvée ciblée à une extension générale de Default
4. Consultez Modifier les paramètres de protection
5. Dans le périmètre approuvé seulement, évaluez Règles de transfert automatique et Activé : le transfert est autorisé

Une option grisée peut dépendre de vos permissions ou d'une politique de l'organisation. Faites intervenir l'administrateur autorisé plutôt que de contourner la restriction par une règle personnelle. Vérifiez ensuite l'effet réel et conservez l'approbation.

Étape 5 : chercher les boucles de routage

Contrôle du routage  |  Symptôme : erreur 5.4.14 ou copies multiples

Une boucle peut apparaître lorsque A transfère vers B, puis B renvoie vers A. Le message peut circuler jusqu'à une limite de sauts ou un autre contrôle. Vérifiez par exemple un catch-all du domaine A envoyé à B et une règle de B renvoyant certaines adresses vers A.

Recherchez ces en-têtes dans les messages retardés ou dupliqués :

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To répété avec la même adresse

Le guide du routage catch-all de domaine aide à construire des routes sans cycle. Une destination finale explicite facilite le contrôle. Un alias ou un autre relais n'impose pas une boucle, mais nécessite de vérifier la chaîne complète et ses limites.

Étape 6 : confirmer le destinataire dans Gmail

Contrôle d'activation  |  Symptôme : règle présente mais inactive

Dans Gmail personnel, une confirmation de l'adresse de destination peut encore être nécessaire. Contrôlez son état, puis vérifiez que le transfert est sélectionné dans les paramètres. La présence d'une adresse enregistrée ne suffit pas à l'activer.

Action : cherchez la confirmation “Gmail Team” dans la boîte destinataire, y compris les indésirables. Vérifiez que la demande est légitime et autorisée avant d'ouvrir le lien. Si elle manque ou a expiré, consultez Paramètres Gmail → Transfert et POP/IMAP et recommencez la vérification selon le parcours actuel.

Lire les en-têtes pour diagnostiquer un transfert

Un message classé en spam a bien atteint la boîte. Authentification, réputation, contenu et autres signaux peuvent expliquer le classement. Authentication-Results fournit des résultats de contrôle, pas l'explication de chaque échec. Examinez qui a ajouté l'en-tête et comparez aux journaux ; un en-tête fourni par une source non fiable n'est pas une preuve.

Pour consulter les en-têtes, selon la version du client :

• Gmail : ouvrir le message → menu à trois points → “Afficher l'original”
• Outlook : Fichier → Propriétés → En-têtes Internet dans les versions compatibles

Exemple illustratif de résultats avec SRS et ARC, pas un modèle canonique d'en-tête ni une preuve de remise. Vérifiez l'authentification, l'alignement et la chaîne ARC réels :

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

Le préfixe SRS0= dans Return-Path correspond à une forme courante de réécriture. Son absence ne prouve pas que tous les transferts échouent ; examinez l'enveloppe et l'implémentation. Gmail, Yahoo et Outlook appliquent des règles distinctes. Les exigences Google pour les expéditeurs en masse de 2024 ne couvrent pas tous les domaines professionnels ni tous les destinataires.

Quand le transfert défaillant affecte l'activité

Un message client, un contrat ou une demande de support non reçu peut retarder une relation commerciale. Le problème n'apparaît parfois qu'à la relance demandant pourquoi personne n'a répondu. Alertes, journaux et tests contribuent à détecter ces lacunes.

Le diagnostic manuel est utile, mais plusieurs domaines nécessitent un suivi continu. Un changement d'authentification ou de politique peut modifier le résultat. Google Postmaster Tools propose des données agrégées de réputation, signalements de spam et autres indicateurs pour le trafic éligible vers Gmail personnel, avec seuils de volume et délais. Un échec d'authentification ne crée pas automatiquement un signalement et n'affecte pas nécessairement tous vos envois.

Réduire les incidents récurrents

Si le transfert échoue régulièrement, examinez l'infrastructure, la conservation de DKIM et les fonctions SRS et ARC en plus des règles. Une conception adaptée peut réduire les recherches répétées, tout en exigeant surveillance et revue des politiques.

Gestion dispersée : examiner les règles Gmail ou cPanel, rechercher les erreurs SPF par domaine et demander des modifications approuvées des politiques M365 lorsque les besoins évoluent.

Modèle TrekMail : définir les routes dans le tableau de bord et vérifier le traitement SRS et ARC côté serveur selon les fonctions disponibles. La remise dépend toujours du destinataire et des paramètres.

TrekMail décrit un transfert au niveau de Postfix, avec réécriture SRS et scellement ARC avant la remise suivante. Confirmez le fonctionnement actuel et la conservation des signatures DKIM d'origine lors des modifications. ARC rapporte des résultats antérieurs ; il ne maintient pas à lui seul une signature valide après changement du contenu signé et ne garantit pas l'acceptation par Gmail, Outlook ou Yahoo.

Pour une agence gérant des dizaines de domaines, la centralisation peut simplifier le travail. Au lieu de consulter, par exemple, 30 consoles, configurez et vérifiez chaque route avec les droits appropriés. Le guide de gestion de la messagerie des clients explique les chaînes multidomaines sans boucles A→B→A comme à l'étape 5.

La description historique place le transfert ARC et SRS dans Pro à $10/mois (100 domaines, 50GB) et Agency à $23.25/mois (1,000+ domaines), avec essai de 14 jours. Vérifiez fonctions, quotas, couverture de l'essai et besoin de carte avant de souscrire : comparez les offres sur trekmail.net/pricing.

Réduisez les tickets récurrents grâce à des paramètres vérifiés et au suivi. Découvrez le traitement SRS et ARC de TrekMail et vérifiez les fonctions actuelles.