Quand la redirection d'email casse SPF (et ce que SRS répare)

SRS : réécrire l'enveloppe pour sauver SPF

Le transfert naïf pose en réalité deux problèmes. Le premier est l'échec SPF décrit plus haut. Le second est le routage des rebonds : si le message redirigé est refusé en bout de chaîne, la notification d'échec repart vers le Return-Path d'origine — vers un expéditeur qui ignore tout de la redirection et reçoit des rebonds incompréhensibles. SRS, formalisé au début des années 2000 en réponse au déploiement de SPF, traite les deux d'un même geste.

Le principe : au moment de réexpédier, le relais réécrit le Return-Path à son propre nom, en encapsulant l'adresse d'origine dans la partie locale. Un message de dupont@exemple.fr transféré par relais-exemple.fr repart avec une enveloppe du type :

MAIL FROM: SRS0=k3v7=T9=exemple.fr=dupont@relais-exemple.fr

Double effet. D'une part, le serveur final évalue désormais SPF sur relais-exemple.fr, dont l'enregistrement autorise bien l'IP du relais : le test passe. D'autre part, un éventuel rebond revient au relais, qui décapsule l'adresse et le réachemine vers l'expéditeur d'origine. Les implémentations sont mûres — module SRS des grandes suites de messagerie, démons dédiés côté Postfix — et la plupart des hébergeurs sérieux réécrivent aujourd'hui les transferts qu'ils opèrent.

Ce que SRS ne répare pas : l'alignement DMARC

Voilà pour la plomberie. Reste l'identité — et c'est là que l'enthousiasme retombe. DMARC n'exige pas seulement un SPF qui passe : il exige que le domaine validé par SPF s'aligne avec le domaine du From visible, celui que le destinataire lit. Or, après réécriture SRS, le Return-Path appartient au relais (relais-exemple.fr) tandis que le From affiche toujours exemple.fr. Deux domaines sans lien organisationnel : l'alignement échoue, en mode strict comme en mode relaxed — et le DNS Tree Walk de DMARCbis, qui détermine le domaine organisationnel, ne rapprochera jamais deux zones étrangères l'une à l'autre.

Le résultat est ce motif si fréquent dans les rapports qu'il mérite son dossier : un SPF qui passe pendant que DMARC échoue. SPF est vert — pour le domaine du relais. DMARC, lui, juge le domaine d'origine et n'a plus que DKIM pour rendre son verdict.

Autrement dit, SRS répare la délivrabilité du relais et le routage des rebonds ; il ne répare pas l'authentification du domaine d'origine. Après une redirection SRS, le sort DMARC d'un message repose à 100 % sur la survie de sa signature DKIM. C'est un point que même des équipes aguerries découvrent tard : SRS est indispensable au forwarding moderne, et parfaitement neutre pour l'alignement DMARC de l'expéditeur.

Trois situations très concrètes

L'alias universitaire. Les universités offrent des adresses à vie (prenom.nom@alumni-exemple.fr) qui ne stockent rien : tout est redirigé vers une boîte personnelle, souvent Gmail. Chaque message envoyé à un ancien élève traverse donc l'infrastructure de l'université avant d'arriver chez Google. Dans les rapports du domaine émetteur, cela dessine des lignes caractéristiques : IP universitaires, SPF en échec (ou passant sur un domaine tiers via SRS), DKIM qui sauve la mise quand la signature est restée intacte.

La boîte de contact redirigée. Une PME fait suivre contact@exemple.fr vers la boîte Gmail du gérant. Ici, le domaine joue le rôle du relais : ce sont les messages des clients qui sont réexpédiés, et c'est leur authentification qui se dégrade. Sans SRS, Gmail voit arriver des messages de tiers depuis une IP non autorisée par leur SPF — avec, à la clé, un classement en spam qui frappe le courrier des clients, pas celui du domaine. Opérer une redirection crée des obligations envers les domaines des autres.

La redistribution interne. Une adresse de service (commandes@exemple.fr) qui réexpédie vers trois collaborateurs, ou un ancien domaine renvoyé vers le nouveau après une fusion : mêmes mécanismes, à ceci près que le trafic est prévisible et l'infrastructure maîtrisée. C'est le cas le plus simple à assainir — et souvent le premier visible dans les rapports.

