Transférer un e-mail vers une autre adresse : diagnostic

Vous créez une règle de transfert. Vous envoyez un test. Tout fonctionne. Vous passez à autre chose.

Puis un client indique ne pas avoir reçu votre réponse. Aucun rebond ni avis de non-remise visible. Le message semble s'être perdu entre les serveurs ; les journaux peuvent expliquer son parcours.

Voici ce qui peut se produire quand vous transférez les e-mails vers une autre adresse : votre serveur ouvre une nouvelle connexion SMTP vers le destinataire. Celui-ci vérifie SPF avec votre IP, pas celle de l'expéditeur initial. Si elle n'est pas autorisée pour le domaine de l'expéditeur d'enveloppe, SPF peut échouer. Sans signature DKIM valide et alignée, DMARC échoue aussi. Avec p=reject, le destinataire peut rejeter le message selon sa politique ; cela ne signifie pas systématiquement une suppression silencieuse sans rebond.

Ce n'est pas forcément une faute de configuration. Le transfert peut entrer en conflit avec l'authentification moderne. Le guide complet de configuration et de dépannage du transfert d'e-mails détaille les différents scénarios. Cet article examine l'authentification : les types d'échec, les codes d'erreur et les mesures correctives.

Pourquoi l'authentification peut échouer lors d'un transfert

Le MTA destinataire vérifie SPF avec l'IP du serveur de transfert, et non celle de l'expéditeur initial. Un e-mail comporte deux niveaux d'identité que le transfert peut désaligner. SPF valide l'enveloppe ; DMARC exige un résultat SPF ou DKIM valide et aligné avec le domaine de l'expéditeur visible.

Le serveur A envoie au serveur de transfert B, qui ouvre une nouvelle connexion TCP vers C. C voit l'IP de B. SPF demande au DNS du domaine de l'expéditeur d'enveloppe : "Cette IP est-elle autorisée à envoyer pour votre domaine ?" Si le domaine initial n'autorise pas B et que l'enveloppe reste inchangée, SPF peut échouer. Ce n'est pas une conséquence universelle du transfert.

DMARC n'a besoin que d'un mécanisme SPF ou DKIM valide et aligné. Une signature DKIM initiale qui reste valide et alignée peut donc préserver la réussite DMARC. Les modifications des éléments signés peuvent invalider DKIM, selon les en-têtes signés et la canonicalisation. Sans mécanisme valide et aligné, DMARC échoue ; p=reject demande le rejet, sous réserve de la politique locale du destinataire.

Trois types de panne à prévoir

Sans mesures adaptées côté serveur, le transfert peut rencontrer ces trois catégories de problèmes. Les codes sont des exemples dépendant du fournisseur, pas des réponses systématiques. Reconnaître le cas aide à cibler le diagnostic.

1. Blocage sortant de Microsoft 365 (550 5.7.520)

Microsoft 365 peut bloquer le transfert externe, considéré comme un risque d'exfiltration. Si une règle transfère hors du tenant et que la politique applicable l'interdit, Exchange Online peut bloquer le message avant sa sortie.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Il s'agit d'une restriction administrative, pas d'une erreur de protocole. L'administrateur doit vérifier le périmètre autorisé :

1. Ouvrez le portail Microsoft 365 Defender.
2. Accédez à Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Modifiez la politique de filtrage du courrier indésirable sortant applicable aux utilisateurs ou groupes autorisés.
4. Réglez Automatic forwarding sur On - Forwarding is enabled uniquement pour ce périmètre approuvé.

Une activation globale accroît l'exposition en cas de compte compromis. Limitez l'exception aux comptes concernés, imposez la MFA et surveillez le volume sortant après le changement. Vérifiez aussi les autres restrictions de transfert en vigueur.

2. Double échec des mécanismes DMARC

Ce problème peut être difficile à repérer depuis la boîte aux lettres. SPF peut échouer à cause du changement d'IP si l'expéditeur d'enveloppe initial est conservé. DKIM peut encore permettre la réussite DMARC avec une signature valide et alignée. Une modification pertinente du corps ou d'un en-tête signé peut l'invalider ; toutes les modifications ne le font pas.

Modifications susceptibles de casser DKIM pendant le transit :

• Un antivirus ajoute une mention en pied de message : "Analysé par [Nom du produit]"
• La passerelle de destination ajoute [EXT] ou [EXTERNAL] à l'objet, si cet en-tête est signé
• Un bandeau "Expéditeur externe" est inséré dans le corps HTML
• Un logiciel de liste de diffusion réécrit des en-têtes signés ou ajoute un lien de désinscription en pied de message

