Transfert des e-mails de domaine : SRS et ARC

Le transfert des e-mails de domaine ouvre une nouvelle connexion SMTP vers le destinataire. Si le serveur conserve l'expéditeur d'enveloppe original, son adresse IP peut ne pas être autorisée par ce domaine. Ce décalage peut nuire à la délivrabilité ; la visibilité des notifications d'échec dépend du routage et des journaux disponibles.

Sans une authentification adaptée, les messages transférés peuvent être filtrés chez Gmail, rejetés avec un code 550 chez Yahoo ou bloqués par une politique chez Microsoft 365. Ces services ne réagissent pas tous de la même manière et un échec n'est pas toujours visible dans la boîte de destination.

Ce guide présente trois modèles utiles en 2026, des exemples d'erreurs chez les principaux fournisseurs et une liste de contrôles réalisables en moins de dix minutes. Pour la configuration complète, consultez notre guide de configuration et de dépannage du transfert d'e-mails.

Pourquoi le transfert des e-mails de domaine peut faire échouer SPF

SPF peut échouer lorsque votre serveur effectue la nouvelle livraison SMTP mais que le Return-Path conserve le domaine original. Le destinataire consulte le SPF de ce domaine pour vérifier l'adresse IP de connexion. Si elle n'est pas autorisée, le contrôle peut échouer. Une politique DMARC p=reject ne signifie pas à elle seule que le message sera supprimé : une signature DKIM originale valide et alignée peut encore permettre à DMARC de réussir.

Voici un exemple de séquence d'échec :

alice@bank.com écrit à info@yourdomain.com. Le SPF de la banque autorise ses propres serveurs.
Votre serveur livre à nouveau le message à you@gmail.com. Gmail voit son adresse IP, mais le Return-Path indique toujours bank.com.
Si cette adresse IP n'est pas autorisée par le SPF de bank.com, SPF peut échouer.
Si le serveur modifie le corps ou un en-tête signé, DKIM peut aussi échouer selon la signature et sa canonicalisation. Sans autre résultat valide et aligné, DMARC échoue et le destinataire peut appliquer sa politique de rejet.

Une notification d'échec peut revenir à l'expéditeur d'enveloppe ou apparaître dans les journaux des files. Vérifiez ces traces avant de conclure à une disparition sans notification.

Le transfert d'un catch-all peut amplifier le risque. Vous réexpédiez aussi le spam reçu depuis l'adresse IP du serveur de transfert. Ce trafic peut dégrader sa réputation et entraîner le filtrage ou le rejet de messages légitimes, sans que cette évolution soit systématique ni propre à Gmail.

Si vous hésitez encore sur cette architecture, consultez les avantages et les limites du transfert par alias avant de choisir votre configuration.

Les 3 modèles de transfert favorisant la délivrabilité

Ces trois modèles répondent à des risques distincts. Ils peuvent être combinés selon votre infrastructure et la politique du destinataire, mais ne sont ni obligatoires partout ni une garantie de livraison. La conservation d'une signature DKIM originale valide et alignée est particulièrement importante.

1. Sender Rewriting Scheme (SRS)

SRS réécrit l'expéditeur d'enveloppe avec le domaine du serveur de transfert. Le destinataire peut alors vérifier SPF pour ce domaine, qui doit autoriser l'adresse IP de sortie. L'adresse encodée permet de renvoyer les notifications d'échec à l'expéditeur original si l'implémentation et le routage sont corrects.

Avant SRS :

MAIL FROM: <alice@bank.com>

Après SRS :

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

La limite : SRS peut résoudre le contrôle SPF de l'enveloppe, mais n'apporte généralement pas l'alignement SPF avec le From original requis par DMARC. Une signature DKIM valide et alignée peut toujours permettre à DMARC de réussir. Si elle devient invalide, SRS seul ne restaure pas cet alignement.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) protège l'historique des résultats d'authentification lors du passage par des intermédiaires. Le serveur ajoute des en-têtes signés qui consignent ses contrôles ; ils ne prouvent pas à eux seuls que l'expéditeur est légitime.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google et Microsoft peuvent tenir compte d'une chaîne ARC valide provenant d'un intermédiaire de confiance. Elle peut aider lorsque l'authentification finale échoue, mais l'acceptation reste soumise à la politique du destinataire.

