Le transfert d’e-mails casse DMARC — Corrigez-le avec SRS (et autres options)

décembre 7, 2025 • février 3, 2026 • Lecture : 28 min • Views: 6

Cet article vous a aidé ?

Le transfert d’e-mails ressemble à la plomberie : vous reliez A à B, puis rentrez chez vous. Jusqu’au jour où le PDG transfère une facture fournisseur vers sa boîte personnelle, que le message disparaît, et vous passez l’après-midi à expliquer « l’alignement » à des gens qui croient que DNS est un service.

Le transfert casse DMARC de façons peu mystérieuses, mais insuffisamment documentées là où les opérateurs occupés regardent réellement. La bonne nouvelle : vous pouvez corriger la plupart des cas avec SRS, plus quelques habitudes opérationnelles ennuyeuses qui vous évitent des revues d’incidents.

Pourquoi le transfert casse DMARC (la défaillance mécanique)

DMARC est simple en concept et brutal en pratique. Il demande au système récepteur :

Est-ce que ce message s’authentifie avec SPF et/ou DKIM ?
Les identifiants authentifiés s’alignent-ils avec le domaine affiché dans From: ?
Si non, que dit la politique DMARC publiée par l’expéditeur et que dois-je en faire ?

Le transfert casse la première partie de cette chaîne d’une façon très spécifique : il change l’adresse IP qui livre le message tout en gardant intact l’en-tête From: visible.

SPF passe chez l’émetteur original, puis échoue chez le récepteur après le transfert

SPF est évalué par rapport à l’IP de connexion et au domaine dans l’enveloppe SMTP (Return-Path). Quand un forwarder relaie un message, c’est son IP qui devient l’IP de connexion. À moins que l’expéditeur original n’ait autorisé les IP du forwarder dans SPF (ce qui n’est généralement pas le cas), SPF échoue.

À ce stade, beaucoup répondent « mais il y a DKIM ». Oui. Et DKIM peut vous sauver — jusqu’à ce qu’il ne le fasse pas :

Si la signature DKIM survit intacte et s’aligne avec le domaine From, DMARC peut passer même si SPF échoue.
Si le forwarder modifie le message (ajout de pied de page, tag du sujet, reformattage de lignes, ré-encodage MIME), DKIM peut se casser.

DMARC n’a besoin que d’un seul des deux (SPF ou DKIM) pour réussir ET s’aligner. Le transfert provoque couramment l’échec de SPF. Les listes de diffusion et certains gateways « utiles » provoquent souvent la casse de DKIM aussi. Voilà votre échec DMARC.

Alignement : la partie que les gens zappent, puis regrettent

Même lorsque SPF réussit techniquement, DMARC peut échouer à cause d’un mauvais alignement. L’alignement compare le domaine qui s’est authentifié (le domaine SPF ou le d= DKIM) au domaine dans l’en-tête From visible.

Si votre forwarder réécrit l’enveloppe sender mais le fait avec un domaine qui ne s’aligne pas avec le From, DMARC échoue toujours à moins que DKIM ne réussisse et s’aligne. C’est pourquoi « nous avons activé SRS mais ça n’a pas aidé » est parfois réel : SRS corrige les résultats SPF, mais pas l’alignement avec le From, sauf si vous garantissez aussi l’alignement DKIM ou acceptez que l’alignement SPF soit avec le domaine du forwarder.

Une vérité sèche : DMARC n’a pas été conçu pour faciliter le transfert. Il a été conçu pour rendre l’usurpation coûteuse. Le transfert est un dommage collatéral.

Blague #1 : Transférer des e-mails, c’est comme déplacer le courrier de quelqu’un à la main — tôt ou tard on vous accuséra d’avoir falsifié l’écriture.

Faits et courte histoire qui expliquent le bazar actuel

Un peu de contexte aide parce que les débats autour de DMARC deviennent vite émotionnels, comme le sport, la religion et le format de configuration MTA « lisible ». Voici des faits concrets qui façonnent le problème de transfert :

