SRS et transfert d’e-mails : SPF, DMARC et le rôle d’ARC

Vous configurez un transfert : contact@your-agency.com → you@gmail.com. Le test fonctionne. Deux semaines plus tard, un contrat envoyé par un client professionnel n’arrive pas, ni dans les spams ni ailleurs. Les journaux indiquent 550 5.7.1 Unauthenticated email, une erreur qui peut avoir plusieurs causes. Vous pourriez aussi voir 550 5.7.520 Access denied si Microsoft 365 bloque le transfert sortant par politique. L’absence du message ne prouve pas qu’il a été supprimé en silence.

Le mécanisme de réécriture de l’expéditeur SRS peut traiter une partie du problème lorsqu’il est correctement configuré. Sans lui, SPF peut échouer si le domaine de l’expéditeur d’enveloppe original n’autorise pas l’IP du serveur de transfert. En 2026, les exigences de Google et Yahoo rendent l’authentification importante, mais n’imposent pas à tous de publier p=reject dans DMARC (exigences de Google pour les expéditeurs). Même avec une politique stricte, un DKIM valide et aligné peut préserver DMARC. Ce guide explique SRS au niveau du protocole, ses limites et les composants d’une configuration adaptée.

Pour une vue d’ensemble, commencez par notre guide de configuration du transfert d’e-mails et de résolution des problèmes courants.

Qu’est-ce que Sender Rewriting Scheme (SRS) ?

SRS réécrit l’enveloppe pour réduire les échecs SPF liés au transfert. Avant de transmettre le message, il remplace l’adresse SMTP de l’enveloppe (MAIL FROM) par une adresse du domaine du serveur de transfert. Cette adresse n’apparaît généralement pas dans l’interface du client, mais reste consultable dans Return-Path. Le destinataire vérifie SPF pour le nouveau domaine, qui doit autoriser l’IP réelle. SPF peut alors réussir, sans garantir la livraison ni l’alignement DMARC avec le From visible. Un échec SPF ne prouve pas à lui seul une usurpation.

Les deux couches d’identité d’un e-mail

Pour examiner SRS, il faut distinguer deux identités souvent confondues. SPF évalue le domaine de l’enveloppe ; DMARC compare les domaines authentifiés par SPF ou DKIM au From visible. Le transfert change la connexion et peut affecter ces vérifications différemment.

L’enveloppe intervient dans la transmission et les avis de non-remise, et son domaine est vérifié par SPF. Le From de l’en-tête apparaît dans le client et sert de référence à l’alignement DMARC. Une nouvelle connexion de transfert peut provoquer un échec SPF si l’IP n’est pas autorisée, sans faire échouer tous les mécanismes : une signature DKIM valide et alignée peut permettre à la vérification DMARC de réussir.

Le problème du nouveau saut : pourquoi SPF peut échouer

Le serveur de transfert ouvre une nouvelle connexion SMTP vers la destination. Si l’expéditeur d’enveloppe reste alice@bank.com, mais que l’IP est la vôtre, SPF la vérifie par rapport à l’enregistrement SPF de bank.com. Dans cet exemple, elle n’est pas autorisée et SPF échoue. Si bank.com publie DMARC p=reject et qu’aucun DKIM valide et aligné ne subsiste, le destinataire peut refuser le message. Un rejet SMTP peut produire un avis de non-remise ; il ne s’agit pas toujours d’une disparition sans notification.

Ce problème peut survenir même avec une règle correcte : il dépend de l’autorisation du nouveau serveur pour le domaine de l’enveloppe. Il n’affecte pas inévitablement tous les transferts. SRS est un moyen d’adapter cette identité à la nouvelle connexion.

Comment SRS réécrit l’enveloppe

SRS remplace l’adresse MAIL FROM par une adresse du domaine du serveur de transfert avant la nouvelle connexion SMTP. L’en-tête visible From: reste celui de l’expéditeur original. L’exemple suivant suppose que le nouveau domaine autorise correctement le serveur :

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

Le destinataire vérifie SPF pour your-domain.com, qui doit autoriser le serveur. Dans ce cas, SPF peut réussir. Le destinataire voit toujours From: alice@bank.com. SRS change l’identité évaluée par SPF, mais son alignement avec le From original reste à examiner.

Comprendre le format d’une adresse SRS

L’adresse SRS de Return-Path peut sembler étrange, mais chaque segment a une fonction. La comprendre aide à vérifier la réécriture et à rechercher les problèmes avec les journaux et les résultats d’authentification.

Exemple : SRS0=4fac=PM=bank.com=alice@your-domain.com

Le second problème : l’alignement SPF après SRS

SRS peut permettre à SPF de réussir la vérification sans préserver l’alignement avec le From original. DMARC exige une vérification réussie et un alignement sur au moins une voie, SPF ou DKIM. Configurer SRS correctement ne garantit donc pas DMARC.

DMARC exige qu’au moins un domaine authentifié soit aligné avec celui de l’en-tête visible From:. Dans l’exemple avec SRS :

