Transfert d’e-mails avec SRS : fonctionnement et limites

Vous configurez un transfert : contact@yourdomain.com dirige les messages vers Gmail. Tout fonctionne pendant une semaine, puis des e-mails de clients manquent. Vous n'avez peut-être reçu aucun avis, bien qu'un refus SMTP puisse aussi produire une notification de non-remise. Les journaux indiquent 550 5.7.1 Unauthenticated email ou 550 5.7.26 This message does not have authentication information. Ces erreurs ne désignent pas une cause unique, mais le transfert d'e-mails avec SRS traite un problème courant : le serveur ouvre une nouvelle connexion SMTP tout en conservant le domaine d'origine dans l'enveloppe. Si ce domaine n'autorise pas la nouvelle IP, SPF peut échouer. Avec p=reject dans DMARC, le destinataire peut refuser le message si aucune signature DKIM valide et alignée ne subsiste, selon sa politique.

Activer SRS ne résout pas tous les problèmes. Même avec une configuration correcte, l'alignement DMARC et les signatures DKIM peuvent encore poser difficulté. Pour comprendre les autres causes et les diagnostiquer, consultez notre guide de configuration et de dépannage des transferts.

Qu'est-ce que le transfert d'e-mails avec SRS ?

Le transfert d'e-mails avec SRS, Sender Rewriting Scheme, réécrit l'adresse d'expéditeur de l'enveloppe lorsqu'un serveur remet un message à une nouvelle destination. Il remplace le domaine d'origine par celui du serveur de transfert dans l'adresse technique de retour. SPF peut alors réussir si le DNS de ce domaine autorise l'IP de transfert. Le champ From visible conserve l'expéditeur d'origine. SRS modifie MAIL FROM ; il ne chiffre pas le message et ne masque pas les identités. Les utilisateurs peuvent consulter les en-têtes techniques.

Des intégrations existent pour Postfix via le service postsrsd, certains environnements Microsoft 365 et des plateformes d'hébergement gérées. Vérifiez la version, la prise en charge et la configuration actuelles. SRS adapte le transfert SMTP à la vérification SPF, sans garantir la remise ni la réussite de DMARC.

Pourquoi le transfert peut échouer : le nouveau saut SMTP

Un transfert crée un nouveau saut SMTP dont l'IP peut ne pas être autorisée par le domaine d'origine. Le message comporte deux identités. Header From (RFC 5322) est celle généralement affichée par le client : From: alice@client.com. Envelope Sender (RFC 5321, MAIL FROM) est l'adresse de retour utilisée pour SPF et les notifications de non-remise. Elle n'apparaît généralement pas dans l'interface, mais reste consultable dans des en-têtes comme Return-Path.

Cette séquence illustre un échec possible, pas une conséquence systématique :

1. Alice envoie depuis alice@client.com. Son enregistrement SPF autorise son serveur ; SPF réussit à l'arrivée sur votre serveur.
2. Votre serveur ouvre une nouvelle connexion SMTP vers you@gmail.com. À ce saut, l'IP émettrice est la vôtre.
3. Envelope Sender reste alice@client.com, mais l'enregistrement SPF de client.com n'autorise pas l'IP de votre serveur dans cet exemple.
4. Gmail vérifie SPF pour client.com. L'IP n'étant pas autorisée, SPF échoue.
5. Si client.com publie p=reject et qu'aucune signature DKIM valide et alignée ne subsiste, DMARC échoue. Gmail peut refuser le message selon sa politique ; le serveur de transfert peut recevoir ce refus et produire une notification.

Comment SRS aide SPF à réussir

Le transfert d'e-mails avec SRS réécrit Envelope Sender avant la nouvelle remise avec le domaine du serveur de transfert. Le destinataire vérifie désormais SPF pour ce domaine, qui doit disposer d'un enregistrement valide autorisant l'IP de sortie réelle. Header From reste inchangé et le destinataire voit toujours l'expéditeur d'origine. Les notifications de non-remise passent par le domaine du serveur de transfert, qui peut retrouver l'adresse initiale selon son implémentation et ses contrôles.

Comprendre la syntaxe SRS

Avec SRS, l'adresse de retour peut prendre cette forme, avec un code d'authentification plutôt qu'une adresse chiffrée :

Avant SRS : MAIL FROM: <alice@client.com>
Après SRS : MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

Si le message est transféré une nouvelle fois (A → B → C), une implémentation SRS peut utiliser la syntaxe SRS1 pour limiter l'allongement de l'adresse SRS0. L'encapsulation ne se réduit pas nécessairement au code et à l'horodatage. Vérifiez que la partie locale reste dans la limite de 64 caractères de RFC 5321 : la réécriture ne le garantit pas pour toute adresse.

Pourquoi SRS ne suffit pas : l'alignement DMARC