ARC, le filet complémentaire

Pour les chaînes de transfert que ni SRS ni DKIM ne suffisent à sauver, un troisième standard entre en scène : ARC (Authenticated Received Chain, RFC 8617). L'idée : chaque intermédiaire scelle dans des en-têtes dédiés le résultat des vérifications qu'il a lui-même effectuées à réception. Le destinataire final peut ainsi constater que le message passait SPF et DKIM avant la redirection, et choisir de passer outre un échec DMARC constaté à l'arrivée.

Le mot important est « choisir » : ARC ne force rien, il documente. Le récepteur n'en tient compte que s'il fait confiance aux intermédiaires qui ont signé la chaîne — Gmail et Microsoft 365 l'évaluent, chacun selon ses propres critères. Le fonctionnement détaillé, sceau par sceau, est décrit dans le guide consacré à ARC. Filet précieux, donc, mais filet seulement : rien ne remplace une signature DKIM qui survit au trajet.

Ce que les rapports RUA en montrent

Bonne nouvelle : la redirection laisse une empreinte très reconnaissable dans les rapports agrégés. Les lignes concernées combinent des volumes modestes, des IP dispersées et changeantes — universités, hébergeurs, opérateurs de boîtes personnelles —, un SPF en échec sur le domaine d'origine (ou en réussite non alignée sur un domaine de relais, marque de SRS), et un DKIM aligné qui, seul, maintient le verdict DMARC au vert.

Les lignes à surveiller de près sont les autres : celles où DKIM échoue aussi. Un relais qui modifie le contenu — bannière, réencodage — produit du courrier légitime intégralement en échec, celui-là même qui sera perdu une fois la politique durcie. Estimer cette part résiduelle, relais par relais, est exactement le travail préparatoire d'un passage à l'application : une plateforme d'analyse qui identifie les IP (tel fournisseur de boîtes, telle infrastructure académique) transforme ces lignes anonymes en diagnostic actionnable.

Quelle politique quand la redirection fait partie de la vie

Faut-il renoncer à p=reject parce que des destinataires redirigent leur courrier ? Non — mais il faut le faire en connaissance de cause. Trois principes s'imposent. D'abord, signer DKIM absolument tous les flux, y compris transactionnels et applicatifs : c'est la seule authentification qui traverse les redirections, et chaque flux non signé est un flux condamné au premier transfert. Ensuite, quantifier avant de durcir : les rapports disent précisément quelle part du trafic légitime transite par des relais destructeurs de signature — souvent une fraction marginale, parfois un angle mort significatif. Enfin, accepter un résidu : un domaine à p=reject perdra les rares messages redirigés dont la signature a été brisée en route. C'est un coût réel, généralement minime, à mettre en regard de ce que l'application ferme aux usurpateurs.

DMARCbis n'a pas changé cette donne — la redirection reste la limite assumée du modèle —, mais son mode test (t=y), qui remplace l'ancien pct, offre une marche intermédiaire propre pour observer l'effet d'une politique avant de la rendre pleinement contraignante.

En résumé

Une redirection réexpédie le message depuis l'IP du relais, absente — et c'est normal — du SPF de l'expéditeur d'origine : l'échec SPF est structurel, pas accidentel. DKIM survit tant que le contenu n'est pas altéré, ce qui en fait l'unique authentification fiable à travers un transfert. SRS réécrit le Return-Path au nom du relais : il sauve la délivrabilité du forwarding et le routage des rebonds, mais ne restaure en rien l'alignement DMARC du domaine d'origine — après SRS, tout repose sur DKIM, avec ARC en filet documentaire que les grands récepteurs sont libres d'honorer. Dans les rapports, le motif se lit clairement, et il se gère : signature DKIM généralisée, quantification du résidu, puis durcissement.

Le point de départ se trouve à portée de main : un passage du domaine par l'analyse DMARC gratuite révèle l'état de SPF, de DKIM et de la politique publiée, redirections comprises. Pour suivre ensuite ces flux relayés semaine après semaine et mener le domaine vers p=reject sans sacrifier le courrier légitime, la création d'un compte donne accès aux rapports décodés, sources identifiées — y compris celles qui ne font que faire suivre.