• Vérification SPF : PASS : votre IP est autorisée par le domaine de l’enveloppe your-domain.com
• Alignement SPF : FAIL : enveloppe your-domain.com ≠ en-tête bank.com

Dans ce cas, DMARC peut dépendre de DKIM. Une signature originale valide et alignée peut être préservée si les parties signées ne changent pas d’une manière qui affecte la vérification selon sa canonicalisation. Ajouter des avertissements « e-mail externe », des pieds de page antivirus ou convertir MIME de 8 bits en 7 bits peut invalider la signature lorsque le contenu signé est modifié.

Si SPF n’est pas aligné et que les modifications invalident le DKIM aligné, DMARC échoue. Le destinataire peut refuser le message selon sa politique, même si SRS a correctement réécrit l’adresse. Cela ne signifie pas que tous les messages transférés sont perdus.

ARC : un complément de SRS

ARC (Authenticated Received Chain, RFC 8617) peut compléter SRS. Tandis que SRS adapte l’enveloppe pour SPF, ARC permet de sceller les résultats d’authentification réellement observés et de les transmettre au prochain destinataire. Il ne certifie pas l’absence de spam et ne garantit pas l’acceptation.

ARC ajoute ARC-Authentication-Results, ARC-Message-Signature et ARC-Seal. Les résultats précédents peuvent apporter du contexte si DKIM échoue ensuite, mais la signature ARC du message peut elle aussi être affectée par des changements ultérieurs des parties signées. Tous ses composants ne résistent pas à n’importe quelle modification du corps.

La limite : le destinataire décide s’il fait confiance au signataire et à la chaîne. Dans un environnement Microsoft 365 compatible, un administrateur autorisé peut configurer les signataires ARC de confiance via PowerShell (Set-ArcConfig) lorsque cela s’applique et qu’ils ne sont pas déjà inclus. Cette configuration doit respecter la politique de l’organisation. Gmail décide selon ses propres critères ; vous ne pouvez pas lui imposer manuellement cette confiance.

En production, évaluez SRS pour SPF et ARC comme contexte supplémentaire lorsque DKIM n’est pas préservé. Ils ne sont pas universellement nécessaires à chaque livraison et ne suffisent pas ensemble à garantir la réception chez tous les fournisseurs. DNS, filtrage, politiques et réputation comptent aussi.

Diagnostiquer les problèmes SRS : liste de vérification

Si les messages transférés n’arrivent pas, cette liste aide à distinguer un problème SRS d’un blocage préalable ou d’autres causes.

1. Vérifiez Return-Path

Envoyez un test depuis un compte externe via le serveur de transfert, puis inspectez les en-têtes bruts à destination. Les résultats suivants illustrent une IP non autorisée avant SRS et autorisée après ; vérifiez le résultat réel de votre parcours.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Vérifiez les blocages sortants de Microsoft 365

Si vous transférez depuis Microsoft 365 et que le blocage de politique suivant apparaît, le message peut être arrêté avant de quitter l’environnement. SRS ne lève pas cette restriction.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Un administrateur autorisé doit examiner la politique antispam sortante dans le portail Defender et déterminer si le parcours est permis. Ne désactivez pas les contrôles pour contourner la politique. SRS sur le serveur destinataire ne résout pas ce blocage.

3. Vérifiez les boucles de routage

Si A transfère à B et B retransfère à A, une boucle peut se former lorsque les règles permettent de répéter le parcours et que les protections ne l’arrêtent pas plus tôt. Recherchez ces messages dans les journaux :

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

Arrêtez le transfert et utilisez de vraies boîtes

Configurer postsrsd, gérer les secrets HMAC et résoudre des échecs d’alignement DMARC peut ajouter du travail lorsqu’on dirige le courrier professionnel vers des boîtes personnelles pour éviter une facturation par boîte. SRS traite une partie du problème créé par un nouveau saut. Une vraie boîte peut éviter ce parcours lorsqu’elle répond à vos besoins.

Au lieu de transférer contact@client-domain.com vers Gmail et de maintenir SRS, vous pouvez héberger contact@client-domain.com comme boîte IMAP sur TrekMail. Utilisez un client compatible, y compris une intégration prise en charge de l’application Gmail : les messages sont remis directement dans la boîte, sans ce nouveau saut. Cela réduit les problèmes liés au transfert, sans garantir une authentification de bout en bout ou l’arrivée dans la boîte principale. Comparez les options dans notre guide du transfert des e-mails de domaine vers Gmail ou notre comparatif alias et boîte mail.

Vous gérez plusieurs domaines clients ? Centraliser leurs boîtes sur TrekMail peut réduire le travail de maintenance de SRS sur différents serveurs. La séparation des boîtes exige des permissions et une configuration appropriées ; elle ne garantit ni sécurité ni délai fixe de création. Le guide de l’hébergement de messagerie multidomaine explique comment organiser cette gestion selon les limites de la formule.

L’offre TrekMail décrite commence à $3.50 par mois et inclut un essai gratuit de 14 jours. Vérifiez les tarifs, conditions et fonctions actuels avant de créer de vraies boîtes et de remplacer les parcours de transfert devenus inutiles.