SRS est un sujet discret, mais important dès qu’un email est transféré automatiquement.
Il intervient surtout dans les cas de redirection, d’alias externes, de listes de diffusion ou de passerelles qui relaient un message vers une autre messagerie.
Sans SRS, un transfert peut casser SPF, même si l’expéditeur original et le destinataire final sont légitimes. Le message n’est pas forcément frauduleux, mais le chemin technique devient incohérent.
Ce que signifie SRS
SRS signifie Sender Rewriting Scheme.
Son rôle est de réécrire l’adresse d’enveloppe d’un email lorsqu’un serveur le transfère vers une autre destination.
Cette adresse d’enveloppe correspond au MAIL FROM SMTP, souvent visible ensuite dans le Return-Path. Elle sert notamment à gérer les erreurs de livraison, aussi appelées bounces.
SRS ne modifie pas l’adresse visible par l’utilisateur dans le champ “De”. Il agit sur la couche technique du transport.
Autrement dit :
SRS ne change pas l’auteur apparent du message. Il change l’adresse d’enveloppe utilisée pendant le transfert.
Cette différence est essentielle pour comprendre son intérêt.
Pourquoi un transfert casse souvent SPF
SPF vérifie si l’adresse IP du serveur qui envoie le message est autorisée par le domaine d’enveloppe.
Dans un envoi direct, c’est assez simple. Le serveur expéditeur appartient au domaine, ou à une plateforme déclarée dans son SPF.
Mais avec un transfert, le message passe par un serveur intermédiaire.
Exemple :
alice@example.comenvoie un email verscontact@entreprise.fr;entreprise.frtransfère automatiquement ce message versdestinataire@gmail.com;- Gmail reçoit le message depuis le serveur de
entreprise.fr; - l’enveloppe porte encore
alice@example.com.
Gmail vérifie alors le SPF de example.com, mais l’IP observée est celle du serveur de entreprise.fr.
Si cette IP n’est pas dans le SPF de example.com, SPF échoue.
Le serveur de transfert n’a rien fait de mal. Il a simplement renvoyé un message en conservant une enveloppe qui ne lui appartient pas.
Comment SRS corrige le problème
SRS corrige ce décalage en réécrivant l’adresse d’enveloppe au moment du transfert.
Au lieu de relayer le message avec :
MAIL FROM:<alice@example.com>le serveur de transfert utilise une adresse de son propre domaine, par exemple :
MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.tld>
Le domaine visible dans l’enveloppe devient alors forwarder.tld.
Le destinataire final vérifie le SPF de forwarder.tld, pas celui de example.com. Si le serveur de transfert est bien autorisé dans son propre SPF, le contrôle SPF redevient cohérent.
SRS encode aussi l’adresse originale dans la nouvelle adresse. Ainsi, si le message échoue plus loin, le bounce peut revenir au serveur de transfert, puis être retransmis vers l’expéditeur initial.
SRS0 et SRS1
On voit souvent des adresses qui commencent par SRS0 ou SRS1.
SRS0 correspond généralement à une première réécriture.
SRS1 apparaît lorsqu’un message déjà réécrit est transféré une nouvelle fois. Le mécanisme évite d’empiler des adresses trop longues et garde une trace exploitable du chemin.
Le détail exact dépend de l’implémentation, mais l’objectif reste le même :
- prouver que l’adresse réécrite a été générée par le serveur de transfert ;
- éviter les falsifications simples ;
- permettre le retour des erreurs ;
- garder SPF cohérent lors du relais.
SRS ajoute donc une forme de traçabilité technique, sans transformer le contenu du message.
Ce que SRS ne fait pas
SRS ne signe pas le contenu.
Il ne remplace pas DKIM.
Il ne garantit pas que le message sera accepté.
Il ne garantit pas non plus que DMARC passera dans tous les cas.
Pourquoi ? Parce que DMARC regarde l’alignement avec le domaine visible dans le champ “From”.
Après SRS, SPF peut passer avec le domaine du redirecteur, mais ce domaine n’est généralement pas aligné avec le domaine visible de l’expéditeur original.
Dans ce cas, DMARC dépend souvent de DKIM. Si la signature DKIM originale est toujours valide et alignée avec le domaine visible, DMARC peut passer.
Si le transfert modifie le message, ajoute un pied de page, réécrit le sujet ou altère le corps, DKIM peut casser. DMARC devient alors plus fragile.
Où ARC intervient
ARC signifie Authenticated Received Chain.
ARC permet à un serveur intermédiaire de transmettre au destinataire final le résultat des contrôles qu’il a observés avant le transfert.
Il ne remplace pas SRS. Il complète le contexte.
Dans un flux transféré :
- SRS aide à garder SPF cohérent côté redirecteur ;
- DKIM aide à préserver l’authenticité du message original ;
- DMARC vérifie l’alignement avec le domaine visible ;
- ARC peut aider le destinataire final à comprendre qu’un message était authentifié avant son passage par un relais.
Les grands fournisseurs ne traitent pas tous ARC de la même manière, mais il devient utile dans les architectures avec transferts, passerelles et listes de diffusion.
Cas fréquents où SRS compte
SRS devient important dès qu’un serveur renvoie des messages qui ne viennent pas de lui.
On le rencontre notamment dans :
- les alias qui transfèrent vers une boîte externe ;
- les domaines qui redirigent tous les emails vers une autre messagerie ;
- les listes de diffusion ;
- les passerelles anti-spam qui relaient vers Microsoft 365 ou Google Workspace ;
- les migrations où un ancien serveur transfère encore certains comptes ;
- les services d’hébergement qui proposent du forwarding simple.
Dans ces cas, l’absence de SRS peut produire des échecs SPF, des classements en spam ou des refus selon la politique DMARC du domaine original et les règles du destinataire final.
Les points à surveiller
Une configuration SRS doit être proprement pensée.
Les points importants :
- le domaine utilisé pour SRS doit avoir un SPF cohérent ;
- les adresses SRS doivent être validées avec un secret fiable ;
- les bounces doivent pouvoir être décodés et renvoyés correctement ;
- les adresses générées ne doivent pas rester valides indéfiniment ;
- les journaux doivent permettre de comprendre un incident de livraison ;
- les transferts multiples doivent être pris en compte.
SRS mal configuré peut créer d’autres problèmes : bounces perdus, boucles de transfert, adresses trop longues ou diagnostics difficiles.
SRS et délivrabilité
SRS n’est pas un outil magique de délivrabilité.
Il ne rend pas un mauvais message légitime.
Il ne corrige pas une mauvaise réputation IP.
Il ne protège pas contre tous les effets des transferts.
Mais il évite un problème très concret : faire échouer SPF uniquement parce qu’un message légitime a été relayé par un serveur intermédiaire.
Dans une architecture email propre, SRS sert donc à rendre le comportement du transfert plus honnête techniquement. Le redirecteur dit en quelque sorte : “c’est moi qui relaie ce message maintenant, vérifiez mon SPF pour cette étape”.
Conclusion
SRS joue un rôle précis dans les flux email : il réécrit l’adresse d’enveloppe lors d’un transfert pour éviter que SPF échoue à cause du serveur intermédiaire.
Il préserve aussi le chemin de retour des erreurs, ce qui est essentiel pour éviter les bounces perdus ou mal dirigés.
Mais SRS ne remplace pas DKIM, DMARC ou ARC. Il traite surtout le problème SPF lié au forwarding.
Pour une messagerie fiable, il doit être vu comme une brique d’architecture : utile pour les redirections, les alias externes, les passerelles et les listes de diffusion, mais à combiner avec DKIM stable, DMARC cohérent, ARC quand c’est pertinent, et une bonne maîtrise des flux qui transfèrent des messages.