SPF vérifie le chemin, pas le contenu. Il valide d’où le mail provient (IP de connexion) par rapport au domaine de l’enveloppe sender.
DKIM vérifie le contenu, pas le chemin. Il signe les en-têtes/corps du message ; le transfert peut le préserver si rien n’est modifié.
DMARC a été publié en 2015 comme RFC (7489). Il a unifié la politique et le reporting autour de SPF/DKIM plus l’alignement.
Le transfert existe depuis des décennies, avant SPF/DKIM. Le modèle SMTP original supposait la confiance entre opérateurs. Cette époque est révolue.
Yahoo et AOL ont durci les politiques DMARC en 2014. Les listes de diffusion ont cassé bruyamment ; l’industrie a commencé à prendre DMARC au sérieux parce que les boîtes de réception se sont vidées.
Beaucoup de gateways d’entreprise modifient le courrier « pour la sécurité ». Les disclaimers, tags DLP et le re-wrapping de contenu invalident régulièrement DKIM.
SRS existait avant que DMARC ne devienne courant. Il a été conçu pour faire survivre SPF lors du transfert en réécrivant l’enveloppe sender.
ARC (Authenticated Received Chain) est plus récent. C’est un moyen pour les intermédiaires d’attester des résultats d’authentification en amont quand les messages sont transformés.
La mise en application de DMARC est conduite par les récepteurs. Même avec « p=none », les récepteurs peuvent appliquer des politiques locales ; avec « quarantine » ou « reject », vos mails transférés vivent dangereusement.

Modes de défaillance : ce qui casse, ce qui survit

Cas 1 : Transfert simple, sans modification

Typique : user@forwarder.example transfère vers user@gmail.com.

SPF chez Gmail : échoue (l’IP du forwarder n’est pas autorisée par le domaine du Return-Path original).
DKIM chez Gmail : passe probablement (message inchangé).
DMARC : passe si DKIM s’aligne avec From.

C’est pourquoi certains transferts « fonctionnent bien » pendant des années, jusqu’à ce qu’un fournisseur change de sélecteur DKIM ou que vous ajoutiez un pied de page. Ensuite ça ne fonctionne plus.

Cas 2 : Le forwarder ajoute un pied de page/disclaimer

Commun en entreprise : « Ce courriel peut être confidentiel… » ajouté en bas.

SPF : échoue (même raison).
DKIM : échoue (le corps a changé).
DMARC : échoue sévèrement, surtout si l’expéditeur publie « p=reject ».

Cas 3 : La liste de diffusion détruit DKIM et SPF

Les listes de diffusion souvent :

réécrivent le Subject (ex. « [list] »),
modifient le corps (pied de page, info de désabonnement),
réexpédient via des serveurs de liste.

Cela casse DKIM ; SPF ne s’aligne pas parce que les serveurs de liste ne figurent pas dans le SPF du domaine original. DMARC échoue à moins que la liste mette en place des mitigations (réécriture du From, ARC ou re-signature DKIM alignée si possible).

Cas 4 : « Conserver le From dans l’en-tête, mais changer l’enveloppe sender »

C’est ce que fait SRS : il réécrit MAIL FROM / Return-Path tout en laissant l’en-tête From inchangé.

Résultat :

SPF peut passer parce que le forwarder est autorisé à envoyer pour son propre domaine SRS.
DMARC exige toujours l’alignement : l’alignement SPF sera avec le domaine SRS (le forwarder), pas avec le domaine From original.
Donc : DMARC ne passera via SPF que si le domaine MAIL FROM réécrit s’aligne avec l’en-tête From (ce qui n’est généralement pas le cas), d’où l’importance continue de l’alignement DKIM.

C’est un point qui se tord en réunion. SRS prévient surtout le rejet basé sur SPF et réduit les problèmes de backscatter. Il ne rend pas l’alignement DMARC avec le From original magique. Il rend le transfert moins cassé, pas parfaitement propre.

SRS : la solution qui correspond réellement au problème

SRS (Sender Rewriting Scheme) réécrit l’enveloppe SMTP sender afin que les vérifications SPF s’effectuent contre le domaine du forwarder. Cela empêche qu’un message transféré échoue SPF à cause de l’IP du forwarder. Cela assure aussi que les rebonds retournent au forwarder pour qu’il route les DSN correctement vers l’expéditeur original, au lieu de créer du backscatter.

Ce que SRS change, concrètement

Before forwarding :

MAIL FROM: <alice@sender.example>
From: Alice <alice@sender.example>

After forwarding with SRS (example) :

MAIL FROM: <SRS0=hash=timestamp=sender.example=alice@forwarder.example>
From: Alice <alice@sender.example> (unchanged)

Maintenant le système récepteur évalue SPF pour forwarder.example par rapport à l’IP de sortie du forwarder, et ça passe. C’est l’objectif.

Pourquoi SRS vaut toujours la peine

Parce que sans lui, SPF est garanti d’échouer sur le courrier transféré sauf si le domaine original a fait quelque chose d’inhabituel. L’échec SPF n’est pas toujours fatal à DMARC, mais c’est une grosse partie de l’histoire d’authentification. Avec SRS, vous arrêtez au moins de casser SPF de manières entièrement prévisibles.

SRS ne résout pas la casse de DKIM

Si votre forwarder modifie les messages (disclaimers, réécriture de liens, scan d’attachements qui ré-encode), DKIM échouera toujours. SRS ne peut rien pour ça. La solution : cesser de modifier les mails que vous ne possédez pas, ou implémenter ARC pour préserver les assertions d’authentification en amont, ou réécrire From (ce qui change l’identité visible et est politiquement douloureux).