La confiance est essentielle : une signature ARC valide ou un nouveau domaine ne bénéficie pas automatiquement de la confiance du destinataire. La réputation et la relation avec l'intermédiaire peuvent intervenir.

3. Relais passif : préservation de DKIM

Préserver le message original est important, avec ou sans SRS et ARC. Évitez d'ajouter un pied de page ou de réécrire des en-têtes signés. DKIM signe le corps et certains en-têtes selon des règles de canonicalisation : une modification pertinente peut invalider la signature, mais tout changement d'un octet ne détruit pas nécessairement toutes les signatures.

Les pannes difficiles à diagnostiquer peuvent venir d'une modification discrète. Un filtre ajoute « Ce message a été analysé par MailGuard » au corps et peut invalider sa signature. Les journaux d'envoi ne le signalent pas forcément ; un dkim=fail (body hash did not verify) dans Authentication-Results à destination fournit un indice, si vous avez accès au message.

Ce modèle dépend de la survie d'une signature DKIM valide et alignée sur tout le parcours. Si SPF n'est pas aligné et que DKIM devient invalide, DMARC peut échouer. Le destinataire décide toujours du traitement et de la prise en compte éventuelle d'ARC.

Comment les principaux fournisseurs traitent les échecs de transfert

Microsoft, Google et Yahoo peuvent bloquer un transfert par politique, rejeter un message pendant SMTP avec un code 550 ou le filtrer ensuite. Réputation et authentification jouent un rôle. Les codes ci-dessous sont des exemples : consultez le diagnostic complet, l'étape de livraison et les journaux sans supposer une réponse universelle.

Microsoft 365 (Exchange Online)

Une politique antispam sortante de Defender peut bloquer le transfert externe automatique. Si le blocage intervient dans le tenant d'origine, le message peut ne jamais atteindre votre serveur de transfert. Vérifiez la politique effective avant de modifier l'authentification.

Code d'erreur	Cause	Correction
`550 5.7.520`	Peut signaler un transfert automatique bloqué par la politique sortante ; vérifiez le diagnostic complet	Si vous y êtes autorisé, permettez seulement les utilisateurs et destinations nécessaires dans Microsoft Defender → Antispam → Politiques sortantes
`5.4.14`	Peut indiquer un nombre de sauts dépassé, notamment à cause d'une boucle	Tracez toute la chaîne et cherchez les boucles comme A→B→A

Une notification 5.7.520 peut être adressée à l'expéditeur d'enveloppe plutôt qu'à la boîte de destination. Consultez le suivi du message et les journaux utiles ; ne supposez pas que le retour sera toujours invisible.

Google Workspace / Gmail

Un exemple de rejet explicite est 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Il peut apparaître si DMARC échoue pour un domaine publiant p=reject. L'absence de SRS ou d'ARC ne suffit pas à le prédire : DKIM original valide et aligné peut faire réussir DMARC, tandis que SRS seul n'apporte pas cet alignement.

Transférer du spam depuis un catch-all peut nuire à la réputation de l'adresse IP. Cela peut entraîner un filtrage ou un rejet, avec des indices différents dans les réponses SMTP et les journaux. Ce n'est pas nécessairement une perte silencieuse et progressive de tous les messages.

Yahoo / AOL

Yahoo peut rejeter avec un code 550 des messages transférés qui ne respectent pas ses politiques d'authentification. Ajouter [FWD] ou [External] à un objet signé peut invalider DKIM ; sans SPF aligné, DMARC peut alors échouer. Cela ne signifie pas que 100% de ces messages sont rejetés ni que toute installation sans SRS/ARC perd son courrier : la signature conservée, la politique et le diagnostic complet comptent.

Liste de diagnostic du transfert

En cas de panne du transfert des e-mails de domaine, suivez cette séquence avant de changer la configuration :

