Alias e-mail ou boîte mail sur votre domaine : choisir

Vous avez besoin d’une nouvelle adresse : sales@, billing@, support@. Beaucoup de guides conseillent « un alias, c’est gratuit ». Cela peut convenir jusqu’au jour où les réponses partent de votre adresse personnelle, où des factures deviennent inaccessibles après un départ ou où des messages transférés sont rejetés pour des problèmes d’authentification SPF. Vous pouvez perdre des messages légitimes sans recevoir vous-même de notification de non-remise.

C’est le risque de confondre alias e-mail sur un domaine et boîte mail. Google Workspace et Microsoft 365 facturent par utilisateur, avec les $6-$30 par mois cités dans la source, ce qui encourage parfois à remplacer les boîtes mail par des alias. Les tarifs actuels dépendent de l’offre. Ces deux objets diffèrent, tant dans leur architecture que dans leur exploitation.

Ce guide fournit un cadre de décision : différences au niveau des protocoles, défaillances possibles en production et matrice par type d’adresse. Pour comprendre le mécanisme de transfert, consultez notre analyse du transfert d’e-mails : configuration, dépannage et fonctionnement. Si vous hésitez entre alias et boîte mail, commencez ici.

Quelle est la différence réelle entre un alias et une boîte mail ?

Un alias e-mail sur un domaine est une règle de routage. Lorsqu’un MTA reçoit un message pour alias@domain.com, il le dirige vers une adresse de destination, par exemple en réécrivant le destinataire de l’enveloppe. L’alias n’a ni stockage ni identifiants propres et ne constitue pas, à lui seul, une identité indépendante. Une boîte mail stocke les messages : elle peut avoir un quota, des identifiants IMAP, un dossier des messages envoyés et un historique séparés. Vous pouvez vous connecter à une boîte si le service le permet, pas à une règle d’alias.

Trois risques liés aux alias en production

Trois problèmes reviennent régulièrement : révéler l’identité principale en répondant, provoquer un échec d’authentification SPF/DMARC lors d’un transfert externe et perdre l’accès aux données à la suppression du compte destinataire. Ce ne sont pas des risques à négliger. Ils peuvent apparaître lorsqu’un alias remplace une boîte qui devrait être gérée indépendamment.

1. Révéler son identité en répondant

Vous dirigez l’alias support@ vers votre compte personnel founder@yourdomain.com. Un client écrit à support@. Vous cliquez sur Répondre.

Si « Envoyer en tant que » est mal configuré ou si le client sélectionne une autre identité, la réponse peut partir de founder@. Le client découvre votre adresse directe et peut ensuite l’utiliser plutôt que le canal de support.

Vérifiez le fonctionnement d’« Envoyer en tant que » dans le service et le client concernés :

• Google Workspace : Ajoutez et vérifiez l’adresse lorsque cela est nécessaire. Examinez « Traiter comme un alias » selon le compte et le mode d’envoi ; décocher cette option ne garantit pas, à lui seul, un Return-Path précis.
• Microsoft 365 : La source donne l’exemple PowerShell Set-OrganizationConfig -SendFromAliasEnabled $true. Vérifiez les conditions actuelles et la compatibilité du client ; certains modes affichent « De la part de » et peuvent révéler l’identité principale.
• Clients de bureau (Outlook, Thunderbird) : Configurez et contrôlez l’adresse d’expédition des réponses. Selon le client, une sélection manuelle peut être nécessaire ; une erreur peut révéler une autre identité.

Une boîte dédiée support@ facilite généralement les réponses depuis support@. Vérifiez néanmoins l’identité par défaut, les délégations et les paramètres du client. Une boîte distincte ne dispense pas de ces contrôles.

2. Le piège SPF des transferts

Une configuration courante consiste à transférer l’alias contact@yourbusiness.com vers un Gmail personnel. Le transfert externe peut compliquer l’authentification.

Les normes d’authentification, SPF (RFC 7208) et DMARC (RFC 7489), effectuent des contrôles différents : SPF vérifie l’IP par rapport au domaine de l’expéditeur d’enveloppe ; DMARC exige une réussite SPF ou DKIM alignée sur le domaine visible de l’expéditeur. Un transfert peut faire échouer le contrôle SPF d’origine.

