Alias e-mail du domaine : 5 problèmes de configuration à vérifier

Vous avez configuré un alias e-mail de domaine - sales@yourcompany.com vers votre boîte de réception, support@ vers l'assistance. Tout semblait correct dans le panneau d'administration. Puis les demandes se sont taries, un client a signalé un rejet et vous avez découvert que vous répondiez depuis votre adresse personnelle depuis trois semaines.

Lorsqu'un alias de domaine pose problème, vérifiez les fautes de frappe et l'interaction entre le routage et l'authentification moderne - SPF, DKIM, DMARC -. Une ancienne règle peut entrer en conflit avec les contrôles du destinataire.

Si vous voyez 550 5.7.520, 554 5.4.14 ou des messages qui disparaissent malgré un poli 250 OK du serveur, cessez de deviner. Ce guide présente cinq erreurs de configuration courantes, leurs codes et les correctifs à examiner.

Pour comprendre d'abord l'architecture - ce qui distingue un alias d'une boîte aux lettres -, lisez alias e-mail de domaine ou boîte aux lettres avant de poursuivre.

Votre alias e-mail de domaine est-il vraiment défaillant ? Commencez ici

Ces cinq schémas sont des points de départ pour le diagnostic. Chacun présente un symptôme et un code utiles. Repérez la ligne pertinente avant de modifier le DNS, le routage ou les politiques administratives : le code oriente l'enquête, sans prouver à lui seul la cause.

Pourquoi les alias posent problème : les deux adresses d'expéditeur

Un e-mail peut comporter deux adresses d'expéditeur aux rôles différents ; leur différence ne constitue pas automatiquement une panne. L'expéditeur d'enveloppe (RFC 5321 MAIL FROM) sert au routage des avis de non-remise et représente l'identité vérifiée par SPF. L'expéditeur d'en-tête (RFC 5322 From:) est celui que le destinataire voit dans Gmail ou Outlook et le domaine avec lequel DMARC exige un alignement.

Un routage interne - de sales@ vers bob@ sur le même serveur - n'ajoute pas nécessairement un saut SMTP externe, mais ne garantit pas l'authentification. Lors d'un transfert externe, le serveur destinataire voit l'IP du serveur de transfert et peut vérifier SPF pour le domaine d'origine. Si cette IP n'est pas autorisée, SPF échoue. Avec p=reject, un échec DMARC peut provoquer un rejet ou un autre traitement selon le destinataire ; une signature DKIM valide, alignée et préservée peut néanmoins faire réussir DMARC. Rejet, quarantaine et avis de non-remise dépendent des politiques et de l'étape SMTP.

Erreur de configuration 1 : transfert externe sans SRS

Transférer un alias vers Gmail, Yahoo ou une adresse personnelle Outlook.com peut faire échouer SPF ; le résultat DMARC dépend aussi de DKIM et de son alignement. C'est un problème important sur la période 2025-2026, notamment quand les expéditeurs publient p=reject, et non une preuve que tous les transferts échouent.

Exemple : le client alice@bank.com écrit à contact@yourdomain.com. Votre serveur transfère le message vers you@gmail.com. Gmail consulte SPF pour bank.com. L'IP du serveur de transfert n'y figure pas et SPF échoue. La banque publie p=reject. Si aucune signature DKIM alignée ne passe, le destinataire peut rejeter le message. Votre serveur a peut-être déjà répondu 250 OK au saut précédent ; cela ne confirme pas la remise finale et n'exclut pas un avis de non-remise ultérieur.

Le correctif pour l'enveloppe : Sender Rewriting Scheme (SRS). SRS réécrit l'expéditeur d'enveloppe avec votre domaine avant le transfert :

Enveloppe d'origine : alice@bank.com
Après réécriture SRS : SRS0=hash=TT=bank.com=alice@yourdomain.com

Gmail vérifie alors SPF pour yourdomain.com. Si le serveur est autorisé, SPF peut réussir pour cette enveloppe réécrite. SRS s'active au niveau du serveur, par l'hébergeur ou l'administrateur. Postfix et Exim disposent de modules SRS dont il faut vérifier la configuration.

Point essentiel : SRS peut rétablir l'autorisation SPF de l'enveloppe transférée, mais pas l'alignement DMARC avec le domaine From d'origine. Une signature DKIM d'origine valide, alignée et conservée peut suffire pour l'alignement DMARC. ARC (Authenticated Received Chain) fournit des éléments que le destinataire peut évaluer après avoir validé la chaîne et accordé sa confiance au service qui la scelle ; il ne crée pas d'alignement et ne garantit pas la remise. Signer avec un autre domaine ne rétablit pas non plus l'alignement avec l'expéditeur d'origine.

Une solution plus simple : éviter le transfert vers des fournisseurs externes. Utilisez une véritable boîte IMAP sur votre domaine et consultez-la depuis un client mobile. Le transfert externe, déjà courant en 2012, demande désormais une gestion attentive de l'authentification, même s'il reste adapté à certains usages.

Erreur de configuration 2 : Microsoft 365 bloque le transfert externe

