Transfert avec SRS : configuration, SPF, DMARC et ARC

Transférer des e-mails semble simple : une redirection et c’est réglé. Pourtant, sans transfert avec SRS (Sender Rewriting Scheme), SPF peut échouer. Par exemple, bank.com écrit à une adresse transférée sur votre serveur, qui relaie depuis sa propre IP. S’il conserve bank.com comme expéditeur d’enveloppe et que cette IP n’est pas autorisée, SPF échoue. Si aucun DKIM valide et aligné ne subsiste et que le domaine publie p=reject, le destinataire peut refuser le message. Ce n’est pas toujours silencieux : le serveur qui le présente peut recevoir une erreur SMTP et générer un avis de non-remise.

Ce guide aborde l’exploitation du transfert avec SRS. Le guide complet de configuration du transfert et de ses défaillances présente l’ensemble du sujet. Ici, nous examinons l’architecture, la syntaxe, l’intégration Postfix et ARC comme complément pour transmettre un contexte d’authentification, sans garantir la réussite de DMARC ni la livraison.

Ce que fait le transfert avec SRS

SRS réécrit l’expéditeur d’enveloppe lorsque votre serveur relaie un message, en remplaçant le domaine original par un domaine que vous contrôlez. SPF peut réussir si ce domaine autorise correctement l’IP du serveur de transfert. Le From de l’en-tête, affiché par le client, reste inchangé. La réécriture ne garantit ni son alignement avec ce From ni l’acceptation du message.

Sans SRS, un message transféré peut échouer à SPF si la nouvelle IP n’est pas autorisée. SRS adapte l’identité de l’enveloppe au nouveau parcours, mais il faut vérifier DNS, DKIM, alignement DMARC et politiques du destinataire. Tous les risques d’authentification ne disparaissent pas.

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

Pour configurer SRS, distinguez ces deux champs. SPF vérifie le domaine de l’enveloppe, tandis que DMARC prend le From visible comme référence pour l’alignement.

• Expéditeur d’enveloppe (RFC 5321 MAIL FROM) : adresse de retour utilisée par les agents de transfert pour acheminer les avis de non-remise. SPF vérifie si l’IP de connexion est autorisée pour ce domaine. Elle est aussi consultable dans Return-Path parmi les en-têtes bruts.
• From de l’en-tête (RFC 5322 From) : adresse affichée par les clients. DMARC exige qu’au moins une voie valide, SPF ou DKIM, soit alignée avec son domaine. SRS laisse ce champ inchangé.

Cet exemple suppose une IP non autorisée avant SRS et correctement autorisée après :

SRS place un domaine que vous contrôlez dans l’expéditeur d’enveloppe. Son SPF doit autoriser l’envoi réel pour que la vérification réussisse. Cela n’oblige pas le destinataire à livrer. L’adresse réécrite n’apparaît généralement pas comme expéditeur dans l’interface, mais reste visible dans les en-têtes bruts.

Syntaxe SRS : le rôle des composants

L’adresse réécrite peut sembler cryptique, mais chaque composant a une fonction. La lire aide à examiner les avis de non-remise et les parcours à plusieurs sauts.

Une première réécriture SRS (SRS0) ressemble à ceci :

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

Les composants :

• Hash : code HMAC tronqué généré à partir d’un secret local ; SHA1 est un exemple d’algorithme employé dans certaines implémentations. Il permet de valider les adresses de retour SRS0 et complique leur falsification, sans supprimer tous les abus par avis de non-remise indésirables.
• Timestamp : horodatage, par exemple encodé en base32 avec une validité de 7 à 21 jours. Le format et la durée sont configurables selon l’implémentation. Refuser les adresses expirées limite certains risques de réutilisation, sans empêcher tout rejeu malveillant.
• Origin : données permettant de reconstruire l’expéditeur original lors d’un retour. Le serveur reçoit l’avis de non-remise, inverse la réécriture et l’achemine vers l’expéditeur.
• AnchorDomain : domaine que vous contrôlez. Il doit avoir un SPF autorisant le serveur et une route de réception opérationnelle pour les retours, généralement via MX ; dans certains cas, SMTP peut utiliser A ou AAAA avec un MX implicite.

Lors d’un nouveau transfert, une implémentation peut remplacer SRS0 par SRS1 :

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 aide à limiter la croissance de la partie locale, mais la limite de 64 caractères de la RFC 5321 reste à vérifier. En cas d’échec sur une chaîne à plusieurs sauts, examinez la longueur avec l’authentification, la validité, les routes et les journaux : ce n’est pas la seule cause possible.

Intégration Postfix : configurer PostSRSd