Où SRS doit se situer dans l’architecture

SRS doit vivre à la frontière de transfert : l’endroit où vous acceptez un message puis l’envoyez vers un domaine différent tout en préservant le From original.

Ne montez pas SRS sur tous les chemins sortants sans réfléchir. Ça complique le dépannage et peut confondre le traitement des rebonds. Utilisez-le uniquement pour les flux de forwarding.

Autres options : préservation DKIM, ARC et « ne pas transférer »

Option A : Préserver DKIM en ne touchant pas au message

Si vous pouvez transférer le mail sans le modifier, faites-le. Beaucoup d’organisations cassent DKIM sans bonne raison.

Exemples de comportements évitables qui cassent DKIM :

Ajouter des mentions légales à chaque message entrant (vous ne possédez pas le contenu).
Réécrire les URLs pour le suivi des clics sur des mails transférés (surtout pour des expéditeurs externes).
Convertir les structures MIME « pour normalisation ».

Choisissez d’être ennuyeux. L’ennuyeux est fiable.

Option B : ARC pour les intermédiaires qui doivent transformer le mail

ARC (Authenticated Received Chain) permet à un intermédiaire d’enregistrer les résultats d’authentification qu’il a observés à la réception puis de signer cet enregistrement. Un récepteur en aval peut décider de faire confiance aux assertions ARC de l’intermédiaire même si DKIM a cassé plus tard.

ARC n’est pas une solution miracle :

Les récepteurs choisissent s’ils font confiance ou non à votre chaîne ARC.
ARC ajoute de la complexité et de la gestion de clés.
Si votre forwarder est fréquemment abusé, votre réputation ARC en souffrira.

Utilisez ARC lorsque vous devez modifier des messages (listes de diffusion, gateways de sécurité) et que vous avez la maturité opérationnelle pour gérer les clés, surveiller les échecs et maintenir vos relais propres.

Option C : Réécriture du From (style liste de diffusion)

Les listes de diffusion réécrivent souvent l’en-tête From vers un domaine qu’elles contrôlent (ex. « alice via list.example »). Cela aligne l’authentification sur un domaine que la liste peut légitimement signer et autoriser.

Techniquement, cela « fonctionne ». Cela change aussi l’identité visible par l’utilisateur, brise les workflows de réponse, et provoque des disputes politiques d’une intensité généralement réservée aux plans de sièges au bureau.

Option D : Arrêter le transfert ; utiliser un accès délégué approprié

Si la raison métier du transfert est « je veux lire mes mails pro dans ma boîte perso », la bonne solution est généralement l’accès délégué ou une configuration de client, pas le transfert SMTP.

Le transfert pousse l’identité, la conformité, la rétention et la réponse aux incidents dans un trou que vous ne pouvez pas surveiller. Si vous êtes responsable des systèmes de production, vous ne créez pas des angles morts volontairement.

Blague #2 : La seule chose plus persistante qu’un e-mail transféré est l’invitation calendrier qui s’accroche à lui pour toujours.

Guide de diagnostic rapide

Vous avez un rapport : « des e-mails transférés manquent » ou « des clients disent qu’ils n’ont jamais reçu le message ». Ne commencez pas par fixer des rapports agrégés DMARC pendant des heures. Commencez par un seul message échoué et suivez la chaîne.

Première étape : identifier où la perte se produit

Le message a-t-il été accepté par le MTA entrant du forwarder ?
Le message a-t-il été relayé en sortie par le forwarder ?
Le message a-t-il été rejeté ou mis en quarantaine par le récepteur final ?

Deuxième étape : vérifier les résultats d’authentification au dernier saut

Résultat SPF (pass/fail/softfail/neutral).
Résultat DKIM (pass/fail, quel domaine d= a signé).
Résultat DMARC (pass/fail, quel identifiant s’est aligné).

Troisième étape : confirmer si le forwarder a modifié le contenu

Comparer en-têtes et corps avant/après transfert si possible.
Rechercher disclaimers, tags de sujet, changements de boundary MIME.
Vérifier si un appliance de sécurité a « réécrit les liens ».

Quatrième étape : choisir la correction selon l’échec

SPF échoue, DKIM passe : vous pouvez déployer SRS pour réduire la fragilité, mais il se peut que vous passiez déjà DMARC via DKIM. Décidez selon la fréquence des cassures DKIM dans votre environnement.
SPF échoue, DKIM échoue : vous devez arrêter de modifier le contenu ou implémenter ARC ou réécrire From. SRS seul ne vous sauvera pas.
SPF passe, DMARC échoue : problème d’alignement — le domaine authentifié ne s’aligne pas avec le header From. Corrigez l’alignement DKIM ou ajustez la stratégie de réécriture.

