Transférer les e-mails de votre domaine vers Gmail

Vous configurez contact@yourdomain.com pour transférer les e-mails de votre domaine vers Gmail. Un client envoie un contrat, une banque une alerte de sécurité. Aucun message n’apparaît.

Vous vérifiez les indésirables : rien. Dans ce scénario, vous ne voyez ni trace ni avertissement, même si l’expéditeur a pu recevoir une notification de son côté.

Il peut s’agir d’un problème d’authentification, pas d’un caprice de Gmail. Quand vous transférez les e-mails de votre domaine vers Gmail, votre serveur retransmet depuis son IP un message d’un autre domaine. Si l’expéditeur d’enveloppe original est conservé et que son SPF n’autorise pas cette IP, SPF échoue. Avec une politique DMARC stricte (p=reject) et sans signature DKIM valide et alignée, Gmail peut rejeter le message avec un code comme 550-5.7.26. Un rejet SMTP peut produire un avis de non-remise à l’expéditeur ; il n’implique pas une suppression silencieuse sans notification pour quiconque.

SRS (Sender Rewriting Scheme) réécrit l’expéditeur d’enveloppe et ARC (Authenticated Received Chain) conserve des résultats d’authentification signés. Ces mécanismes peuvent aider au transfert, sans garantir la remise ni être tous deux indispensables dans chaque cas : une signature DKIM valide et alignée préservée peut permettre la réussite de DMARC.

Ce guide traite de SRS, de la prévention des boucles et d’« Envoyer en tant que » dans Gmail. Pour comprendre les interactions de SPF, DKIM et DMARC et le fonctionnement de SRS, consultez notre guide complet de configuration et de dépannage du transfert d’e-mails.

Pourquoi Gmail peut rejeter les messages transférés

Le SPF original peut échouer parce que l’IP du serveur de transfert n’est pas autorisée par le domaine de l’expéditeur d’enveloppe. SRS permet de vérifier SPF sur le domaine du serveur de transfert, s’il autorise ce serveur. Cela ne garantit pas l’alignement DMARC avec le From: original : DKIM, ARC, les filtres et les politiques du destinataire comptent aussi.

Un scénario possible lorsqu’un message de client@bank.com est transféré vers you@gmail.com :

1. bank.com remet le message à votre serveur de transfert
2. Votre serveur le transmet à Gmail
3. Gmail vérifie SPF avec l’expéditeur d’enveloppe conservé : client@bank.com
4. Le SPF de bank.com n’autorise pas l’IP de votre serveur : SPF FAIL
5. La politique DMARC est p=reject et aucune signature DKIM alignée ne réussit : Gmail peut répondre 550-5.7.26
6. Le message est rejeté ; vous pouvez ne recevoir aucun avis, même si l’expéditeur reçoit un rapport de non-remise. La conservation dépend du serveur.

DKIM peut survivre au transfert si les éléments couverts par la signature restent intacts. Évitez l’ajout de pieds de message et les changements d’objet signé. DKIM valide et aligné peut permettre la réussite de DMARC malgré l’échec SPF. Le paramètre aspf=s ne concerne que l’alignement SPF, pas DKIM. Modifier du contenu signé peut invalider DKIM, mais toute modification ne le fait pas. Vérifiez les deux mécanismes ; SRS n’est pas une correction garantie de DMARC.

Trois façons de transférer les e-mails de votre domaine vers Gmail

Les configurations ne présentent pas toutes les mêmes risques. Choisissez l’architecture adaptée à votre usage avant d’activer le transfert.

Un catch-all peut dégrader la délivrabilité. Les spammeurs essaient des adresses comme abc123@yourdomain.com et junk@yourdomain.com. Si le serveur accepte et transfère ces messages, il relaie aussi le spam. Les 90% de la source illustrent un scénario, pas un seuil de blocage Gmail. L’IP peut perdre en réputation et le courrier légitime finir dans les indésirables ; aucun délai fixe de rétablissement n’est garanti.

Pour examiner les compromis, consultez les avantages et risques du transfert d’alias. Si vous choisissez entre alias et boîte dédiée, le comparatif des alias sur un domaine et des boîtes mail détaille les critères.

SRS : pourquoi l’évaluer pour un transfert vers Gmail

SRS aide à traiter l’échec SPF du saut de transfert. Il remplace le domaine de l’expéditeur d’enveloppe, repris dans Return-Path et utilisé pour les avis de non-remise, par celui du serveur de transfert. Gmail peut vérifier SPF sur ce domaine si le serveur est autorisé. Cela ne garantit ni DMARC ni la remise et ne constitue pas une obligation universelle pour tout transfert.