PostSRSd est une option d’intégration SRS pour Linux et Postfix. Postfix peut interroger ce service via des tables de réécriture, lui transmettre les adresses d’enveloppe et recevoir les adresses transformées. Les exemples suivants sont indicatifs : vérifiez la version, les paquets et les chemins avant de les adapter, et ne les exécutez pas sans examiner votre configuration.

Étape 1 : prérequis du domaine de réécriture

Avant de modifier les fichiers, préparez le domaine qui apparaîtra dans l’expéditeur d’enveloppe réécrit. Vérifiez :

• Enregistrements MX : le domaine doit recevoir les avis de non-remise et les réacheminer correctement vers l’expéditeur. Un MX explicite est habituel, mais SMTP permet une réception avec MX implicite via A ou AAAA dans certaines conditions. Vérifiez le parcours réel selon la RFC 5321.
• Enregistrement SPF : le destinataire compare l’IP du serveur au SPF de ce domaine. Si elle n’est pas autorisée ou si l’enregistrement comporte des erreurs, la réécriture SRS ne suffit pas à faire réussir la vérification SPF.
• Réputation : relayer du spam peut affecter le serveur et le domaine de réécriture et contribuer à leur inscription sur des listes de blocage. Ce n’est pas inévitable, et SRS ne remplace pas le filtrage.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Étape 2 : configurer PostSRSd

Selon la version et le paquet, la configuration peut se trouver dans /etc/default/postsrsd (Debian/Ubuntu) ou /etc/postsrsd/postsrsd.conf. Vérifiez les paramètres pris en charge et le fonctionnement des exclusions avant d’adapter cet exemple. L’absence de liste d’exclusion ne provoque pas systématiquement une boucle :

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

Si vous devez créer un secret, sachez que la redirection suivante écrase un fichier existant. Effectuez une sauvegarde protégée avant toute modification, planifiez la rotation et la validation des retours entre les nœuds, et conservez des permissions restrictives avec le propriétaire approprié. Adaptez le chemin et n’exécutez les commandes que dans le cadre d’un changement contrôlé et autorisé :

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Étape 3 : intégrer avec Postfix

L’intégration se configure dans /etc/postfix/main.cf. L’exemple distingue PostSRSd 2.x avec des tables de socket Unix et 1.x avec TCP ; la syntaxe, le socket et son accès depuis Postfix dépendent de l’installation. Consultez la documentation de votre version :

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

Après validation de la configuration et préparation du changement, redémarrez les services lorsque cela convient :

systemctl restart postsrsd
systemctl restart postfix

SRS ne suffit pas : le rôle d’ARC

SRS peut permettre à SPF de réussir pour le nouveau domaine, sans établir à lui seul l’alignement DMARC avec le From original. DMARC exige qu’au moins une voie valide, SPF ou DKIM, soit alignée avec ce From. Si SPF authentifie relay.yourdomain.com et non client.com, il n’est pas aligné dans cet exemple. DMARC peut alors dépendre d’un DKIM valide et aligné.

Les modifications lors du transfert peuvent invalider DKIM si elles changent les parties signées selon la canonicalisation utilisée. Les préfixes « expéditeur externe » dans l’objet, les pieds de page de désabonnement ou les changements MIME n’invalident pas systématiquement toute signature : cela dépend de ce qui est signé. Si le DKIM aligné devient invalide et que SPF n’est pas aligné non plus, DMARC échoue et le destinataire applique sa politique.

ARC, Authenticated Received Chain, défini dans la RFC 8617, transmet les résultats d’authentification réellement observés. Un destinataire qui fait confiance au signataire et à la chaîne peut les utiliser malgré un échec DMARC. ARC ne répare pas l’alignement et ne garantit pas la livraison.

Une instance ARC ajoute trois en-têtes :

• ARC-Authentication-Results : résultats des vérifications d’authentification observées par le serveur
• ARC-Message-Signature : signature de certaines parties des en-têtes et du corps au moment du scellement
• ARC-Seal : lien cryptographique reliant l’instance à la chaîne au fil des sauts

SRS adapte l’expéditeur d’enveloppe ; ARC apporte un contexte d’authentification. Ils peuvent se compléter avec des politiques strictes, sans être toujours nécessaires ni suffisants pour garantir la livraison. Si DKIM échoue et SPF n’est pas aligné, SRS seul ne fait pas réussir DMARC.

La référence normative de SPF, dont SRS traite les difficultés liées au transfert, est la RFC 7208.

Problèmes propres aux fournisseurs à connaître

Même avec SRS et ARC correctement configurés, un fournisseur peut appliquer des politiques qui bloquent le transfert indépendamment de l’authentification. Vérifiez leur portée et l’environnement concerné avant d’attribuer le problème à votre configuration.