Idée paraphrasée (Werner Vogels) : « Tout échoue ; concevez pour pouvoir le détecter rapidement et récupérer automatiquement. » Cela s’applique aux flux de mail plus que quiconque veut l’admettre.

Tâches pratiques avec commandes, sorties et décisions

Ci-dessous des tâches pratiques que vous pouvez exécuter sur un relais mail Linux typique (exemples Postfix) ou depuis une station d’administration. Chaque tâche inclut : la commande, une sortie d’exemple, ce que ça signifie, et la décision à prendre.

Task 1: Confirm the DMARC policy for the sender domain

cr0x@server:~$ dig +short TXT _dmarc.sender.example
"v=DMARC1; p=reject; rua=mailto:dmarc@sender.example; adkim=s; aspf=s"

Ce que cela signifie : L’expéditeur demande aux récepteurs de rejeter les messages échouant ; alignement strict pour DKIM et SPF.

Décision : Si vous transférez du courrier depuis ce domaine, vous devez préserver l’alignement DKIM ou vous attendre à des rejets. SRS n’alignera pas SPF sur sender.example.

Task 2: Check SPF record for the sender domain (to understand why forwarding fails)

cr0x@server:~$ dig +short TXT sender.example
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

Ce que cela signifie : Seules les plages IP listées et le provider sont autorisés. Votre forwarder n’y figure pas.

Décision : Attendez-vous à un échec SPF après transfert sauf si vous appliquez SRS (ou que l’expéditeur ajoute votre forwarder, ce qu’il ne fera pas).

Task 3: Validate that your forwarder domain has SPF allowing its own outbound IPs

cr0x@server:~$ dig +short TXT forwarder.example
"v=spf1 ip4:198.51.100.10 -all"

Ce que cela signifie : Votre forwarder est légitime pour envoyer au nom de son propre domaine.

Décision : SRS peut s’appuyer sur forwarder.example parce que SPF passera pour votre IP de sortie.

Task 4: Inspect a message’s Authentication-Results (from the final receiver)

cr0x@server:~$ grep -iE 'authentication-results|dmarc=|spf=|dkim=' message.eml | head -n 8
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@sender.example does not designate 198.51.100.10 as permitted sender) smtp.mailfrom=alice@sender.example;
       dkim=pass header.i=@sender.example header.s=s1 header.b=abc123;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender.example

Ce que cela signifie : SPF a échoué à cause de l’IP de transfert, mais DKIM a passé et s’est aligné, donc DMARC a passé.

Décision : Si votre chaîne de transfert modifie parfois le contenu, vous êtes à un disclaimer d’une panne. Envisagez SRS et/ou la suppression des modifications.

Task 5: Inspect Postfix logs for rejection at the next hop

cr0x@server:~$ sudo grep -E "status=bounced|reject:|dmarc" /var/log/mail.log | tail -n 10
Jan 03 10:22:11 mx postfix/smtp[24190]: 9C2B81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=1.2, delays=0.1/0.0/0.6/0.5, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 This message does not pass authentication checks (SPF and DKIM both fail) 550-5.7.26 and has a DMARC policy of reject. (in reply to end of DATA command))

Ce que cela signifie : Le récepteur final a rejeté à cause d’un échec DMARC ; SPF et DKIM ont tous deux échoué.

Décision : SRS seul ne réparera pas cela si DKIM casse à cause de modifications. Trouvez ce qui a changé le message ou implémentez ARC / arrêtez les transformations.

Task 6: Confirm whether you are modifying messages (header/body) in transit

cr0x@server:~$ sudo postconf -n | egrep 'header_checks|body_checks|milter|content_filter'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
header_checks = regexp:/etc/postfix/header_checks
content_filter = smtp-amavis:[127.0.0.1]:10024

Ce que cela signifie : Milters et filtres de contenu sont actifs ; header_checks peut réécrire ; amavis peut ré-encoder.

Décision : Supposez que DKIM cassera parfois. Soit bypassez le filtrage pour le mail transféré, préservez DKIM, ou ajoutez ARC en acceptant le coût opérationnel.

Task 7: Check if header_checks are adding disclaimers or tags

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/header_checks
/^Subject:/ PREPEND X-Company-Notice: scanned
/^From:/    PREPEND X-Forwarded-By: forwarder.example

Ce que cela signifie : Vous modifiez des en-têtes. La modification d’en-tête peut invalider DKIM si l’en-tête modifié est signé.

Décision : Arrêtez de le faire pour le mail transféré, ou assurez-vous que les en-têtes modifiés ne sont pas dans la liste des en-têtes signés par DKIM (souvent impossible à garantir).

