Le transfert d'e-mails est probablement l'une des premières fonctions que vous configurez lorsque vous possédez un domaine. C'est aussi souvent la première qui cesse discrètement de fonctionner.
En apparence, rien de plus simple : prendre les messages envoyés à info@yourdomain.com et les rediriger vers votre compte @gmail.com. En pratique, le transfert est une opération d'intermédiaire qui entre directement en conflit avec les principaux modèles de confiance de l'Internet moderne : SPF, DKIM et DMARC. En cas d'erreur, le message ne revient pas avec une alerte spectaculaire. Il disparaît simplement.
Pour un fondateur, un transfert défaillant peut faire manquer les e-mails d'investisseurs. Pour un MSP qui gère 50 domaines clients, il peut provoquer une avalanche de tickets d'assistance un lundi matin.
Ce guide explique le fonctionnement réel du transfert au niveau du protocole, ses défaillances prévisibles et la manière de créer une configuration qui résiste aux politiques DMARC strictes en 2026.
Le modèle mental : pourquoi le transfert d'e-mails est plus complexe qu'il n'y paraît
Avant de réparer un transfert, il faut comprendre ce qui se passe dans la couche SMTP. Il ne s'agit pas de faire passer un mot, mais de réexpédier une lettre. Cette distinction est capitale.
Lorsque le serveur A envoie un e-mail à votre serveur (le serveur B, chargé du transfert), puis que le serveur B le relaie vers la destination finale (le serveur C), un changement d'identité déterminant se produit. Le serveur de destination voit l'adresse IP du serveur B, pas celle du serveur A. C'est la cause de presque toutes les défaillances de transfert.
Enveloppe et en-tête : les deux identités d'un e-mail
Chaque e-mail possède deux couches d'identité distinctes, que le transfert désynchronise :
- L'enveloppe (P1) : ce que les serveurs utilisent pour acheminer physiquement le message. Elle contient le
Return-Path. SPF valide cette couche. - L'en-tête (P2) : ce que votre client affiche comme adresse d'expéditeur. Les contrôles d'alignement DKIM et DMARC utilisent cette couche.
Voici le problème. Lors du transfert, votre serveur ouvre une nouvelle connexion SMTP vers la destination. SPF compare l'IP d'envoi à l'enregistrement SPF de l'expéditeur d'origine, mais l'IP du serveur de transfert n'y est pas autorisée. SPF échoue. Si l'expéditeur applique une politique DMARC stricte (p=reject) et que SRS n'est pas mis en place, le serveur de destination rejette le message.
Une analogie concrète : Alice envoie une lettre à Bob. Bob place la lettre d'Alice dans une nouvelle enveloppe portant sa propre adresse de retour et l'expédie à Carole. Carole demande à Alice si elle l'a envoyée depuis l'adresse de Bob. Alice répond que non. C'est un échec DMARC, auquel le serveur de Carole réagit en conséquence.
Comprendre cette séparation entre enveloppe et en-tête est fondamental. Toutes les corrections de ce guide en découlent.
Transfert, alias et catch-all : comprendre la différence
Les opérateurs confondent constamment ces trois méthodes de routage. Choisir la mauvaise mène rapidement à un ticket « e-mail introuvable » dont le diagnostic prend trois heures.
Transfert d'e-mails
Il prend un message envoyé à une adresse et le remet à un serveur entièrement différent, par exemple contact@startup.com → founder@gmail.com. Il y a un saut réseau. Les chaînes d'authentification se rompent si elles ne sont pas traitées explicitement. C'est une bonne solution pour regrouper plusieurs domaines dans une seule boîte. Risque : élevé sans gestion correcte de SRS/ARC. Consultez notre analyse des compromis entre alias et transfert.
Alias d'e-mail
Il s'agit d'un autre nom pour une boîte existante sur le même serveur. support@company.com remet le courrier dans la même boîte que admin@company.com, sans saut réseau ni changement d'authentification. Idéal pour une personne qui remplit plusieurs rôles. Risque : faible. Pour savoir quand les alias atteignent leurs limites et quand une boîte complète devient nécessaire, consultez notre guide de choix entre alias et boîte.
Catch-all (routage générique)
Il accepte tout e-mail envoyé à une adresse inexistante de votre domaine, *@domain.com. Utile pour récupérer les fautes de frappe ou les adresses de campagnes ponctuelles. Risque : critique s'il pointe directement vers Gmail. Chaque spam visant votre domaine arrive dans votre boîte et Gmail peut finir par considérer votre serveur de transfert comme une source de spam. Si vous utilisez un catch-all, isolez-le. Notre guide de configuration de l'e-mail professionnel détaille ces compromis.
| Méthode | Saut réseau ? | Risque d'authentification | Usage recommandé |
|---|---|---|---|
| Transfert | Oui | Élevé (SPF/DMARC échouent) | Routage entre domaines ou fournisseurs |
| Alias | Non | Aucun | Plusieurs rôles, même boîte |
| Catch-all | Selon la configuration | Critique (aimant à spam) | Fautes de frappe, adresses jetables |
Méthodes de configuration : la bonne, la mauvaise et celle qui ne fonctionne pas
Il existe trois façons de configurer le transfert. Deux risquent de vous poser problème. Une fonctionne généralement de façon fiable en production.
1. Routage côté fournisseur (la bonne méthode)
Il intervient au niveau du MTA, avant que le message n'atteigne une boîte. Le serveur reçoit l'e-mail, réécrit l'enveloppe avec SRS et le relaie immédiatement. Aucune licence de boîte payante n'est nécessaire. Aucun espace de stockage n'est consommé. SPF et ARC sont gérés dans la couche d'infrastructure.
C'est l'approche sur laquelle il est judicieux de s'appuyer. Les routes de transfert TrekMail fonctionnent ainsi : vous définissez la destination et l'infrastructure gère les en-têtes d'authentification. Suivez le guide de configuration du transfert de boîte pour les étapes exactes.
2. Règles de boîte (l'ancienne méthode)
Vous créez un compte utilisateur complet, payez $6-$30/month pour une licence dont vous n'avez pas réellement besoin, vous connectez et ajoutez une règle : « Si un message arrive, le transférer vers X ».
Certains cas particuliers la justifient : transfert conditionnel (« ne transférer que les factures »), exigences d'audit ou nécessité de stocker localement le message avant son relais. Mais, dans la plupart des configurations, vous payez une place uniquement pour acheminer du courrier. Cette méthode rompt aussi DMARC comme tout autre transfert, et Microsoft 365 bloque par défaut le transfert automatique (voir la section sur les défaillances).
3. Transfert côté client (à éviter entièrement)
Il s'agit d'une règle définie dans Outlook Desktop ou Apple Mail sur votre ordinateur. Votre portable doit être allumé, actif et connecté à Internet pour que le transfert s'effectue. Cela ne fonctionne ni pendant vos déplacements, ni durant un redémarrage, ni à 2am lorsque l'e-mail important arrive.
Aucun scénario de production n'en fait le bon choix. Si vous en dépendez aujourd'hui, corrigez cette configuration.
Liste de contrôle pour une configuration sûre
Avant d'activer une route de transfert, effectuez ces quatre contrôles. En omettre un finira probablement par vous causer des difficultés.
1. Test de boucle
Vérifiez que l'adresse de destination ne renvoie pas vers l'adresse source. A→B→A forme une boucle infinie. Les serveurs modernes la détectent grâce aux limites de sauts et renvoient un NDR 5.4.14 hop count exceeded, mais votre réputation d'envoi peut déjà avoir souffert. Cartographiez les routes avant leur activation.
2. Test d'inspection des en-têtes
Envoyez un test depuis un compte externe (Gmail personnel, Yahoo ou tout service hors de votre domaine) vers l'adresse transférée. À destination, ouvrez les en-têtes complets et trouvez Authentication-Results. Vous devez idéalement voir spf=pass (grâce à la réécriture SRS) ou dkim=pass. Si dmarc=fail apparaît, la configuration n'est pas prête pour la production.
3. Test Reply-To
Répondez à un message transféré. La réponse va-t-elle à l'expéditeur d'origine ou à l'adresse du serveur de transfert ? Elle doit parvenir à l'expéditeur d'origine. Si elle va au serveur intermédiaire, la configuration de l'enveloppe est incorrecte et créera un fil de discussion déroutant.
4. Contrôle de la politique sortante
Si Microsoft 365 ou Google Workspace est la destination du relais, vérifiez que le transfert automatique est autorisé dans les paramètres du filtre antispam sortant. M365 le bloque par défaut. Une configuration incorrecte peut entraîner l'abandon silencieux des transferts, sans avertir l'expéditeur d'origine.
Modes de défaillance courants
Lorsque le transfert tombe en panne, il échoue presque toujours de l'une des manières précises suivantes. Reconnaître le schéma évite une heure d'examen désordonné des en-têtes.
1. Rejet silencieux par DMARC
C'est l'une des causes les plus courantes de disparition des e-mails en 2026, et elle est invisible : aucun NDR, aucune erreur, aucun signal. Le message n'arrive tout simplement pas.
Scénario : une banque, un prestataire de paiement ou un éditeur SaaS envoie vers votre domaine un e-mail assorti d'une politique DMARC stricte p=reject. Vous le transférez vers Gmail. L'IP du serveur de transfert fait échouer SPF. Si votre serveur modifie aussi le corps (ajout d'une mention) ou l'objet (ajout de [External]), DKIM échoue également. Échec SPF + échec DKIM = échec DMARC. Gmail le rejette.
La correction consiste à mettre en place SRS sur le serveur de transfert afin que SPF réussisse et à éviter toute modification du contenu pour préserver DKIM. Si vous ne maîtrisez pas l'infrastructure, choisissez un fournisseur qui s'en charge. Notre analyse de DMARC et de l'e-mail sécurisé approfondit les échecs propres aux chaînes de transfert.
2. Blocage Microsoft 550 5.7.520
Symptôme : l'expéditeur d'origine reçoit un NDR portant le code 550 5.7.520 Access denied, your organization does not allow external forwarding.
Le filtre antispam sortant de M365 remplit exactement sa fonction : bloquer le transfert automatique vers des adresses externes. La correction exige d'accéder au portail Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → régler « Automatic forwarding rules » sur « On: forwarding is enabled ».
Ce parcours est peu intuitif et difficile à trouver. Toutefois, le code d'erreur fournit un diagnostic précis : lorsqu'il apparaît, vous savez où intervenir.
3. Boucle de réponse automatique
L'utilisateur A transfère vers l'utilisateur B. B configure une réponse automatique. A écrit à B. La réponse automatique de B repart vers A. Le serveur de A la transfère à B. Le serveur de B répond à nouveau.
Les serveurs modernes emploient des en-têtes tels que X-Loop et X-Auto-Response-Suppress pour détecter et arrêter cette situation. Les installations anciennes ou mal configurées peuvent encore produire des milliers de messages en quelques minutes. Contrôlez les réponses automatiques lors de la mise en place de transferts entre comptes.
4. Rupture de DKIM après modification
DKIM signe un hachage cryptographique du contenu. Dès qu'un élément de la partie signée change, même l'ajout d'un pied de page d'une ligne, la signature devient invalide. De nombreux systèmes d'entreprise ajoutent une mention juridique à chaque message sortant. Si elle est ajoutée après la création de la signature DKIM, celle-ci sera invalide à destination.
Si les en-têtes d'un message transféré indiquent dkim=fail (body hash did not verify), c'est presque toujours la cause.
Procédure de diagnostic : symptôme → correction
| Symptôme | Cause probable | Étape de diagnostic |
|---|---|---|
L'expéditeur reçoit un NDR 5.7.1 | SPF / relais refusé | Vérifiez si l'IP du serveur de transfert figure sur une liste de blocage. Contrôlez l'authentification SPF dans les en-têtes. |
L'expéditeur reçoit un NDR 5.4.14 | Boucle de routage | Auditez toutes les règles pour repérer les chemins circulaires (A → B → A). |
| Aucun e-mail, aucun NDR (rejet silencieux) | Rejet DMARC / filtre antispam | Consultez le dossier spam ou courrier indésirable de destination. Recherchez dmarc=fail dans les en-têtes. |
550 5.7.520 Access denied | Blocage de la politique sortante M365 | Modifiez la politique antispam sortante de M365 Defender : activez le transfert automatique. |
| L'e-mail arrive, mais son affichage est altéré | Échec du hachage du corps DKIM | Recherchez dkim=fail (body hash did not verify). Désactivez l'injection de pieds de page ou de mentions. |
| La réponse va au serveur de transfert, pas à l'expéditeur | Mauvaise configuration Reply-To / enveloppe | Vérifiez que le transfert préserve l'en-tête Reply-To de l'expéditeur d'origine. |
Pourquoi le transfert échoue en production (SRS et ARC expliqués)
De simples règles ne suffisent pas dans un environnement de production. Il faut une infrastructure qui comprend SRS et ARC. Voici le rôle exact de chacun et la raison pour laquelle les deux comptent.
SRS : Sender Rewriting Scheme
SRS corrige l'échec SPF causé par le saut réseau. Votre serveur réécrit l'adresse d'expéditeur de l'enveloppe pour permettre à la destination de valider SPF sur votre domaine plutôt que celui de l'expéditeur d'origine.
Avant SRS :
MAIL FROM: alice@bank.comAprès réécriture SRS :
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comLe serveur de destination contrôle SPF sur forwarder.com. Ce contrôle réussit, car votre serveur est autorisé. Les rebonds continuent d'être acheminés vers alice@bank.com grâce à l'adresse encodée. SPF est validé sans rompre le chemin des rebonds.
SRS est essentiel. Sans lui, chaque message transféré provenant d'un expéditeur au SPF strict échouera à l'authentification à destination. Pour tout comprendre de SRS dans les chaînes de transfert, consultez notre guide détaillé de configuration de l'e-mail sur votre domaine. Pour un routage vers Gmail, suivez notre guide expliquant comment transférer l'e-mail de domaine vers Gmail en configurant correctement SRS et « Envoyer des e-mails en tant que ».
ARC : Authenticated Received Chain
SRS corrige SPF, mais ne résout pas entièrement l'alignement DMARC. ARC permet au serveur de transfert d'apposer une signature cryptographique déclarant : « J'ai vérifié l'authentification de ce message à sa réception, et elle était valide. »
Google et Microsoft reconnaissent les sceaux ARC d'intermédiaires de confiance. En présence d'un sceau fiable, ces fournisseurs peuvent accepter le message même si les contrôles SPF/DMARC d'origine échouent à cause du transfert. C'est en quelque sorte un registre de chaîne de conservation pour l'authentification des e-mails.
ARC est défini dans la RFC 8617 et constitue la norme actuelle de préservation de l'authentification lors des transferts légitimes. Sans ARC, une politique DMARC stricte p=reject de l'expéditeur peut faire rejeter les messages transférés par de grands fournisseurs, même si SRS est actif.
La zone à risque du catch-all
Le transfert est souvent associé au catch-all, une combinaison qui mérite un avertissement. Si un catch-all pointe vers Gmail, chaque spam visant une adresse aléatoire de votre domaine arrive chez Gmail, qui considère votre serveur de transfert comme la source. Les plaintes visant votre IP peuvent s'accumuler rapidement et dégrader aussi la réputation d'envoi des messages légitimes.
Si vous avez besoin d'un catch-all, isolez-le dans une boîte dédiée avec filtrage antispam côté serveur, plutôt que de le transférer vers une boîte personnelle. Notre guide de configuration de l'e-mail sur votre domaine décrit la méthode complète.
Le rôle de TrekMail
L'ancienne méthode imposait de construire son propre MTA compatible SRS et ARC, ou de payer des licences par utilisateur uniquement pour acheminer du courrier. Aucune option n'était adaptée aux opérateurs gérant plus de quelques domaines.
Payer Google ou Microsoft $6/user/month, avoir besoin de 10 adresses de transfert et potentiellement payer 10 places inutilisées, ou atteindre les limites d'alias et multiplier les contournements : c'est une taxe sur le routage.
TrekMail adopte un hébergement à tarif fixe. Vous payez une formule, pas des places. Les routes de transfert, alias et catch-all sont inclus, avec une gestion côté serveur et un transfert compatible SRS intégré à l'infrastructure. Vous définissez la route ; la plateforme gère les en-têtes d'authentification, l'application de TLS et la remise. Pas de frais par adresse ni de lutte avec les politiques antispam sortantes pour obtenir une fonction élémentaire.
Pour un fondateur seul, hello@yourdomain.com peut ainsi être acheminé de façon fiable vers Gmail en moins de cinq minutes, sans serveur de messagerie complet. Pour une équipe, chaque modification s'effectue dans le tableau de bord, sans fouilles DNS. Pour une agence gérant 100+ domaines clients, les règles sont centralisées et cohérentes, ce qui limite les échecs d'authentification transformés en escalades d'assistance à 6pm un vendredi.
La formule Pro ($10/month, ou $8/month en annuel) comprend le catch-all externe et le transfert de boîte. La formule Agency ($29/month) prend en charge 1,000+ domaines avec accès API pour la gestion groupée des routes. Toutes les formules payantes proposent un essai gratuit de 14-day (carte requise).
Découvrez la gestion du transfert à toute échelle sur trekmail.net.
Conclusion
Le transfert n'est pas une fonction que l'on configure puis oublie. C'est une opération de routage active qui touche aux principaux modèles d'authentification d'Internet. Les échecs sont prévisibles : SPF se rompt au changement d'IP, DKIM lors d'une modification du contenu, et DMARC rejette le message si l'alignement échoue. Ils peuvent être corrigés lorsque l'on comprend la couche protocolaire.
À retenir : utilisez le transfert côté serveur avec SRS et ARC, jamais des règles côté client. Testez les en-têtes avant la mise en service. Surveillez le blocage sortant de M365. Isolez le catch-all. Et si vous gérez plusieurs domaines, ne payez pas par utilisateur uniquement pour acheminer le courrier.
Avec une infrastructure adéquate, le transfert peut fonctionner de façon fiable. Avec une mauvaise configuration, vos messages les plus importants risquent de disparaître sans laisser de trace. Le choix n'est pas compliqué.