Voici un scénario possible lorsqu’une banque écrit à votre alias, qui transfère vers Gmail :

1. Le serveur de la banque envoie à contact@yourbusiness.com.
2. Votre serveur réécrit le destinataire et transfère vers you@gmail.com.
3. Gmail reçoit la connexion depuis l’IP de votre serveur, pas celle de la banque.
4. Si l’expéditeur d’enveloppe original est conservé, le SPF de la banque n’autorise pas votre serveur et peut échouer.
5. Si la banque publie p=reject et qu’aucune authentification alignée ne réussit, Gmail peut rejeter le message selon sa politique ; une signature DKIM valide et alignée peut permettre la réussite de DMARC.

Vous ne recevrez pas nécessairement d’avertissement. Un rejet peut produire une notification à l’expéditeur d’enveloppe, sans vous être adressée. Consultez les journaux du transfert plutôt que de supposer que tous les échecs arrivent dans votre boîte.

SRS (Sender Rewriting Scheme) réécrit l’expéditeur d’enveloppe pour que le destinataire puisse vérifier SPF sur le domaine du serveur de transfert, à condition que ce serveur soit correctement autorisé. Cet exemple illustre le mécanisme ; il ne garantit ni l’acceptation ni l’alignement DMARC :

# Original envelope (bank → your alias)
MAIL FROM: <notifications@bank.com>
RCPT TO:   <contact@yourbusiness.com>

# After SRS rewrite (your server → Gmail)
MAIL FROM: <SRS0=hash=TT=bank.com=notifications@yourbusiness.com>
RCPT TO:   <you@gmail.com>

Sans SRS ou autre traitement adapté, MAIL FROM conserve notifications@bank.com, un domaine qui n’autorise généralement pas votre serveur, et SPF peut échouer chez Gmail. Vérifiez la prise en charge de SRS ou d’ARC et le traitement de DKIM. SRS seul n’aligne pas SPF sur l’expéditeur visible d’origine ; ARC ne garantit pas non plus l’acceptation. Notre guide sur la messagerie sécurisée pour les entreprises détaille la configuration de base de SPF, DKIM et DMARC.

3. La dépendance à une seule personne

Vous dirigez billing@ vers alice@. Alice gère les factures. Alice quitte l’entreprise. Vous supprimez son compte.

Sans réaffectation de la destination, billing@ peut renvoyer des erreurs et les nouvelles factures ne plus arriver. Les documents des trois dernières années présents dans la boîte d’Alice peuvent devenir inaccessibles ou être perdus, selon la rétention et les possibilités de récupération du service.

Conserver le compte d’Alice uniquement pour les factures conserve aussi ses conversations personnelles avec les RH. Cela peut compliquer la confidentialité, la rétention et la conformité. Séparez ces données et définissez une politique adaptée.

Avec une boîte dédiée billing@ et une délégation prise en charge, Alice peut travailler sans détenir seule le compte. À son départ, révoquez ses accès et vérifiez les sessions et identifiants. L’historique peut rester séparé du sien et Bob recevoir l’accès le jour même si le service le permet. Préparez et testez la passation pour réduire les interruptions et les pertes, sans les déclarer impossibles.

Matrice de décision : alias ou boîte mail ?

Privilégiez une boîte pour une adresse qui envoie des messages, change de responsable, nécessite un historique distinct ou reçoit du courrier critique ou volumineux. Un alias convient au routage simple et peu fréquent, aux adresses temporaires de suivi et aux redirections dont l’historique et les réponses sont correctement gérés dans la boîte de destination.

L’exception noreply@

noreply@ ressemble à une adresse de routage, mais un alias seul ne fournit pas d’identifiants d’envoi. Si votre application s’authentifie en SMTP, il lui faut une boîte autorisée ou des identifiants de service spécifiques, selon le fournisseur. Une boîte accessible en IMAP n’est pas toujours nécessaire. Conservez le secret dans une configuration protégée de l’application ; ne le publiez pas et ne le distribuez pas inutilement.