Task 8: Confirm the forwarding flow uses a dedicated transport (so you can apply SRS selectively)

cr0x@server:~$ sudo postconf -n | egrep 'transport_maps|sender_dependent_default_transport_maps'
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo postmap -q user@forwarder.example /etc/postfix/transport
forward-srs:

Ce que cela signifie : Ce destinataire est routé via un transport personnalisé nommé forward-srs.

Décision : Bien. Vous pouvez appliquer SRS uniquement sur ce transport, au lieu de tout réécrire et créer de nouveaux mystères.

Task 9: Install and enable SRS support (example: postsrsd)

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y postsrsd
...output...
Setting up postsrsd (1.10-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/postsrsd.service → /lib/systemd/system/postsrsd.service.

Ce que cela signifie : postsrsd est installé et activé en tant que service système.

Décision : Procédez à la configuration de Postfix pour appeler le démon SRS, mais seulement pour les chemins de forwarding si possible.

Task 10: Check postsrsd is running and listening

cr0x@server:~$ systemctl status postsrsd --no-pager
● postsrsd.service - PostSRSd
     Loaded: loaded (/lib/systemd/system/postsrsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-03 10:12:44 UTC; 8min ago
   Main PID: 1827 (postsrsd)
     Tasks: 1
     Memory: 1.2M
     CGroup: /system.slice/postsrsd.service
             └─1827 /usr/sbin/postsrsd -d -p 10001 -s forwarder.example

Ce que cela signifie : Le démon tourne et est configuré avec le domaine SRS forwarder.example, écoutant sur le port 10001.

Décision : Vous pouvez maintenant pointer Postfix sender_canonical_maps ou un service de nettoyage dédié vers lui.

Task 11: Configure Postfix to use SRS for envelope sender rewriting (example pattern)

cr0x@server:~$ sudo postconf -n | egrep 'sender_canonical_maps|sender_canonical_classes|recipient_canonical_maps'
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:127.0.0.1:10001

Ce que cela signifie : Postfix réécrira l’enveloppe sender via la map TCP (postsrsd) pour tout le courrier utilisant sender_canonical_maps.

Décision : Si c’est trop large, reculez et limitez : appliquez via un transport ou service dédié, pas des defaults globaux.

Task 12: Reload Postfix and confirm configuration sanity

cr0x@server:~$ sudo postfix check
...output...
cr0x@server:~$ sudo systemctl reload postfix
...output...

Ce que cela signifie : Postfix a accepté la configuration.

Décision : Procédez à un test contrôlé : transférez un message signé d’un domaine DMARC strict et inspectez le Return-Path et les résultats d’authent.

Task 13: Send a test message and confirm SRS rewriting occurred

cr0x@server:~$ sudo grep -E "from=<|to=<|srs" /var/log/mail.log | tail -n 20
Jan 03 10:28:01 mx postfix/cleanup[25102]: 1A2B312345: message-id=<test-170428@sender.example>
Jan 03 10:28:01 mx postfix/qmgr[901]: 1A2B312345: from=<SRS0=HHH=TT=sender.example=alice@forwarder.example>, size=18234, nrcpt=1 (queue active)
Jan 03 10:28:02 mx postfix/smtp[25106]: 1A2B312345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, dsn=2.0.0, status=sent (250 2.0.0 OK ...)

Ce que cela signifie : L’enveloppe sender a été réécrite en SRS0=…@forwarder.example et le message a été accepté par Gmail.

Décision : Vous avez réduit la casse liée à SPF. Maintenant vérifiez le résultat DMARC côté récepteur ; si DKIM échoue à cause de modifications, SRS ne vous sauvera pas.

Task 14: Verify you are not creating open relay conditions while “fixing forwarding”

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Ce que cela signifie : Le relais est limité aux réseaux de confiance et aux utilisateurs authentifiés ; les destinataires non authentifiés sont différés.

Décision : Gardez-le ainsi. SRS ajoute de la légitimité à votre mail sortant ; vous ne voulez pas que des attaquants empruntent cette légitimité.

Task 15: Look for signs DKIM is being broken by transformation appliances

cr0x@server:~$ grep -iE 'amavis|altered|footer|disclaimer|repack|mime' /var/log/mail.log | tail -n 15
Jan 03 10:25:33 mx amavis[2201]: (02201-11) Passed CLEAN, but modified headers: added X-Virus-Scanned
Jan 03 10:25:33 mx amavis[2201]: (02201-11) body modified: appended disclaimer

Ce que cela signifie : Le contenu est modifié. Les signatures DKIM des expéditeurs externes échoueront probablement après ce point.

Décision : Pour les flux de forwarding, contournez les modifications ou implémentez ARC. Si votre équipe sécurité refuse, dites la vérité : certains mails transférés seront rejetés, et ce n’est pas un bug, c’est une politique.

Task 16: Verify ARC headers are present (if you deploy ARC)

cr0x@server:~$ grep -iE '^ARC-Seal:|^ARC-Message-Signature:|^ARC-Authentication-Results:' message.eml | head -n 10
ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=alice@sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...

Ce que cela signifie : Le forwarder affirme ce qu’il a vu à la réception et signe cette assertion.

Décision : Confirmez que les récepteurs en aval importants pour vous utilisent effectivement les signaux ARC. Sinon, ARC n’améliorera peut-être pas assez la délivrabilité pour justifier la complexité.

Trois mini-histoires d’entreprise (douleur, regret et une victoire)

Mini-histoire 1 : L’incident causé par une fausse hypothèse

L’entreprise avait une règle de transfert « simple » : tout le courrier adressé à acquisitions@corp.example était transféré vers une adresse de l’équipe deals hébergée chez un autre fournisseur. Ça fonctionnait depuis des années. Tout le monde supposait que c’était OK car il n’y avait pas de tickets.

Puis un partenaire majeur a renforcé son authentification : DMARC est passé de p=none à p=reject avec alignement strict. Le forwarder relaya encore le courrier exactement comme avant. SPF a échoué chez le nouveau provider (comme toujours). DKIM aurait pu sauver la situation — sauf que la gateway corporate avait ajouté un disclaimer de conformité à tous les mails sortants, y compris les transferts. DKIM a cassé.

Le premier symptôme n’a pas été un bounce. Ce fut le silence. L’équipe procurement du partenaire a cru que l’entreprise les ghostait. Les internes se sont accusés mutuellement (d’abord « le filtre du partenaire », ensuite « notre provider », puis chacun se renvoyant la faute), ce qui est l’ordre traditionnel des opérations.

La correction fut humiliante : ils ont désactivé l’injection de disclaimer pour le transport de forwarding, déployé SRS pour réécrire l’enveloppe sender, et ajouté une règle : tout ce qui est transféré à l’externe ne doit pas être muté à moins que le business n’accepte le risque. Il n’y avait pas de bouton magique « activer DMARC ». Juste des décisions précises de plomberie.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation voulait réduire la latence et les dépendances externes. Ils ont consolidé plusieurs petits MTA en un « smart relay » qui faisait antivirus, tagging DLP, réécriture d’URL et normalisation d’en-têtes. C’était une boîte propre : moins de systèmes, moins d’alertes, un tableau de bord qui avait l’air confiant.

Puis ils ont activé la réécriture agressive des URLs pour la protection. Cela changeait régulièrement le corps des messages. Les signatures DKIM des expéditeurs externes ont commencé à échouer. La plupart des livraisons directes ont survécu parce que SPF s’alignait et passait. Les messages transférés, eux, non : SPF échouait après transfert, DKIM échouait à cause de la réécriture, DMARC échouait, et les expéditeurs stricts se faisaient rejeter.

L’optimisation « fonctionnait » selon leurs métriques — moins de serveurs, moins de pièces en mouvement — tout en dégradant silencieusement la délivrabilité pour des workflows business critiques : mails transférés, notifications de ticketing routées vers des boîtes perso, et quelques flux fournisseurs externes.

Ils ont récupéré en construisant une voie de contournement : les messages identifiés comme purs forwards (basé sur le routage et la classe de destinataire) ont contourné la modification du corps et la réécriture d’URL. La sécurité n’était pas ravie, mais ils ont accepté après avoir vu que l’alternative était la non-livraison sans recours utilisateur. Le meilleur contrôle de sécurité est celui qui laisse encore fonctionner le business.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait une règle : tout changement de traitement du courrier devait être testé avec un ensemble connu de domaines externes publiant des politiques DMARC strictes. Ils gardaient un petit corpus de messages de test (signés DKIM, types MIME variés) et les faisaient passer par leurs relays avant et après changement.

Un jour ils ont mis à jour un paquet milter. Les notes de version étaient vagues mais le changement avait l’air mineur. Leur suite de test pré-déploiement a immédiatement montré des échecs DKIM sur les messages transférés ; le milter avait commencé à re-wrappper les longues lignes et à normaliser les espaces. SPF échouait déjà sur le mail transféré, donc DMARC cassait désormais aussi.

Comme ils l’ont détecté avant le déploiement en production, ils ont eu des options : bloquer la version du milter, ajuster la config pour éviter les changements de canonicalisation, et appliquer SRS où nécessaire. Pas d’incident. Pas d’escalade exécutive. Pas de bannière « email en panne » dans le chat.

La pratique était ennuyeuse : un banc de tests, une checklist, et un peu de paranoïa. Cela les a sauvés d’apprendre la leçon en public.

Erreurs courantes : symptômes → cause profonde → correction

1) Symptom: Forwarded mail disappears, no bounce

Cause profonde : Le récepteur final met en quarantaine ou rejette silencieusement sur base de DMARC ; les bounces peuvent aller vers un Return-Path réécrit ou invalide, ou être supprimés.

Correction : Inspectez les logs Postfix pour les DSN 5.7.26/5.7.1. Ajoutez une boîte surveillée pour les rebonds, et assurez-vous que SRS est configuré afin que les DSN vous soient renvoyés. Si DKIM est modifié, arrêtez les modifications ou adoptez ARC.

2) Symptom: SPF fail on every forwarded message