Si votre alias transfère vers l'extérieur et que l'expéditeur reçoit 550 5.7.520 Access denied, vérifiez les politiques Microsoft. L'option par défaut "Automatic - System-controlled" du filtre antispam sortant d'Exchange Online correspond au blocage du transfert externe automatique. Cette mesure vise à limiter l'exfiltration de données ; contrôlez la politique réellement appliquée à votre organisation.

Correctif dans le portail d'administration : n'autorisez le transfert qu'avec l'accord de votre organisation. Les étapes suivantes modifient la politique par défaut et peuvent affecter tous les comptes auxquels elle s'applique.

1. Ouvrez le portail Microsoft 365 Defender
2. Accédez à : Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Modifiez Anti-spam outbound policy (Default)
4. Réglez "Automatic forwarding rules" sur On - Forwarding is enabled

Pour n'autoriser le transfert que pour certains utilisateurs - une approche mieux délimitée -, créez une politique sortante ciblant ces comptes plutôt que de modifier le réglage de toute l'organisation.

Alternative PowerShell :

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Erreur de configuration 3 : la boucle de routage

Une boucle peut produire 554 5.4.14 Hop Count Exceeded. Le message passe entre deux adresses jusqu'à atteindre la limite du serveur - par exemple 15-20 sauts si celui-ci est configuré ainsi -, puis le traitement s'arrête. L'expéditeur peut recevoir un avis de non-remise et le destinataire prévu ne rien recevoir. Le seuil dépend du système.

Vérifiez si une règle oubliée dans la boîte de destination provoque la boucle :

Alias du serveur : info@ → admin@
Règle de la boîte admin@ : tout transférer vers info@ pour archivage
Résultat : boucle jusqu'au dépassement du nombre de sauts

Inspectez aussi ce qu'on oublie facilement : un répondeur d'absence vieux de deux ans ou une règle "tout archiver vers info@". Auditez les alias du serveur et les règles des clients. Dans Exchange, consultez les règles de transport du centre d'administration. Dans Google Workspace, examinez "Filtres et adresses bloquées" pour chaque compte concerné.

Correctif structurel : vérifiez quand les alias sont développés et quand les règles de boîte sont appliquées. Selon le serveur, une redirection conservant le destinataire d'origine peut déclencher à nouveau l'alias. Définissez des routes sans cycle et testez leur comportement ; les libellés "redirect" ou "deliver to" ne garantissent pas à eux seuls le résultat.

Erreur de configuration 4 : l'identité exposée par l'envoi sous alias

Un alias limité à la réception peut ne pas répondre à votre besoin d'identité. Si vous répondez à un message adressé à sales@yourcompany.com et que le destinataire voit bob.smith@yourcompany.com dans From, vous n'utilisez pas l'adresse attendue. Cette exposition peut passer inaperçue de votre côté.

Vérification dans Google Workspace :

1. Ouvrez les paramètres utilisateur → Comptes → "Envoyer des e-mails en tant que"
2. Ajoutez l'adresse de l'alias
3. Évaluez "Traiter comme un alias" selon l'usage de cette identité. Décocher l'option peut convenir à une identité distincte, mais ne garantit pas la confidentialité. Vérifiez From, Reply-To et les en-têtes d'un message test.

Vérification dans Microsoft 365 :

Dans M365, "Bob de la part de Sales" peut refléter une permission d'envoi pour le compte d'autrui. L'envoi depuis un alias est distinct des permissions "Send As" et d'envoi pour le compte d'autrui. Pour activer la fonctionnalité d'alias dans l'organisation :

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

Ce réglage concerne Exchange Online, pas Exchange sur site. Il ne supprime pas universellement la mention "de la part de" : vérifiez les permissions, le type d'adresse et la prise en charge par le client.

Erreur de configuration 5 : conflit avec une adresse catch-all

Une adresse catch-all (*@domain.com) recueille les messages sans correspondance précise. Si le système privilégie une correspondance générique avant un alias explicite, il peut envoyer les messages dans la mauvaise boîte sans erreur évidente.

Pour les tables indexées de Postfix, virtual_alias_maps recherche l'adresse exacte avant le catch-all du domaine ; ce n'est pas simplement une lecture des lignes de haut en bas. L'exemple place les alias explicites en premier pour la lisibilité :

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

La dernière position du catch-all est illustrative, pas une règle universelle d'évaluation ; dans une table PCRE, l'ordre des motifs peut compter. Avant d'appliquer cet exemple, sauvegardez la configuration et les tables existantes, testez les correspondances de destinataires et faites valider la configuration et les routes par l'administrateur autorisé avant le rechargement. Pour une table MySQL, vérifiez les requêtes et la priorité effective de la recherche d'adresse précise sur celle du domaine ; l'ordre des lignes ne suffit pas à la garantir.

Diagnostic avancé : lire les en-têtes complets

Quand un message semble disparaître sans avis de non-remise, les en-têtes d'un message arrivé dans les indésirables peuvent aider. Authentication-Results décrit les contrôles de ce destinataire. Comparez-le aux journaux et au suivi de remise : il ne retrace pas nécessairement tous les sauts.