Attention au catch-all

Un catch-all dirigé vers une vraie boîte peut accepter du courrier destiné à des adresses inexistantes, dont des fautes de frappe, du spam et des tentatives d’énumération, selon les filtres du serveur. Si vous en avez besoin, dirigez-le vers une boîte isolée et consultez-la chaque semaine. Évitez qu’il encombre la boîte principale d’un utilisateur. Le guide de configuration d’une messagerie sur votre domaine explique comment organiser cette séparation dès le départ.

Pourquoi le secteur entretient la confusion et ce que propose TrekMail

La tarification par utilisateur peut encourager une architecture mal adaptée. Les offres Google Workspace et Microsoft 365 ont des conditions de licence différentes, notamment pour certaines boîtes partagées ; vérifiez-les avant de comparer. Économiser les $6/mois de l’exemple avec un alias peut compliquer l’identité de réponse, l’audit et l’authentification des transferts.

Modèle par licence, exemple de la source : 5 salariés + 3 boîtes fonctionnelles (support, billing, noreply) = 8 licences × $6 = $48/mois dans cette hypothèse, pas un minimum universel. Diriger support@ vers une boîte personnelle évite une licence dans ce scénario, mais ajoute la configuration d’« Envoyer en tant que » et des risques d’erreur d’identité.

TrekMail : Selon le modèle décrit dans la source, vous pouvez créer support@, billing@ et noreply@ comme boîtes séparées pour $0 supplémentaires, dans les limites de l’offre. Elles utilisent le stockage mutualisé sans ajouter de licence par utilisateur ; vérifiez les conditions actuelles.

La source annonce des offres à partir de $3.50/mois (Starter : 50 domaines, 15GB de stockage mutualisé, 100 boîtes par domaine et SMTP géré inclus). Elle décrit Nano avec 10 domaines, 5GB et jusqu’à 10 boîtes par domaine, sans carte bancaire. Ce sont les conditions de la version décrite dans la source, pas une garantie de disponibilité actuelle ; consultez les tarifs en vigueur.

Pour les agences et prestataires de services gérés, ce modèle peut faciliter la création de boîtes fonctionnelles sans chiffrer chaque utilisateur séparément. Avant d’ajouter une adresse, vérifiez les limites et le quota disponibles. Notre guide sur l’hébergement e-mail multidomaine à grande échelle décrit le fonctionnement opérationnel pour gérer de nombreux domaines clients depuis un tableau de bord.

Aide-mémoire : quand choisir chaque option

Utilisez une boîte mail si l’adresse doit :

• Permettre de lire les messages en IMAP et de les envoyer par le service compatible
• Changer de responsable lors des mouvements de personnel
• Disposer d’un dossier des messages envoyés distinct pour l’audit
• Traiter du courrier critique ou volumineux
• S’authentifier sur un serveur SMTP pour les envois transactionnels, sauf identifiants de service adaptés

Utilisez un alias si l’adresse doit :

• Diriger du courrier peu prioritaire vers une boîte existante
• Être temporaire, pour suivre un événement ou identifier un fournisseur
• Rediriger uniquement au sein du même domaine
• Ne pas nécessiter une identité de réponse ou une passation indépendantes de la boîte de destination

En résumé

Les alias routent le courrier. Les boîtes le stockent et permettent de le gérer et de l’envoyer avec une identité propre, selon le service. Ils ne sont pas interchangeables. La facturation par utilisateur peut pousser à les traiter comme tels, mais confier à un alias le rôle d’une boîte augmente le risque de rupture de continuité lors d’un départ ou de réponse depuis la mauvaise adresse.

Choisissez l’architecture selon l’importance de chaque adresse. Privilégiez les boîtes pour les fonctions critiques et les alias pour les redirections simples. Comparez les conditions du fournisseur et le coût réel de cette séparation.

Consultez les offres TrekMail : la source décrit un modèle par domaine sans frais par utilisateur et un essai gratuit de 14 jours sur les offres payantes. Vérifiez les conditions actuelles.