Cause profonde : Comportement normal. L’IP du forwarder n’est pas autorisée par le SPF du domaine expéditeur original.

Correction : Implémentez SRS à la frontière du forwarder. Ne demandez pas aux tiers d’ajouter vos IPs dans leur SPF ; ce n’est pas comme ça que le monde fonctionne.

3) Symptom: DKIM fails only after you enabled “legal disclaimer”

Cause profonde : L’injection de pied de page modifie le corps ; la signature DKIM ne correspond plus.

Correction : Désactivez l’injection de pied de page pour le mail transféré et les mails de listes, ou appliquez-la uniquement au courrier que vous générez. Si vous devez ajouter des avis, faites-le au niveau client/UI, pas dans la payload SMTP.

4) Symptom: DMARC fails even though SPF passes

Cause profonde : SPF passe pour un domaine qui ne s’aligne pas avec le header From (ex. utilisation d’un domaine de rebond ou d’un domaine de relais tiers).

Correction : Assurez-vous que le domaine utilisé pour l’authentification SPF s’aligne avec le header From (l’alignement organisationnel strict/relax dépend de la politique de l’expéditeur). Sinon appuyez-vous sur un DKIM aligné.

5) Symptom: Some providers accept forwarded mail, others reject

Cause profonde : Les récepteurs pèsent différemment DKIM/SPF/ARC ; certains appliquent DMARC plus strictement ou ont des politiques anti-abus locales.

