SRS : réécriture de l’expéditeur et limites du transfert

Vous configurez un transfert et le test fonctionne. Deux semaines plus tard, un e-mail contenant le contrat d’un client manque à l’appel : il n’est pas dans les spams et vous ne voyez aucun avis de non-remise. Dans les journaux, vous trouvez : 550 5.7.1 Unauthenticated email from domain.com.

Un mécanisme de réécriture de l’expéditeur (SRS) absent ou mal configuré est une cause possible, mais ce code ne désigne pas un problème unique. L’authentification vérifie si le serveur est autorisé à envoyer pour le domaine de l’enveloppe. Le transfert peut modifier cette relation. SRS adapte l’expéditeur d’enveloppe, mais en 2026 il ne suffit pas à lui seul : ses limites comptent autant que son fonctionnement.

Ce guide explique ce que fait SRS, ses modes de défaillance et les composants nécessaires à une configuration de transfert. Si vous recherchez aussi des problèmes plus larges, comme des MX incorrects, un catch-all mal configuré ou des changements DNS qui perturbent les routes, commencez par le guide de configuration et de dépannage du transfert d’e-mails.

Pourquoi SPF peut échouer lors d’un transfert

Si le serveur transfère depuis son IP tout en conservant le domaine original dans l’expéditeur d’enveloppe, SPF peut échouer lorsque ce domaine n’autorise pas cette IP. Avec DMARC p=reject, le destinataire peut refuser le message si aucun DKIM valide et aligné ne subsiste. Ce n’est pas toujours une disparition silencieuse : le serveur qui présente le message peut recevoir une erreur SMTP et produire un avis de non-remise.

La messagerie n’est pas un tuyau continu : elle enchaîne des connexions SMTP, avec un nouvel établissement de connexion TCP à chaque saut. Voici un exemple de défaillance possible :

1. alice@client.com écrit à contact@your-agency.com
2. Votre serveur accepte le message : l’IP qui le présente est autorisée par le SPF de client.com
3. Votre serveur ouvre une nouvelle connexion SMTP vers Gmail pour le transférer
4. Gmail voit une connexion provenant de votre IP
5. L’expéditeur d’enveloppe reste alice@client.com
6. Gmail vérifie le SPF de client.com : votre IP n’est pas autorisée dans cet exemple
7. SPF échoue. Si client.com publie p=reject et qu’aucun DKIM valide et aligné ne subsiste, Gmail peut refuser le message

La RFC 7208, spécification de SPF, reconnaît les difficultés que le transfert peut poser à cette vérification. Réécrire l’enveloppe permet d’évaluer le domaine du serveur de transfert sans demander à chaque expéditeur original d’autoriser son IP.

Deux identités : l’enveloppe et l’en-tête

Un e-mail comporte deux identités d’expéditeur. L’expéditeur d’enveloppe (RFC 5321, MAIL FROM, P1) sert à SPF et au routage des avis de non-remise ; il peut aussi être consulté dans Return-Path parmi les en-têtes bruts. Le From de l’en-tête (RFC 5322, P2) est celui qu’affiche le client, comme Gmail ou Outlook. SRS adapte l’identité de l’enveloppe au nouvel envoi, sans nécessairement aligner son domaine sur le From visible.

Lors du transfert, le From de l’en-tête reste alice@client.com. Votre serveur crée une nouvelle transaction SMTP et SPF évalue l’expéditeur d’enveloppe à ce saut. Le problème apparaît si la nouvelle IP n’est pas autorisée ; lorsque SRS change le domaine de l’enveloppe, son alignement avec le From doit être évalué séparément.

Ce que fait réellement SRS

SRS réécrit l’adresse de l’expéditeur d’enveloppe (P1) avant la nouvelle connexion SMTP. Le From visible reste inchangé. Employer un domaine qui autorise le serveur de transfert peut permettre à SPF de réussir, sans garantir son résultat ni la livraison. Cela n’établit pas non plus à lui seul l’alignement DMARC avec l’expéditeur original.

L’analogie postale : vous recevez une lettre d’Alice et la renvoyez dans un nouveau sac en gardant son adresse de retour. Le destinataire voit que vous livrez un courrier portant l’adresse d’Alice, ce qui peut poser une question d’autorisation. Avec SRS, vous remplacez l’adresse de retour par la vôtre. Elle correspond alors au nouvel envoi. Si le sac revient, il arrive chez vous, et vous pouvez acheminer le retour vers Alice.