Si ni SPF ni DKIM ne fournissent un résultat valide et aligné, DMARC (RFC 7489) échoue. Avec p=reject, le domaine demande un rejet, mais le destinataire choisit le traitement final. Un rejet SMTP, une quarantaine ou une autre action locale sont possibles ; une suppression sans rebond n'est pas certaine. Consultez les journaux et les rapports disponibles.

3. Boucles de routage (554 5.4.14)

Une boucle apparaît lorsque des serveurs se renvoient le même message jusqu'à la limite de sauts. Elle peut générer un avis de non-remise, dont le délai et le code varient selon le système. Elle peut aussi encombrer les files et retarder d'autres messages.

Situations à vérifier :

• L'utilisateur A transfère vers B, et une règle de B renvoie vers A.
• A transfère vers B, qui dispose d'une réponse d'absence. Si les règles autorisent des réponses répétées et que les protections sont insuffisantes, cette réponse peut repasser par le transfert et créer une boucle ; ce n'est pas automatique dans tous les systèmes.
• Une adresse catch-all transfère vers une boîte qui renvoie vers une adresse inexistante du même domaine, à nouveau prise en charge par le catch-all.

554 5.4.14 Hop count exceeded - possible mail loop

Vérifiez toute la chaîne de routage, y compris les réponses automatiques et les destinations catch-all, avant d'activer le transfert en production.

Les mesures correctives : SRS et ARC

Deux mécanismes côté serveur peuvent améliorer l'authentification du transfert, sans garantir la remise. SRS réécrit l'expéditeur d'enveloppe pour permettre la réussite SPF avec une configuration correcte. ARC conserve une chaîne authentifiée de résultats que le destinataire peut choisir d'utiliser malgré un échec DMARC. Ils nécessitent un support serveur, pas une simple règle du client.

SRS : Sender Rewriting Scheme

SRS réécrit l'expéditeur d'enveloppe (P1) avec un domaine que vous contrôlez. Au lieu de conserver alice@bank.com, dont le domaine n'autorise peut-être pas votre serveur, le relais utilise un Return-Path de ce type :

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF vérifie désormais votre domaine. Il peut réussir si son enregistrement autorise l'IP sortante et si l'évaluation DNS aboutit correctement. Cela n'aligne pas automatiquement ce domaine avec le From visible initial pour DMARC.

Le hash et l'horodatage servent à valider et acheminer les rebonds : un avis envoyé à une adresse SRS valide peut être décodé et renvoyé à Alice. Ces adresses ont une durée de validité limitée et un usage précis. La validation SRS ne remplace pas les contrôles de destinataires et de relais indispensables pour éviter un relais ouvert.

ARC : Authenticated Received Chain

SRS peut corriger SPF sans rétablir l'alignement entre l'enveloppe et l'en-tête. ARC (RFC 8617) ne comble pas cet écart. Le serveur ajoute un sceau cryptographique préservant les résultats d'authentification observés à la réception, afin de permettre la vérification de la chaîne.

Google et Microsoft peuvent tenir compte d'ARC provenant d'intermédiaires jugés fiables, selon leurs politiques. Une chaîne ARC valide et une bonne réputation ne garantissent ni l'acceptation ni le placement en boîte de réception : la décision finale appartient au destinataire.

ARC ressemble à un registre de traçabilité. Chaque intermédiaire participant ajoute une attestation signée des résultats observés. Les destinataires suivants peuvent vérifier la chaîne et décider de lui faire confiance lorsque l'alignement SPF ou DKIM ne suffit plus à satisfaire DMARC.

Gmail et Microsoft 365 prennent en charge ARC dans certains flux ; vérifiez les en-têtes et la configuration du parcours utilisé. Sans ARC sur votre serveur, ce contexte supplémentaire manque, mais DMARC peut toujours réussir grâce à une signature DKIM initiale valide et alignée.

Mise en œuvre : deux approches

Pour réduire les problèmes d'authentification du transfert, vous pouvez gérer votre MTA ou choisir un fournisseur qui confirme le support SRS et ARC pour votre flux. Aucune approche ne supprime tous les risques de remise ; des tests et une surveillance restent nécessaires.

Option A : Postfix + postsrsd (autogéré)

Sur un serveur Linux avec Postfix, postsrsd peut gérer SRS. Cet exemple illustre l'intégration TCP des anciennes versions. Les versions modernes utilisent socketmap, incompatible avec ces tables TCP ; consultez la documentation de la version installée, adaptez la configuration et testez-la avant de l'appliquer :

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Responsabilités associées :