Correction : Concevez pour les récepteurs stricts : préservez DKIM, évitez les transformations et déployez SRS. Traitez « ça marche chez le fournisseur A » comme une anecdote, pas comme une validation.

6) Symptom: Bounce storms or backscatter after forwarding

Cause profonde : Le forwarder conserve le MAIL FROM original, donc les DSN vont à l’expéditeur original même si le forwarder a causé le problème, ou bien à des expéditeurs forgeries quand du spam est impliqué.

Correction : SRS. Assurez-vous aussi de rejeter le mail non authentifié au moment SMTP quand c’est possible pour éviter de générer des DSN pour des ordures.

7) Symptom: ARC added, but nothing improved

Cause profonde : Les récepteurs ne font pas confiance à votre chaîne ARC (réputation), ou vous ne scellez pas correctement, ou vos modifications sont trop extrêmes.

Correction : Validez les signatures ARC, gardez vos relais propres, et ne supposez pas qu’ARC est universellement honoré. Si vous pouvez éviter les modifications, faites-le à la place.

Checklists / plan étape par étape

Plan A: You run a forwarder and want forwarding to “mostly work”

Inventoriez les chemins de transfert. Listez toutes les règles, alias et transferts au niveau boîte qui envoient à l’extérieur.
Séparez le trafic de forwarding. Utilisez un transport Postfix dédié ou une instance séparée pour les forwards.
Déployez SRS sur ce flux. Assurez-vous que votre domaine de transfert publie un SPF autorisant les IP d’envoi.
Arrêtez de modifier le mail transféré. Pas de pieds de page, pas de tags de sujet, pas de réécriture d’URL. Si le scan sécurité est nécessaire, faites-le de façon à préserver les octets du message.
Testez avec des domaines DMARC stricts. Utilisez un jeu de messages de test reproductible et validez les Authentication-Results chez les destinataires finaux.
Surveillez les rejets par codes DSN. Alertez sur les pics en 5.7.26, 5.7.1 et « DMARC policy of reject ».
Préparez un rollback. SRS et les filtres touchent le comportement central du mail. Rendez les changements réversibles sans héroïsme.

Plan B: You operate a mailing list or gateway that must modify messages

Décidez d’une stratégie d’identité. Soit réécrire From (fonctionne mais visible par l’utilisateur) soit investir dans ARC et espérer que les récepteurs vous fassent confiance.
Si vous utilisez ARC : gérez les clés, faites des rotations sûres, surveillez la validation. Traitez cela comme l’opération des certificats TLS : ennuyeux, programmé, documenté.
Minimisez les modifications de toute façon. Chaque transformation est un ticket de loterie pour casser DKIM.
Fournissez des instructions utilisateurs. Pour les domaines stricts, expliquez que l’abonnement direct ou la mise en liste blanche peut être nécessaire.