Comprendre le format d’une adresse SRS

SRS transforme l’expéditeur d’enveloppe en une adresse encodée avant le transfert. Le destinataire évalue le domaine du serveur de transfert. L’adresse contient un code d’authentification pour valider les retours, un horodatage pour limiter sa validité et l’adresse originale pour réacheminer les avis de non-remise. Ce sont des données structurées, pas des caractères aléatoires.

Exemple d’adresse réécrite avec SRS :

SRS0=4fac=PM=client.com=alice@your-agency.com

• SRS0 : premier saut. SRS1 peut apparaître lors d’un nouveau transfert et aide à limiter la croissance de l’adresse, sans garantir une chaîne illimitée
• 4fac : exemple de code HMAC-SHA1 dans une implémentation. Il sert à valider les retours entrants ; rejeter les codes invalides aide à réduire les abus par avis de non-remise indésirables. L’algorithme et la longueur dépendent de l’implémentation
• PM : horodatage. Une fenêtre de 7 à 21 jours est un exemple de validité, pas une durée universelle ; refuser les adresses expirées réduit certains risques de rejeu sans les supprimer complètement
• client.com=alice : expéditeur original encodé, utilisé pour acheminer les avis de non-remise vers la bonne adresse

Quand SRS est nécessaire

SRS est pertinent pour les transferts entre domaines lorsque l’IP du serveur de transfert n’est pas autorisée par le SPF de l’expéditeur original. Sans lui, SPF peut échouer, même si un DKIM aligné permet encore à DMARC de réussir. Une infrastructure multidomaine doit vérifier ces conditions et surveiller les messages transférés.

Domaine personnel vers Gmail. Vous possédez cool-startup.com et transférez tout vers founder@gmail.com. SRS peut être important pour SPF sur ce trajet. Sans lui, SPF peut échouer si l’expéditeur original n’autorise pas le serveur de transfert ; une politique DMARC stricte ne provoque pas automatiquement un rejet si un DKIM valide et aligné subsiste.

MSP ou agence avec une plateforme partagée. Vous hébergez 200 domaines clients qui configurent des transferts vers leurs fournisseurs, comme Comcast, AT&T ou Outlook. Relayer du spam peut nuire à la réputation de votre IP et contribuer à une inscription sur une liste telle que Spamhaus. Ce n’est ni inévitable ni nécessairement une question de semaines ; SRS ne remplace pas le filtrage et ne garantit pas une bonne réputation.

Microsoft 365 avec un connecteur sortant. Dans M365, le comportement de SRS peut varier selon le parcours et la configuration. Si vous utilisez un connecteur, vérifiez dans la documentation de sa version et de son type s’il prend en charge SenderRewritingEnabled et comment ce paramètre s’applique. Examinez aussi la politique antispam sortante et le blocage du transfert externe 5.7.520, qui relève d’une politique et ne prouve pas un échec SRS. Toute modification doit être autorisée par l’organisation.

Pourquoi SRS ne suffit pas

SRS peut permettre à SPF de réussir pour le domaine du serveur de transfert, mais cela n’équivaut pas à un alignement DMARC. DMARC exige qu’au moins un domaine authentifié par SPF ou DKIM soit aligné avec le From visible. Si SRS utilise un autre domaine, SPF n’est pas aligné ; DMARC peut alors dépendre de la préservation d’un DKIM valide et aligné.

Ces modifications peuvent invalider DKIM si elles touchent les parties signées et changent le résultat selon la canonicalisation de la signature :

• Ajouter [EXTERNAL] à l’objet peut invalider DKIM si cet en-tête est signé
• Ajouter un pied de message, comme un avis antivirus ou un lien de désabonnement, peut modifier le contenu couvert par l’empreinte du corps
• Réécrire MIME, par exemple convertir un encodage de 8 bits en 7 bits, peut modifier le contenu signé

Si SPF n’est pas aligné et que les modifications invalident le DKIM aligné, DMARC échoue. Le destinataire applique sa politique, qui peut inclure le rejet, avec ou sans notification ultérieure à l’expéditeur.

ARC (Authenticated Received Chain, RFC 8617) peut apporter un contexte d’authentification au destinataire sans réparer l’alignement. Le serveur de transfert scelle les résultats observés avant de poursuivre le parcours. Trois en-têtes sont ajoutés :

