Le 7 octobre 2026, l’équipe Exchange a annoncé la disponibilité générale de l’envoi depuis un alias dans Exchange Online. Une personne qui reçoit déjà à contact@exemple.fr et à prenom@exemple.fr dans la même boîte peut choisir l’une ou l’autre adresse pour écrire. Auparavant, Exchange Online réécrivait normalement l’expéditeur sortant avec l’adresse SMTP principale. La nouveauté paraît simple ; son déploiement touche pourtant les usages Outlook, les règles de transport, les traces et l’authentification des domaines.
Ce guide s’adresse aux administrateurs qui doivent activer la fonction sans transformer chaque adresse secondaire en identité autonome. Il distingue ce que Microsoft annonce officiellement de ce qu’il faut vérifier sur vos propres messages, notamment Return-Path, DKIM et DMARC.
En bref : l’alias permet d’utiliser plusieurs adresses publiques dans une même boîte Exchange Online. Il ne crée ni boîte, ni délégation, ni historique séparé. Activez la fonction au niveau du tenant, puis testez chaque domaine et chaque client réellement utilisé.
1. Ce qu’est un alias SMTP dans Exchange Online
Une boîte possède une adresse SMTP principale, généralement celle utilisée par défaut pour ses réponses et son affichage. Elle peut aussi posséder des adresses secondaires, appelées alias ou proxy addresses. Un message envoyé à l’une d’elles arrive dans la même boîte. Microsoft décrit ce fonctionnement dans sa documentation de gestion des adresses de boîte.
Dans la propriété EmailAddresses / proxyAddresses, la notation Exchange distingue habituellement SMTP: en majuscules pour l’adresse principale et smtp: en minuscules pour les secondaires. Cette distinction concerne la configuration de l’objet destinataire, pas une seconde boîte cachée derrière l’alias. Pour vérifier l’état réel d’une boîte, l’administrateur peut consulter ses adresses :
Get-Mailbox -Identity prenom@exemple.fr |
Format-List PrimarySmtpAddress,EmailAddressesUn alias doit être configuré sur la boîte : taper une adresse arbitraire dans « De » ne suffit pas. Les alias utilisateur se gèrent dans le centre d’administration Microsoft 365.
Alias, plus addressing et liste de distribution
Le plus addressing (prenom+factures@exemple.fr) sert à recevoir et à trier. Le suffixe +factures ne crée pas un alias dans proxyAddresses ; Microsoft précise que l’on ne peut pas envoyer depuis une adresse plus. Utilisez-le pour classer des inscriptions ou des notifications, pas pour représenter une identité d’expéditeur. Voir Plus Addressing in Exchange Online.
Une liste de distribution a encore une autre fonction : elle redistribue les messages à ses membres. Elle n’est pas une boîte de réception commune avec son propre historique. On peut accorder une permission Send As sur certains groupes, mais cela relève de la délégation, pas de l’envoi depuis un alias attaché à la boîte personnelle. Ces objets répondent à des besoins différents malgré une adresse visible similaire.
2. Ce que la disponibilité générale change
La fonction autorise l’envoi depuis une adresse SMTP secondaire de la boîte hébergée dans Exchange Online. Les réponses à un message reçu sur un alias utilisent automatiquement cet alias, selon l’annonce Microsoft. L’utilisateur peut aussi sélectionner les alias à afficher dans les clients pris en charge. C’est utile lorsque la même personne travaille sous plusieurs domaines publics ou pendant une transition de marque.
Un alias reste lié à un seul propriétaire de boîte : ni boîte commune, ni délégation, ni historique séparé. Les noms affichés par alias et le calendrier ne sont pas promis dans cette version.
ventes@marque.fr peut être l’alias d’Alice si elle travaille seule. Pour un traitement collectif ou un historique partagé, choisissez un objet adapté.
3. Activer la fonction et préparer les adresses
L’activation se fait au niveau du tenant. Dans Exchange Online PowerShell, Microsoft publie la commande :
Set-OrganizationConfig -SendFromAliasEnabled $True
Get-OrganizationConfig | Format-List SendFromAliasEnabledL’autre chemin est le centre d’administration Exchange > Paramètres > Flux de messagerie > Turn On Sending from Aliases. Microsoft indique que la modification peut prendre jusqu’à 60 minutes. Préparez un groupe pilote et attendez la propagation avant de conclure qu’un client ne fonctionne pas. Le commutateur ouvre la capacité pour l’organisation : inventaire et communication doivent donc précéder l’activation à grande échelle.
Vérifiez ensuite les alias, leurs propriétaires et leurs domaines dans le centre Microsoft 365. Repérez les adresses techniques et les anciens domaines réservés à la réception : un alias oublié peut devenir une identité d’envoi visible.
Microsoft permet de mettre un domaine entier en Receive Only dans le centre d’administration Microsoft 365. Les paramètres SendingFromDomainDisabled et SendingToDomainDisabled de Set-AcceptedDomain permettent également de gérer les sens autorisés au niveau du domaine. Ce sont des contrôles larges : pour une restriction plus fine, l’équipe Exchange renvoie aux règles de flux de messagerie ou aux politiques internes. N’assimilez pas la liste des alias visibles dans Outlook à une politique de sécurité suffisante.
4. Expérience dans Outlook et réponses
Dans Outlook sur le Web, l’utilisateur va dans Paramètres > Courrier > Composer pour voir et choisir ses alias. Cette formulation reprend la correction publiée par l’équipe Exchange le 8 octobre ; certains textes plus anciens indiquaient « Compose & Reply ». Dans Outlook pour Windows et Mac, l’adresse se choisit dans le menu du champ De, ou se saisit manuellement. Dans Outlook mobile, on touche le champ De pour choisir une adresse disponible. Affichez le champ « De » dans l’interface si nécessaire.
Envoyez vers une boîte externe depuis chaque client utilisé, puis répondez à un message reçu sur l’alias. Microsoft indique que la réponse conserve l’alias destinataire ; testez aussi transferts, anciens brouillons et signatures. Le message reçu fait foi.
Le nom affiché ou une entrée d’autocomplétion peut masquer l’adresse SMTP effective. Microsoft prévient que le From envoyé peut changer si le client utilisait des valeurs différentes de celles de la boîte. Vérifiez les en-têtes chez le destinataire.
Boîtes partagées : une limite précise
Pour un alias porté par une boîte partagée, Microsoft annonce un support dans Outlook sur le Web uniquement lorsque le délégué ouvre cette boîte via « Open another mailbox ». L’envoi depuis un alias de boîte partagée n’est pas pris en charge dans les clients Outlook dans l’état décrit par l’annonce. Une équipe qui dépend d’Outlook de bureau doit en tenir compte avant de remplacer une adresse principale ou de promettre un flux multi-alias.
5. Quand utiliser un alias et quand préférer une boîte partagée ?
| Besoin | Alias sur une boîte personnelle | Boîte partagée |
|---|---|---|
| Plusieurs adresses publiques pour la même personne | Adapté : une boîte, plusieurs adresses « De » | Souvent superflue |
| Plusieurs collègues lisent et répondent au même courrier | Mauvais modèle : courrier dans la boîte d’une personne | Adaptée avec accès et délégation |
| Historique commun et continuité lors d’un départ | À organiser séparément ; dépend de la boîte personnelle | Historique centralisé dans la boîte commune |
| Identité d’équipe distincte de l’employé | Pas de séparation réelle | Adaptée, sous réserve des permissions |
| Plusieurs alias sur la boîte commune dans Outlook de bureau | Sans objet | Limite actuelle : envoi depuis alias non pris en charge dans Outlook |
Une boîte partagée possède son propre objet et sa propre boîte. Les utilisateurs autorisés peuvent disposer de Full Access, Send As ou Send on Behalf selon le travail attendu. Full Access permet d’ouvrir et de gérer la boîte ; il ne donne pas à lui seul le droit d’envoyer. Send As fait apparaître la boîte ou le groupe comme expéditeur. Send on Behalf montre explicitement le délégué « de la part de » cette identité. Microsoft détaille ces différences dans Manage permissions for recipients in Exchange Online.
L’alias de la boîte d’Alice n’est donc ni un Send As, ni un Send on Behalf. Alice envoie depuis sa propre boîte sous une autre adresse qui lui appartient. À l’inverse, si l’adresse support@exemple.fr appartient à une boîte partagée ou à une liste, elle n’est pas simultanément un alias de la boîte d’Alice. La réutilisation d’une identité exige une décision de migration des objets et des droits, pas seulement un changement du champ « De ».
Une liste de distribution diffuse aux membres, éventuellement avec un envoi délégué ; elle n’offre pas l’historique d’une boîte partagée. Pour le support, préférez une boîte commune ou un système de tickets ; pour une personne signant sous deux marques, un alias suffit souvent.
6. From, Return-Path, SPF, DKIM et DMARC : ce qu’il faut tester
Le champ From du message est l’identité que le destinataire voit et que DMARC prend comme référence. Le Return-Path reflète en général l’expéditeur d’enveloppe SMTP (MAIL FROM) utilisé pour les retours d’erreur. Ces adresses peuvent être différentes. Un alias visible dans From ne prouve donc pas que l’adresse d’enveloppe ait changé de la même façon.
SPF valide la source autorisée pour le domaine de MAIL FROM. DKIM signe le message avec un domaine d=. DMARC exige qu’au moins une authentification réussie, SPF ou DKIM, soit alignée avec le domaine du From. La documentation Microsoft sur DMARC distingue expressément ces identités. Ajouter un enregistrement SPF au domaine de l’alias sans connaître le MAIL FROM effectivement utilisé ne démontre pas l’alignement SPF.
Avec un alias sur un autre domaine, vérifiez que ce domaine est configuré pour l’envoi dans Microsoft 365, que son SPF couvre les véritables plateformes qui l’utilisent, que DKIM est configuré pour ce domaine, et que sa politique DMARC correspond à vos flux. Microsoft recommande une configuration DKIM propre à chaque domaine ou sous-domaine personnalisé utilisé pour envoyer. Aucun de ces contrôles ne permet d’affirmer, sans essai, que l’envoi depuis l’alias change automatiquement le domaine SPF, le Return-Path ou la signature DKIM.
La procédure fiable est concrète : envoyez un message depuis l’alias vers une boîte externe qui expose les en-têtes complets ; relevez From, Return-Path, Authentication-Results (smtp.mailfrom, header.d, header.from) et DKIM-Signature. Vérifiez les résultats SPF, DKIM et DMARC, puis répétez l’essai pour chaque domaine, chaque connecteur ou application d’envoi et, si pertinent, chaque client. Un transfert ou un relais peut encore modifier l’enveloppe ou le message après Exchange Online.
Testez le trajet de production : un message Outlook ne prédit pas nécessairement le résultat d’un CRM sur connecteur SMTP. Voir nos guides SPF, DKIM et DMARC et sécurité du transport Exchange Online.
7. Les comportements qui changent l’exploitation
Traçabilité. Une recherche Message Trace avec la seule adresse SMTP principale ne renvoie pas nécessairement les messages expédiés avec un alias. Microsoft demande de rechercher l’alias lui-même pour les envois ou réceptions correspondants. Pensez-y avant de conclure qu’un message n’est jamais sorti. Les requêtes de supervision et les tableaux de bord construits autour de la seule adresse principale devront être revus.
Règles et journaux. Des règles de flux, de routage, de sécurité ou de journalisation qui comparent une adresse littérale peuvent ne pas reconnaître les alias. À l’inverse, certaines fonctions opèrent au niveau de la boîte et ne distinguent pas ses différentes adresses. Testez les règles critiques : exceptions anti usurpation, archivage réglementaire, copies de conformité, connecteurs et signatures. Ne supposez pas qu’une règle qui vise prenom@exemple.fr couvre automatiquement contact@exemple.fr.
Hybride et local. La fonction concerne les boîtes hébergées dans Exchange Online. Des serveurs sur site peuvent réécrire l’alias. Microsoft cite aussi un cas hybride où le routage vers mail.contoso.onmicrosoft.com conserve cette adresse et peut faire apparaître une réponse d’absence depuis le domaine de routage, plutôt que le domaine public. Insérez ce cas dans les tests si le tenant conserve Exchange sur site ; le comportement d’une boîte cloud pure ne suffit pas à valider l’hybride.
Affichage et calendrier. Microsoft étudie les noms affichés par alias et le calendrier, sans les annoncer comme acquis. Validez séparément signatures et invitations.
8. Quatre scénarios où l’alias aide vraiment
Plusieurs marques, un interlocuteur. Une commerciale répond à alice@marque-a.fr et alice@marque-b.fr, tout en travaillant dans une seule boîte. L’alias simplifie l’expérience si les deux adresses lui appartiennent et si l’entreprise accepte un historique commun. Vérifiez DKIM et DMARC pour chaque domaine ; la cohérence de la signature et du nom affiché doit aussi être testée.
Changement de domaine. Pendant le passage de ancien.fr à nouveau.fr, conservez l’ancienne adresse pour recevoir et, si le métier le demande, pour certaines réponses. Définissez une date et une règle métier pour choisir l’adresse « De ». Un ancien domaine censé être en réception seule peut être bloqué à l’envoi au niveau du domaine. Le guide de migration doit préciser quand l’adresse principale change et combien de temps les alias restent actifs.
Fusion d’organisations. Après une acquisition, plusieurs domaines peuvent aboutir à une même boîte pour une personne. L’alias évite parfois des boîtes supplémentaires, mais il ne remplace ni la migration des historiques ni le traitement des adresses déjà attribuées à d’autres objets. Vérifiez les règles, l’annuaire, le routage hybride et l’authentification de chaque domaine avant de généraliser.
Plusieurs identités publiques d’un salarié. Une personne peut représenter une fonction locale et une fonction internationale. Si les messages doivent rester sous sa responsabilité individuelle, plusieurs alias sont cohérents. Si une identité doit survivre à son départ ou être partagée avec un service, choisissez une boîte commune et définissez la délégation.
Ces cas ne justifient pas l’usage d’Exchange Online comme plateforme de campagnes. L’alias change l’identité visible, pas les limites d’envoi ni la réputation. Notre article sur Microsoft 365 et l’envoi marketing traite ce choix d’architecture ; celui sur la limite TERRL rappelle le plafond collectif de destinataires externes.
9. Checklist de mise en production
- Inventorier les alias existants, leurs propriétaires, domaines et usages. Repérer ceux qui doivent rester en réception seule.
- Choisir le bon objet pour chaque adresse : alias individuel, boîte partagée, liste de distribution ou application dédiée. Valider les besoins d’historique et de délégation.
- Contrôler les domaines acceptés et leurs réglages d’envoi ; préparer SPF, DKIM et DMARC pour les domaines qui porteront un
Frompublic. - Activer
SendFromAliasEnableddans un créneau pilote ; prévoir jusqu’à 60 minutes de propagation et vérifier la valeur de configuration. - Tester les clients réellement utilisés : Outlook sur le Web, Windows, Mac et mobile. Pour une boîte partagée, vérifier spécifiquement le parcours OWA pris en charge.
- Tester les messages neufs, les réponses reçues sur l’alias, les signatures, les noms affichés et les invitations séparément.
- Lire les en-têtes externes et l’alignement DMARC pour chaque domaine et chaque chemin d’envoi. Corriger le chemin réellement en défaut.
- Revoir les règles et les traces : chercher l’alias dans Message Trace et tester transport, journalisation, sécurité et routage hybride.
- Documenter le choix de l’adresse « De », le support utilisateur et la procédure de retrait d’un alias ou d’un domaine.
Conclusion
La disponibilité générale supprime un contournement ancien : une personne peut enfin envoyer et répondre avec ses adresses secondaires dans Exchange Online. La réussite d’un déploiement dépend cependant moins du commutateur que du modèle d’identité retenu. Un alias est pratique pour plusieurs adresses d’une personne ; une boîte partagée reste le bon objet lorsque plusieurs personnes doivent posséder un flux commun.
Avant de généraliser, validez les clients, les règles et les en-têtes sur des messages externes réels. Une adresse alias dans From est une promesse visible au destinataire ; l’alignement DMARC, la traçabilité et le traitement des réponses doivent la soutenir. Un audit de messagerie Dharmail peut aider à cartographier les adresses, les domaines et les flux lorsque le tenant est ancien ou hybride.
Sources
- Microsoft Exchange Team, « Sending From Email Aliases – General Availability » (7 octobre 2026, mise à jour le 8 octobre).
- Microsoft Learn, « Add or remove email addresses for a mailbox in Exchange Online ».
- Microsoft Learn, « Plus Addressing in Exchange Online ».
- Microsoft Learn, « Manage permissions for recipients in Exchange Online ».
- Microsoft Learn, configuration de DMARC et de DKIM.