Sans SRS, scénario d’échec :
Expéditeur d’enveloppe : client@bank.com
IP d’envoi : 203.0.113.10 (serveur de transfert de l’exemple)
SPF : entrée de bank.com → FAIL (203.0.113.10 n’est pas autorisée)
DMARC : FAIL sans DKIM aligné valide (p=reject) → rejet possible, pas suppression inévitable

Avec SRS, SPF corrigé dans l’exemple :
Expéditeur d’enveloppe : SRS0=HASH=TT=bank.com=client@yourdomain.com
IP d’envoi : 203.0.113.10 (serveur de transfert de l’exemple)
SPF : entrée de yourdomain.com → PASS (203.0.113.10 est autorisée)
From: de l’en-tête : client@bank.com (inchangé ; l’expéditeur visible original est conservé)

Le SPF du domaine utilisé par SRS doit autoriser l’IP ou le service d’envoi avec les mécanismes appropriés. Sans cette autorisation, la réécriture ne suffit pas : SPF peut échouer même si la nouvelle adresse appartient à votre domaine.

L’infrastructure peut aussi ajouter des en-têtes ARC (Authenticated Received Chain). ARC enregistre des résultats d’authentification dans une chaîne signée. Gmail peut les prendre en compte selon sa confiance dans le serveur de transfert et ses propres politiques. Cela exige une configuration de signature ARC valide, pas simplement une signature DKIM ordinaire. L’opérateur du serveur s’en charge ; demandez la compatibilité à votre fournisseur si vous ne l’administrez pas.

SPF est défini dans la RFC 7208. ARC, qui documente les résultats d’authentification sur plusieurs sauts, est défini dans la RFC 8617.

Prévenir les boucles : quatre vérifications avant la mise en service

Les boucles peuvent produire des erreurs comme 5.4.14 Hop count exceeded et empêcher la remise. Effectuez ces vérifications avant de passer en production.

1. Pas de routage circulaire. Vérifiez que you@gmail.com n’a pas de filtre qui renvoie le courrier vers you@yourdomain.com, puis à nouveau vers Gmail. Cette route peut boucler jusqu’à l’intervention des limites du serveur.
2. Maîtrisez les réponses d’absence. Avec une adresse fonctionnelle (team@domain.com → plusieurs comptes Gmail), examinez les réponses automatiques et la prévention des cycles. Precedence: bulk peut aider dans certains systèmes, sans remplacer une politique complète de suppression des réponses automatiques.
3. Testez depuis un compte tiers. Gmail peut dédupliquer les messages. Un test envoyé depuis le compte de destination peut rester dans les messages envoyés sans apparaître dans la réception. Utilisez un autre compte, par exemple Yahoo ou Outlook, et vérifiez aussi les journaux.
4. Vérifiez la politique sortante M365. Avec Microsoft 365, un administrateur autorisé doit examiner si la politique antispam sortante permet le transfert nécessaire. Un blocage peut produire 550 5.7.520 ; ne modifiez pas les protections sans approbation et ne supposez pas que toutes les routes suivent la même politique.

Ce sont des causes fréquentes lors d’une première configuration. Les codes seuls ne révèlent pas toujours le paramètre responsable.

Transférer les e-mails de votre domaine vers Gmail avec TrekMail

La source décrit la réécriture SRS et la signature ARC dans le MTA de TrekMail pour les messages transférés, avec le choix de la destination dans le tableau de bord. Vérifiez l’implémentation et la couverture actuelles dans la documentation ; cette automatisation ne garantit pas l’acceptation de chaque message par Gmail.

La version décrite dans la source réserve le transfert de boîtes aux offres Pro et Agency, pas à Free ou Starter. Vérifiez les conditions actuelles avant de changer d’offre. Les étapes décrites figurent dans la documentation du transfert de boîtes TrekMail :

1. Ouvrez Boîtes mail (Mailboxes) dans le tableau de bord
2. Cliquez sur Gérer (Manage) pour la boîte concernée
3. Activez Activer le transfert (Enable forwarding)
4. Saisissez l’adresse Gmail dans Transférer vers (Forward to)
5. Activez Conserver une copie (Keep a copy) pendant la configuration initiale
6. Cliquez sur Enregistrer les paramètres de transfert (Save Forwarding Settings)

« Conserver une copie » est important. Dans la configuration décrite, une copie locale est conservée en plus de la tentative de remise à Gmail, si le quota et la remise locale le permettent. Sans elle, un rejet externe peut vous laisser sans copie accessible dans la boîte. Gardez l’option active pendant les vérifications ; elle ne constitue pas une sauvegarde garantie.