Lisez Authentication-Results à destination (« Afficher l'original » dans Gmail ; source du message dans Outlook), si le message est accessible.
```
Authentication-Results: mx.google.com;
  spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
  dkim=fail (body hash did not verify)
  dmarc=fail (p=REJECT)
```
spf=fail → vérifiez le domaine d'enveloppe, l'adresse IP et SRS ; ce résultat seul n'identifie pas la cause.
dkim=fail (body hash) → recherchez des modifications du corps et des problèmes de signature.
Les deux échecs peuvent faire échouer DMARC sans autre résultat valide et aligné ; le rejet dépend du destinataire.
Cherchez les boucles de routage. 5.4.14 Hop count exceeded oriente vers un nombre de sauts excessif. Tracez tout le parcours et cherchez des cycles comme A→B→C→A.
Testez Reply-To. Une réponse est généralement envoyée à Reply-To s'il existe, sinon à From. Vérifiez la destination attendue et les deux en-têtes avant d'attribuer une réponse au serveur de transfert à une réécriture de From.
Auditez tous les composants qui touchent le message. Filtres antispam, antivirus, listes de diffusion et outils antiphishing peuvent modifier du contenu signé. Vérifiez leurs transformations et les journaux de chaque saut.
Vérifiez le volume du catch-all. Un volume élevé de spam transféré peut dégrader la réputation et la livraison, même si certains messages réussissent les contrôles d'authentification.

Si vous hésitez entre transfert et routage par adresse, comparez les alias de domaine et les boîtes aux lettres. Ils répondent à des besoins différents et modifient les risques à gérer.

L'infrastructure de transfert de TrekMail

Avec Postfix autohébergé, une architecture peut comprendre postsrsd pour SRS, OpenARC pour ARC, la rotation des clés RSA et la conservation du contenu signé. Ces composants sont indépendants et doivent être testés séparément ; ils ne sont pas tous nécessaires dans chaque architecture.

Une signature DKIM supplémentaire du serveur de transfert peut faire partie de sa conception, mais ce n'est pas une exigence universelle d'ARC. Elle ne remplace pas la signature originale alignée et ne restaure pas l'alignement avec le From original si elle utilise un autre domaine. Vérifiez la conservation de DKIM, la chaîne ARC et la politique du destinataire plutôt que d'attribuer tout échec à l'absence d'une nouvelle signature.

La conception décrite pour TrekMail combine OpenARC, une signature DKIM supplémentaire et SRS, avec un parcours préservant le contenu. Vérifiez l'implémentation actuelle et les en-têtes des messages de test. Choisissez la destination dans les paramètres de transfert de la boîte ; la livraison dépend aussi du destinataire.

	Postfix autohébergé	TrekMail
Réécriture SRS	Configuration manuelle de postsrsd et vérification du routage	Automatique sur les routes compatibles, selon l'implémentation actuelle
Signature ARC et signature DKIM supplémentaire	OpenARC et, si la conception le prévoit, une étape DKIM distincte	Gérées par l'infrastructure décrite ; vérifiez le fonctionnement actuel
Risque de modification du message	Contrôler les changements introduits par chaque composant	Contenu préservé dans le parcours décrit
Contrôle du volume catch-all	Filtrage configuré par l'opérateur	Vérifiez les contrôles par domaine disponibles dans le tableau de bord

L'offre décrite inclut le transfert dans Pro ($10/mois) et Agency ($23.25/mois), avec un essai gratuit de 14 jours nécessitant une carte bancaire. Nano ($0, 10 domaines, SMTP fourni par vos soins) et Starter ($3.50/mois, 50 domaines) sont présentés sans transfert. Confirmez les tarifs, limites et fonctionnalités actuels dans le comparatif complet sur trekmail.net/pricing.

Conclusion

La délivrabilité du transfert des e-mails de domaine en 2026 dépend de l'authentification et du parcours. SRS peut résoudre SPF pour l'enveloppe sans aligner le From original ; ARC fournit un historique protégé que le destinataire peut prendre en compte ; préserver DKIM original valide et aligné aide DMARC à réussir. Combinez les mesures adaptées sans les considérer comme une garantie de livraison.

Commencez par Authentication-Results pour diagnostiquer. Interprétez ses résultats avec les en-têtes et les journaux de chaque saut : un seul en-tête ne reconstitue pas toujours tout le parcours.

Si vous préférez ne pas gérer Postfix, configurer une messagerie professionnelle sur votre domaine avec TrekMail peut prendre environ 15 minutes selon les prérequis. Vérifiez les fonctionnalités de transfert actuelles et testez la livraison vers vos destinations.