Dans Gmail : ouvrez le message → menu à trois points → "Afficher l'original". Repérez le bloc d'authentification :

Exemple d'échec - SRS absent :

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom vaut toujours alice@bank.com. Si l'IP est celle du serveur de transfert, cet exemple indique que l'enveloppe n'a pas été réécrite avec SRS.

Exemple réussi - SRS actif et authentification alignée préservée :

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

L'enveloppe a été réécrite et SPF passe pour yourdomain.com. Ce SPF n'est pas aligné sur le From d'origine. Pour expliquer la réussite DMARC par DKIM, il faut une signature valide et alignée, non affichée dans cet extrait ; SRS seul ne l'explique pas.

Pour tester la réponse du serveur à une adresse d'alias, utilisez swaks uniquement avec autorisation sur des serveurs et domaines que vous contrôlez. Remplacez les valeurs d'exemple par vos propres adresses de test, pas celles de tiers : cette commande peut envoyer un message de test.

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK confirme l'acceptation à cette étape SMTP, pas l'existence d'une boîte ni la remise finale ; un catch-all ou une validation différée peuvent aussi l'expliquer. 550 User Unknown signifie que le serveur a rejeté l'adresse comme inconnue pendant ce test. Vérifiez les tables, les politiques et les journaux.

Prévention : simplifier le routage et réduire les sauts

Pour limiter les erreurs, supprimez si possible les schémas qui les favorisent. Ces deux principes couvrent une bonne partie des cas précédents.

Règle 1 : éviter les transferts externes inutiles. Conservez le courrier professionnel sur son domaine et consultez la boîte avec un client IMAP sur votre téléphone. Le transfert peut compliquer SPF et DMARC, faire passer les données chez des tiers et nécessiter une identité d'envoi supplémentaire. S'il est nécessaire, évaluez ces risques et configurez l'authentification.

Règle 2 : ramener les chaînes d'alias à un saut.

Chaque saut ajoute un risque de boucle, de modification d'en-tête ou d'échec d'authentification. Un seul saut est un objectif de conception utile, pas une obligation universelle.

Pour les adresses temporaires ou de campagne, envisagez l'adressage avec suffixe plus - bob+newsletter@domain.com - plutôt qu'un nouvel alias à chaque fois. Vérifiez la prise en charge et les réglages actuels chez TrekMail, Gmail et Exchange ; ils dépendent du fournisseur et de la configuration. Certains formulaires rejettent le caractère +, ce qui limite aussi son utilisation.

Pour comparer en détail alias et transfert, lisez le transfert par alias e-mail.

Quand le problème vient du modèle tarifaire

Une partie de cette complexité apparaît quand la tarification par utilisateur rend les boîtes distinctes coûteuses. Vous créez des alias pour éviter une licence supplémentaire, puis passez des heures à examiner les en-têtes SRS et les politiques PowerShell.

La comparaison historique de TrekMail présentée ici oppose un forfait de service à une facturation pour chaque boîte. L'offre Starter ($3.50/mois) sert d'exemple d'une ancienne formule proposant sales@, support@ et billing@ comme de véritables boîtes IMAP distinctes, avec leurs accès et identités. Vérifiez le tarif actuel, les limites de domaines et de boîtes et les quotas partagés du compte. Pour répondre sous chaque identité, contrôlez les permissions et les réglages du client SMTP ; des boîtes distinctes ne garantissent pas qu'aucun en-tête ne révèle une autre identité. Dans le modèle Nano avec votre propre SMTP, celui-ci sert à tous les messages sortants, réponses comprises ; les offres payantes peuvent inclure un SMTP géré selon leurs prestations.

Pour les agences, l'offre Pro ($10/mois) pour 100 domaines est également une référence à une ancienne formule. Vérifiez les conditions actuelles avant d'intégrer des clients. L'outil de migration IMAP décrit peut copier des messages depuis Gmail ou cPanel avec un accès autorisé et une compatibilité vérifiée. Contrôlez les dossiers et les décomptes, coordonnez la bascule DNS et une copie finale des nouveaux messages ; IMAP ne remplace pas une sauvegarde et ne migre pas à lui seul les contacts et les calendriers.

Pour une première configuration, créer une adresse e-mail avec votre domaine explique le processus. Consultez les tarifs TrekMail pour confirmer le forfait du compte, les limites et les modalités d'essai. L'ancienne offre prévoyait un essai de formule payante de 14 jours avec carte bancaire obligatoire ; vérifiez les conditions en vigueur avant de vous inscrire.

Conclusion

Les alias peuvent rencontrer des échecs SPF lors de transferts sans SRS, des blocages Microsoft 365, des boucles dues aux règles oubliées, des identités d'envoi mal réglées et des conflits catch-all. Les codes facilitent l'enquête, mais le correctif exige de vérifier le routage réel, les politiques et l'authentification alignée.

Si ces problèmes se répètent, la configuration n'est peut-être pas seule en cause : vous construisez peut-être des contournements d'un modèle tarifaire par utilisateur. Il faut alors examiner également l'architecture et l'offre choisie.

Pour approfondir l'architecture et le diagnostic, commencez par la configuration du transfert e-mail et ses correctifs.