Face à l’erreur M365 550 5.7.520, identifier la bonne politique permet de gagner du temps : elle concerne généralement le transfert sortant de l’environnement d’origine, pas une politique à modifier chez le destinataire. SRS ou ARC ne lèvent pas cette restriction. L’examen et toute modification dans Defender doivent être réalisés par des administrateurs autorisés selon la politique de sécurité.

Vérifier le transfert avec SRS

Avant la production, envoyez un test et inspectez les en-têtes bruts à destination. Un Return-Path avec SRS indique une réécriture visible pour ce message, pas une garantie de livraison. Si l’adresse originale subsiste, il peut s’agir d’une exclusion, d’un parcours qui ne consulte pas SRS ou d’un problème d’intégration ; cela ne prouve pas à lui seul que le service est arrêté.

1. Vérifier Return-Path

Envoyez un test depuis un compte externe, par exemple ProtonMail, vers l’adresse transférée. Recherchez Return-Path dans la source du message et examinez aussi les résultats d’authentification :

• Return-Path: <SRS0=...@yourdomain.com> → une réécriture SRS est visible ; le résultat d’authentification reste à vérifier
• Return-Path: <alice@protonmail.com> → aucune réécriture visible ; vérifier exclusions, parcours et service

2. Vérifier le DNS du domaine de réécriture

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Consulter les journaux Postfix

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

Recherchez les requêtes au service SRS et les adresses retournées. Une connexion refusée peut venir d’un service arrêté, d’un mauvais chemin de socket ou port, de permissions ou de règles réseau. systemctl status postsrsd aide à examiner le service sans exclure les autres causes.

4. Tester la connexion et TLS

Les problèmes SRS et de connexion peuvent produire des symptômes semblables. Ce test aide à distinguer la connectivité SMTP de la négociation TLS :

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Une expiration du délai peut venir du réseau, du port ou du filtrage, pas uniquement de TLS. Une négociation échouée exige d’examiner la réponse précise. Recherchez ces causes séparément de la réécriture SRS.

Quand arrêter le transfert et héberger des boîtes

SRS, ARC, le domaine de réécriture, les secrets, les exclusions et la réputation représentent du travail opérationnel. Cette architecture est parfois choisie pour éviter une licence par boîte. Transférer sales@ vers une boîte personnelle évite, dans un exemple, une licence de $6 par mois. Le calcul peut être pertinent pour une adresse et devenir coûteux avec dix.

Le guide des avantages et limites des alias et du transfert compare les situations adaptées à cette architecture et celles où elle ajoute des problèmes. Le guide de choix entre alias et boîte aide à définir la structure des adresses.

L’offre Pro décrite ($10 par mois) comprend 100 domaines et 50GB de stockage mutualisé. Vous pouvez héberger sales@, support@ et info@ comme vraies boîtes IMAP sans facturation par utilisateur dans les limites de la formule, et éviter ces chaînes de transfert. Vérifiez les conditions actuelles : la livraison directe ne garantit ni réception ni conservation indéfinie.

Si le transfert reste nécessaire, par exemple pour réunir plusieurs domaines vers une destination, les configurations Pro et Agency décrites prévoient SRS et les signatures OpenARC gérés côté serveur. Vérifiez leur disponibilité et les exigences actuelles ; ils ne garantissent pas la livraison. Nano avec votre propre SMTP n’accorde pas automatiquement le transfert : si votre infrastructure sortante externe prend en charge ce parcours, intégrez SRS à cet endroit et adaptez PostSRSd ou une autre solution à sa version.

Pour le parcours vers Gmail, le guide du transfert des e-mails de domaine vers Gmail détaille les défaillances possibles et les vérifications.

En bref

Le transfert avec SRS change l’expéditeur d’enveloppe pour que SPF évalue un domaine autorisant l’IP réelle. Il peut faire réussir SPF sans garantir DMARC. PostSRSd est une option pour Postfix : vérifiez le domaine et le retour des avis de non-remise, SPF, secrets, exclusions et tables compatibles dans main.cf. Évaluez ARC lorsqu’il apporte du contexte au destinataire si DKIM devient invalide et SPF n’est pas aligné.

Vérifiez les en-têtes, l’authentification et les retours après chaque changement. Si la maintenance dépasse l’économie de licences, envisagez des boîtes avec livraison directe. Consultez les formules TrekMail : les conditions Nano décrites ne nécessitent pas de carte, mais l’activation et les fonctions dépendent des prérequis et limites actuels. Pro prévoit SRS et ARC gérés dans les configurations prises en charge.