• ARC-Authentication-Results : consigne les résultats SPF, DKIM et DMARC réellement observés, sans présumer leur réussite
• ARC-Message-Signature : signe certaines parties du message au moment du scellement, pas nécessairement dans leur état à la réception
• ARC-Seal : signature cryptographique reliant cette instance à la chaîne ARC

Un destinataire comme Gmail peut examiner ARC lorsque l’authentification du message transféré échoue. S’il fait confiance au signataire et à la chaîne, il peut déroger à son traitement habituel de DMARC. Cette décision lui appartient : la réputation peut compter, mais ne garantit ni confiance ni acceptation.

Comment vérifier le fonctionnement de SRS

Envoyez un message depuis un compte externe vers l’adresse transférée, puis inspectez les en-têtes complets à destination. Return-Path indique si une réécriture SRS est visible ou si l’adresse originale subsiste. Vérifiez aussi les résultats d’authentification : l’adresse de retour ne permet pas, à elle seule, de savoir si SPF a réussi.

Étape 1 : vérifier Return-Path à destination

# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>

# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>

Étape 2 : vérifier le DNS du domaine SRS

# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf

# Check MX - bounces need a place to go:
dig MX your-domain.com

Le domaine SRS doit disposer d’une route de retour opérationnelle et d’un SPF autorisant le serveur. Un MX explicite est habituel, mais son absence ne signifie pas toujours que le domaine est inaccessible : SMTP peut utiliser A ou AAAA via le mécanisme de MX implicite. Vérifiez la réception réelle des avis de non-remise, pas uniquement l’existence de l’enregistrement.

Étape 3 : consulter le journal de messagerie sous Linux

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

Les messages hash mismatch ou timestamp expired peuvent résulter de secrets désynchronisés ou renouvelés, d’adresses altérées ou de retours tardifs ; ils ne prouvent pas une tentative de rejeu malveillant. Postfix nécessite généralement une intégration SRS externe ; PostSRSd est une option parmi d’autres. Vérifiez la configuration compatible avec votre version, notamment SRS_EXCLUDE_DOMAINS lorsqu’il s’applique, et les routes locales pour éviter des réécritures inutiles ou des boucles possibles.

L’alternative plus simple : arrêter le transfert

SRS adapte l’enveloppe à une nouvelle livraison SMTP. Utiliser une vraie boîte sur votre domaine et y accéder en IMAP évite ce saut de transfert et réduit les problèmes associés. Cela ne garantit pas une authentification de bout en bout et ne supprime pas tous les risques : la réception et les contrôles d’accès restent essentiels.

La popularité du transfert s’explique aussi par les coûts : personne ne veut payer par utilisateur pour une boîte qui reçoit cinq messages par mois. SRS peut répondre en partie à une architecture choisie pour son prix, pas seulement pour des besoins techniques.

Le modèle TrekMail décrit ici propose des formules à partir de $3.50 par mois, plusieurs domaines et un stockage mutualisé à tarif fixe, sans facturation par utilisateur dans les limites de la formule. Vous pouvez utiliser sales@yourdomain.com comme vraie boîte IMAP dans un client compatible, tel qu’Outlook ou une intégration prise en charge de l’application Gmail, et supprimer cette route de transfert. Vérifiez les fonctions et conditions actuelles ; éviter ce saut ne garantit pas l’absence d’échecs d’authentification.

Pour plusieurs clients, le guide de l’hébergement de messagerie multidomaine explique comment organiser des dizaines de domaines et réduire les tâches d’administration. Si vous conservez une configuration hybride avec des boîtes et d’anciens transferts, le guide des alias et du transfert d’e-mails aborde la configuration avec SRS sur le parcours.

Que vous conserviez le transfert ou passiez à des boîtes, comprenez le rôle de SRS, vérifiez son fonctionnement et évaluez ARC selon le destinataire. Une configuration incomplète peut empêcher l’arrivée de messages légitimes : c’est un problème opérationnel pour votre entreprise, pas une simple curiosité technique.

Commencez avec un compte TrekMail gratuit, sans carte ni expiration de la période d’essai dans les conditions décrites, et vérifiez les fonctions et limites actuelles pour gérer plusieurs domaines sans cette complexité de transfert.