Beaucoup d'administrateurs activent le transfert d'e-mails avec SRS et pensent avoir terminé, alors que les messages peuvent encore arriver dans les indésirables. SRS peut permettre à SPF de réussir sans préserver l'alignement DMARC initial. DMARC exige un résultat valide et aligné de SPF ou DKIM par rapport au domaine de Header From. Après réécriture, SPF authentifie yourdomain.com, tandis que Header From reste client.com. Ils ne sont pas alignés dans cet exemple ; d'autres cas peuvent l'être selon la relation entre domaines et le mode d'alignement.

Lorsque SPF n'est pas aligné, DMARC dépend d'une signature DKIM valide et alignée. Certaines modifications du serveur de transfert peuvent l'invalider si elles touchent des parties signées et ne sont pas neutralisées par la canonicalisation :

• Ajouter [EXTERNAL] au début de l'objet
• Insérer un pied de message antivirus ou une mention juridique
• Convertir l'encodage de 8 bits en 7 bits
• Réécrire les délimiteurs MIME

Ces modifications n'invalident pas nécessairement toute signature, mais doivent être testées. Sans SPF valide et aligné ni DKIM valide et aligné, DMARC échoue. Le destinataire peut refuser ou filtrer le message selon sa politique, même si SRS a fonctionné correctement.

Le rôle d'ARC (Authenticated Received Chain)

ARC (RFC 8617) permet au serveur de transfert de consigner les résultats d'authentification réellement observés et de sceller le message. Il ajoute trois en-têtes :

• ARC-Authentication-Results: Consigne les résultats SPF/DKIM/DMARC observés par l'intermédiaire
• ARC-Message-Signature: Signe les en-têtes et le corps au moment du scellement
• ARC-Seal: Signature reliant l'ensemble ARC à la chaîne précédente

Si le destinataire valide la chaîne et fait confiance au serveur qui la scelle, il peut en tenir compte pour accepter un message malgré un échec DMARC ultérieur. Cela ne transforme pas l'échec en réussite DMARC et ne garantit pas la remise. Gmail évalue ARC en production depuis 2019.

Pour préparer les transferts en 2026, envisagez le transfert d'e-mails avec SRS pour SPF, la conservation des parties signées par DKIM et ARC lorsque sa prise en charge est pertinente. Ces trois éléments ne sont ni des exigences universelles ni une combinaison suffisante pour garantir la remise.

Configurer SRS selon la plateforme

La configuration varie : Postfix peut utiliser un service externe, Microsoft 365 combine fonctions et politiques de l'environnement, et Google Workspace applique ses propres contrôles. Vérifiez ce qui est disponible et activé aujourd'hui, sans supposer des paramètres par défaut identiques partout.

Postfix (Linux autohébergé)

Le service postsrsd est une option d'intégration SRS pour Postfix. La commande suivante est un exemple à vérifier pour votre distribution et votre version :

apt-get install postsrsd

Cet exemple ancien utilise des tables TCP dans /etc/postfix/main.cf. Avant une modification autorisée, sauvegardez la configuration, conservez et intégrez les tables existantes, puis vérifiez les sockets, chemins et formats pris en charge par votre version de postsrsd :

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Important : Vérifiez comment votre version gère les exclusions ; cet exemple utilise SRS_EXCLUDE_DOMAINS dans /etc/default/postsrsd pour les domaines locaux. Des exclusions inadaptées peuvent réécrire votre propre courrier ou contribuer à des boucles en combinaison avec le routage. L'omission d'une option ne provoque pas systématiquement une boucle : testez les chemins entrants, sortants et de retour avant tout changement.

Microsoft 365

Microsoft 365 prend en charge SRS pour certains flux ; vérifiez le comportement actuel des pools sortants, environnements hybrides et connecteurs. Une erreur comme 550 5.7.520 Access denied, Your organization does not allow external forwarding signale une restriction de transfert sortant dans l'environnement émetteur, pas à elle seule un échec SRS.

Examinez la politique antispam sortante dans l'interface administrative actuelle. N'autorisez que les transferts légitimes pour des utilisateurs et destinataires approuvés après examen de sécurité, sans désactiver largement les protections. La commande suivante n'est pas universelle : son paramètre peut ne pas être disponible. Vérifiez le cmdlet, sa version et la documentation applicable avant toute modification :

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google applique ses propres mécanismes et contrôles. Examinez notamment ces risques, qui ne sont pas exclusifs à Workspace :

• Limites de volume : Un catch-all transférant vers Gmail peut dépasser les quotas applicables. Un afflux de spam peut déclencher des restrictions ; vérifiez les limites actuelles et l'état du compte sans présumer une suspension automatique.
• Boucles et messages manquants : Les règles et la détection des boucles peuvent empêcher certains transferts. Consultez les journaux disponibles, les réponses SMTP et les outils de suivi ; ne supposez pas que le message est toujours supprimé sans trace.