La source décrit aussi des actions groupées pour sélectionner plusieurs boîtes et appliquer une destination commune, y compris sur une centaine de domaines. Vérifiez leur disponibilité et leur portée avant de les utiliser sur des domaines clients. Testez et contrôlez les résultats plutôt que de supposer que l’action réussit partout.

Compléter le circuit : « Envoyer en tant que » dans Gmail

Le transfert gère le courrier entrant, pas l’identité de réponse. Sans « Envoyer en tant que », les réponses peuvent partir de votre adresse personnelle @gmail.com plutôt que de ceo@yourdomain.com, selon le client et ses paramètres.

Configurez « Envoyer en tant que » avec des identifiants SMTP externes autorisés lorsque cela convient. Examinez le mode d’envoi et « Traiter comme un alias » pour votre cas : cette case seule ne détermine pas le serveur utilisé et ne garantit pas l’alignement DMARC. Testez From:, Return-Path et les résultats d’authentification.

Chemin indicatif dans Gmail : Paramètres → Comptes et importation → Envoyer des e-mails en tant que → Ajouter une autre adresse e-mail. Vérifiez l’effet de « Traiter comme un alias » dans la configuration actuelle au lieu de le décocher systématiquement.

Paramètres SMTP TrekMail décrits pour Starter, Pro et Agency :

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano : SMTP externe fourni par vos soins (SES, SendGrid, Mailgun, etc.), selon la source :

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Ces blocs sont des exemples : confirmez les paramètres et identifiants actuels. Gmail peut envoyer un code de vérification lors de l’ajout de l’adresse. Confirmez celle-ci et choisissez l’expéditeur par défaut si nécessaire, puis vérifiez l’identité réellement sélectionnée pour les réponses.

Vérifier le résultat : lire les en-têtes d’authentification Gmail

Après réception d’un test envoyé depuis un compte externe, examinez les en-têtes complets avant de confier du courrier important à cette configuration.

Dans Gmail : ouvrez le message → menu à trois points → Afficher l’original. Recherchez Authentication-Results.

La source propose cet exemple ; il ne démontre pas, à lui seul, l’alignement DMARC avec l’expéditeur original :

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail ou spf=fail peuvent signaler un problème SRS, une autorisation SPF manquante ou d’autres conditions d’évaluation. arc=fail peut résulter de contenu signé modifié, de clés, de signatures ou d’une chaîne invalides ; il ne désigne pas une cause unique. Vérifiez aussi From:, DKIM, DMARC et la confiance ARC. Les recommandations officielles de Google pour le transfert vers Gmail apportent des critères de contrôle du traitement de l’expéditeur d’enveloppe.

Autogestion ou service géré : le véritable compromis

Sur un Postfix autogéré, une option consiste à configurer postsrsd, protéger et gérer srs_secret, organiser sa rotation et intégrer OpenARC avec des clés de signature ARC adaptées. Surveillez aussi la réputation avec Google Postmaster Tools lorsque cela convient. Les détails dépendent de l’architecture. Mises à jour, rotations incorrectes ou nouvelles politiques peuvent exiger une enquête, même à 11 heures du soir.

La source décrit SRS et ARC gérés dans le MTA après le choix de la destination dans TrekMail. Vérifiez les conditions actuelles, les autorisations DNS et les résultats de remise ; un suivi de la configuration reste nécessaire.

Pour commencer

La source présente Nano sans carte bancaire pour connecter et tester un domaine, mais pas comme une offre incluant le transfert de boîtes. Pour cette fonction, elle annonce Pro à partir de $10/mois forfaitaires sans frais par utilisateur, dans les limites du forfait. Vérifiez la disponibilité et le tarif actuels avant de souscrire.

La version décrite dans la source propose un essai gratuit de 14 jours pour les offres payantes, avec carte bancaire, et Nano sans carte. Consultez trekmail.net/pricing pour confirmer les conditions actuelles.

Vérifiez quatre aspects : la réécriture SRS lorsque nécessaire, les résultats signés ARC, l’autorisation SPF du serveur de transfert et l’identité sortante d’« Envoyer en tant que ». Ce sont des contrôles utiles, pas une garantie de remise pendant des années. DKIM, les filtres, les politiques du destinataire et la surveillance comptent aussi ; les erreurs ne sont pas toujours silencieuses.

Configurez, vérifiez les en-têtes et assurez le suivi.