• Gérer les clés secrètes SRS. Une fuite permet de forger des adresses SRS ; conservez des contrôles indépendants de relais et de destinataires.
• Définir les exclusions des domaines locaux selon votre topologie et votre version, pour éviter des réécritures inadaptées du courrier interne.
• Gérer la réputation de l'IP sortante, qui influence la remise à Gmail et Outlook sans la déterminer à elle seule.
• Configurer ARC séparément : postsrsd ne suffit pas à signer ARC.

Cette approche est viable avec une configuration validée. Elle demande toutefois un entretien continu, qu'un fournisseur peut prendre en charge en partie.

Option B : TrekMail (transfert géré)

Si vous choisissez TrekMail, confirmez au préalable le support SRS automatique et ARC pour votre formule et votre flux de transfert. Vérifiez aussi quels messages passent par des relais SMTP gérés. Ne supposez pas que ces fonctions sont incluses dans toutes les formules, ni que réputation et remise sont garanties.

Pour les fondateurs indépendants : payer $6/mois par boîte uniquement pour transférer info@yourdomain.com vers une boîte personnelle peut représenter un coût par utilisateur important. Le tarif de référence de Starter est $3.50/mois pour jusqu'à 50 domaines, sans frais par utilisateur ; confirmez le prix actuel, les limites et l'inclusion du transfert externe. Consultez le fonctionnement du transfert de boîtes dans TrekMail.

Pour les agences gérant le DNS de plusieurs clients, diagnostiquer SPF peut réduire les marges. Un tableau de bord commun peut simplifier la gestion, s'il couvre les flux nécessaires. Pour choisir entre alias et règles de boîte complètes, le guide du transfert par alias présente les compromis.

Liste de vérification avant un transfert

Vérifiez ces quatre points avant d'activer une règle en production. Ils réduisent les risques décrits, mais ne remplacent pas les tests de remise et l'examen des journaux.

1. SRS actif lorsque nécessaire. Examinez l'en-tête Return-Path d'un test remis. Si le flux utilise SRS, il doit contenir le domaine de transfert et un format SRS valide ; contrôlez aussi SPF.
2. Éviter les modifications du contenu signé. Configurez les protections pour ne pas ajouter de mentions antivirus en pied de message, de préfixes dans l'objet ou de bandeaux "Expéditeur externe" invalidant DKIM. Maintenez l'analyse de sécurité et des protections équivalentes, par exemple des avertissements hors du contenu signé. L'effet d'une modification dépend de la canonicalisation et des en-têtes signés.
3. Protection contre les boucles. Vérifiez les règles inverses, les réponses d'absence, les destinations catch-all et les limites de sauts. Une réponse automatique ne crée pas forcément une boucle, mais son comportement effectif doit être testé.
4. Politique sortante M365. Dans Exchange Online, autorisez "Automatic Forwarding" uniquement pour les utilisateurs ou groupes approuvés dans la politique sortante Defender. Vérifiez les autres restrictions et évitez l'activation globale par défaut.

Quand éviter le transfert vers une autre adresse

Le transfert externe n'est pas toujours nécessaire. Pour recevoir les messages de plusieurs domaines dans une boîte du même système, un alias de domaine peut éviter un saut SMTP externe supplémentaire. Les domaines doivent néanmoins être correctement configurés ; les responsabilités SPF/DKIM ne disparaissent pas toutes.

La comparaison entre alias de domaine et boîte aux lettres aide à choisir entre alias et règle de transfert complète. Si vous changez de fournisseur, vérifiez la disponibilité et les limites de l'outil de migration IMAP de TrekMail : copier les messages existants depuis la source ne remplace pas la transition du courrier entrant en direct.

Résumé

Lors d'un transfert, le destinataire voit l'IP du relais. Si l'expéditeur d'enveloppe initial est conservé et que cette IP n'est pas autorisée, SPF peut échouer. DMARC peut encore réussir grâce à DKIM valide et aligné. Sans mécanisme d'authentification aligné, il échoue ; le traitement dépend du destinataire et l'éventuel rebond dépend du flux.

Les mesures sont côté serveur : SRS réécrit l'expéditeur d'enveloppe avec un domaine contrôlé et peut permettre la réussite SPF ; ARC fournit un contexte authentifié auquel le destinataire peut décider de se fier. Aucun ne garantit seul l'alignement DMARC ou la remise. Vous pouvez les gérer dans Postfix ou confirmer leur disponibilité chez un fournisseur.

Pour déléguer les clés SRS, ARC et la gestion de réputation, confirmez ce que propose TrekMail pour votre cas. Le tarif de référence de Starter est $3.50/mois pour jusqu'à 50 domaines, forfait sans frais par utilisateur ; vérifiez les prix, fonctions et conditions actuels. Voir toutes les formules.