Diagnostiquer les échecs de transfert avec SRS

Les en-têtes complets apportent des indices, mais ne sont pas toujours disponibles et ne suffisent pas nécessairement à identifier la cause. Envoyez un test depuis ProtonMail vers votre serveur de transfert et examinez ce qui arrive à la destination finale. Complétez l'analyse avec les journaux SMTP, la configuration et le suivi des messages lorsqu'ils sont disponibles.

Vérification 1 : Return-Path

Sans réécriture SRS visible : Return-Path: <original@protonmail.com>
Avec réécriture SRS visible : Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Si Return-Path conserve le domaine d'origine, vérifiez si cette route nécessite SRS, fait partie des exclusions ou contourne les tables configurées. Un service arrêté ou une intégration incorrecte sont aussi possibles, mais cet en-tête ne les prouve pas à lui seul.

Vérification 2 : Authentication-Results

Recherchez spf=pass associé au domaine réécrit dans des en-têtes d'authentification fiables du destinataire. Un dmarc=fail malgré SPF valide peut venir de l'absence d'alignement SPF et d'un DKIM absent, invalide ou non aligné. Examinez les signatures et les modifications de l'objet ou du corps, pas seulement la présence d'une signature.

Vérification 3 : DNS

dig yourdomain.com TXT +short

Vérifiez que le domaine SRS dispose d'un SPF valide pour l'IP sortante et d'une adresse de retour joignable. Un MX ne suffit pas à le démontrer, et son absence n'empêche pas toujours la réception : une route MX implicite via A/AAAA peut exister. Testez l'adresse de retour et consultez les erreurs réelles du destinataire.

Vérification 4 : journaux Postfix

grep "srs_forward" /var/log/mail.log

Les erreurs hash mismatch ou timestamp expired peuvent révéler des secrets différents entre nœuds, une rotation de clés, un décalage horaire, une configuration incorrecte ou des adresses anciennes. Elles peuvent aussi apparaître lors d'une tentative de rejeu ; elles ne prouvent pas une attaque à elles seules.

Quand choisir une boîte hébergée plutôt qu'un transfert SRS

Le transfert d'e-mails avec SRS répond à un décalage d'identité créé par un intermédiaire. SRS, la préservation de DKIM et, lorsque nécessaire, ARC ajoutent des dépendances opérationnelles. Le transfert peut sembler moins cher avec des licences par utilisateur, mais incluez le temps de maintenance et de diagnostic dans la comparaison.

Comparez les deux approches :

TrekMail décrit des forfaits à tarif fixe avec un stockage partagé entre boîtes et domaines, pas une capacité illimitée ni une facturation fondée uniquement sur le stockage. Vérifiez les limites et conditions actuelles. Pour les agences, comparez ce modèle à une configuration classique de transfert vers Gmail ou consultez le guide des avantages et limites du transfert par alias. Pour choisir entre alias et boîtes réelles, lisez le comparatif entre alias de domaine et boîte mail.

Héberger directement la boîte sur TrekMail supprime ce saut de transfert et peut éviter le besoin de SRS ou d'ARC pour cette route. L'assistant peut aider à préparer SPF, DKIM et DMARC, mais vous devez autoriser et tester chaque route sortante, y compris un fournisseur SMTP externe compatible avec le forfait et ses identifiants. Être le serveur MX du domaine n'autorise pas automatiquement l'envoi SMTP et ne garantit pas l'authentification.

Essayez TrekMail : l'offre décrite comprend Nano sans carte et un essai de 14 jours sur Starter à partir de $3.50/mo avec SMTP géré. Vérifiez la disponibilité, les conditions d'accès, les fonctions et les prix actuels.

Résumé

Le transfert d'e-mails avec SRS est un outil utile dans les architectures de transfert de 2025-2026, pas une obligation universelle pour tout serveur de transfert. Sans SRS, SPF peut échouer si le domaine initial n'autorise pas la nouvelle IP. Avec SRS, la vérification SPF peut réussir si l'autorisation est correcte, mais l'alignement avec le From initial peut manquer. DMARC exige SPF ou DKIM valide et aligné.

Sur Postfix, vérifiez la version de postsrsd, les tables de main.cf et les exclusions. Dans Microsoft 365, examinez les politiques autorisées et les fonctions réellement disponibles sans appliquer une commande incompatible. Dans Workspace, consultez quotas, règles, journaux et état des comptes.

Combinez SRS lorsque nécessaire, préservation des signatures DKIM et ARC lorsque le destinataire le prend en charge et fait confiance à la chaîne. Cela ne garantit pas la remise. Vous pouvez aussi héberger la boîte à sa destination réelle, tout en conservant la configuration et les tests d'authentification nécessaires.