Plan C: You’re a corporate IT team and people want mail forwarded to personal accounts

Ne le faites pas par défaut. Le transfert est de l’exfiltration + un risque de délivrabilité déguisé en commodité.
Offrez des alternatives supportées. Gestion d’appareils mobiles, accès délégué, webmail sécurisé, ou configurations clients gérées.
Si vous devez l’autoriser : exigez MFA, appliquez SRS, et interdisez la modification des messages sur cette voie de forwarding.
Rendez-le visible. Journalisez et auditez les règles de transfert externe. Traitez-les comme des contrôles de sortie de données, parce que c’est ce que c’est.

FAQ

1) Does SRS “fix DMARC” for forwarded mail?

Non. SRS rétablit la survie de SPF pendant le transfert en réécrivant l’enveloppe sender. DMARC peut toujours échouer si DKIM se casse et que l’alignement SPF ne correspond pas au domaine From visible.

2) If DKIM passes, do I still need SRS?

Souvent oui, pour la résilience et la gestion des rebonds. DKIM peut être fragile quand les gateways modifient le mail. SRS réduit aussi le backscatter et rend votre comportement de forwarding plus conforme aux standards.

3) Why can’t the original sender just “allow” my forwarder in SPF?

Parce que SPF est un mécanisme d’autorisation publié par le domaine pour ses expéditeurs légitimes. Ajouter des forwarders tiers serait impossible opérationnellement et augmenterait la surface d’abus.

4) What about forwarding within the same provider?

Ça dépend. Certains providers implémentent un forwarding interne qui préserve le contexte d’authentification, parfois via des mécanismes propriétaires. Mais dès que vous traversez des frontières administratives et de nouvelles IPs sortantes, SPF mordra.

5) Can I re-sign DKIM at the forwarder to make DMARC pass?

Vous pouvez signer avec votre propre domaine, mais cela ne s’alignera pas avec le From original à moins que vous ne réécriviez aussi From. La re-signature peut aider les récepteurs à évaluer l’intégrité, mais n’implique pas l’alignement à elle seule.

6) Is ARC widely supported?

Supporté à divers degrés par les principaux fournisseurs de boîtes mail, mais pas de façon suffisamment cohérente pour en faire une garantie. ARC est plutôt un signal qui aide certains récepteurs parfois.

7) What’s the biggest operational risk of SRS?

La mauvaise portée. Si vous réécrivez les senders pour du courrier qui ne devrait pas l’être, vous pouvez casser le traitement des rebonds et compliquer le dépannage. Appliquez-le aux chemins de forwarding.

8) How do I know if my system is breaking DKIM?

Recherchez des transformations : disclaimers, réécriture d’URL, normalisation MIME, tags de sujet. Puis confirmez en comparant Authentication-Results à la réception vs après relais, ou en observant DKIM=fail en aval.

9) If I stop modifying mail, will forwarding always work?

Pas toujours. DKIM peut être absent, mal configuré, ou utiliser une canonicalisation fragile. Mais arrêter les modifications élimine un important mode d’échec auto-infligé et améliore significativement les chances.

10) What should I tell the business when forwarded mail from strict senders still fails?

Dites la vérité : les politiques anti-usurpation modernes considèrent le transfert comme risqué à moins que vous ne préserviez DKIM ou n’utilisiez des mitigations supportées. Proposez des alternatives au transfert pour les workflows critiques.

Prochaines étapes réalisables cette semaine

Si vous exécutez du forwarding en production, traitez-le comme n’importe quelle autre surface de fiabilité : mesurez-le, isolez-le, et arrêtez de faire des « petits changements inoffensifs » à la payload.

Choisissez un message échoué et suivez-le de bout en bout. Confirmez si SPF, DKIM ou l’alignement est la cause réelle.
Supprimez la mutation de contenu des flux transférés. Les disclaimers sur le mail d’autrui ne sont pas un gain de conformité ; ce sont une dette de délivrabilité.
Déployez SRS à la frontière de forwarding pour éviter les échecs SPF prédictibles et canaliser les comportements de rebond.
Décidez si ARC vaut le coup pour les flux qui doivent transformer le mail. Si vous pouvez éviter la transformation, faites-le.
Rédigez votre politique : quel forwarding est supporté, lequel est interdit, et que doivent faire les utilisateurs à la place.

Le transfert ne s’est pas empiré ; l’écosystème est devenu moins tolérant à l’identité ambiguë. C’est du progrès. Ça veut juste dire que la plomberie nécessite maintenant de l’ingénierie réelle.