Aller au contenu principal
CaptainDNS

Envoi depuis un alias Exchange Online : chaque domaine accepté devient un domaine d'expédition

Par CaptainDNS
Publié le 11 octobre 2026

Mis à jour le 11 octobre 2026

Schéma d'une boîte Exchange Online avec une adresse principale et deux alias sur d'autres domaines, un message sortant par l'un des alias

Jusqu'ici, un alias Exchange Online ne servait qu'à recevoir, comme le rappelle l'annonce Microsoft du 7 octobre 2026 : « Previously, aliases could only receive mail, and all outgoing messages used the primary SMTP address of the mailbox. » L'envoi depuis un alias passe en disponibilité générale : des domaines qui n'ont jamais envoyé un message peuvent désormais apparaître dans le From: de vos courriers sortants.

TL;DR
  • Exchange Online permet d'envoyer depuis n'importe quel alias (adresse proxy) d'une boîte. Le réglage vaut pour tout le tenant et met jusqu'à 60 minutes à s'appliquer.
  • Chaque domaine accepté qui porte des alias peut alors apparaître dans le From: : vérifiez SPF, DKIM et DMARC avant d'activer, ou fermez l'envoi sur ce domaine (Receive Only, SendingFromDomainDisabled).
  • Revoyez les règles de flux, de journalisation et d'hygiène. Dans Message Trace, cherchez sur l'alias.

Contrôlez le DMARC de chaque domaine d'alias

Vérifier mon DMARCVérifier mon SPF

Ce que Microsoft change : envoyer depuis une adresse proxy

L'annonce de l'équipe Exchange précise que la fonction permet aux utilisateurs « to send emails from any alias (proxy address) associated with their mailbox, not just their primary SMTP address ». Une boîte julie@contoso.com qui porte aussi julie@contoso.fr et julie@ancienne-marque.com peut écrire depuis chacune de ces adresses.

Les réponses suivent : « Replies automatically use the alias the message was sent to ». Un message reçu sur julie@contoso.fr reçoit une réponse partie de cette adresse, sans choix de l'utilisateur. C'est par là que du courrier sort par des domaines que personne n'a préparés.

En préversion publique depuis janvier 2022, la fonction passe en disponibilité générale avec cette annonce.

Elle ne concerne que les boîtes Exchange Online. En hybride, un message envoyé depuis le site local vers Exchange Online porte l'adresse de routage de l'utilisateur sur le domaine onmicrosoft.com du tenant (exemple de Microsoft : mail.contoso.onmicrosoft.com). Avec l'envoi depuis un alias activé, Exchange Online conserve cette adresse au lieu de la remplacer par l'adresse principale. Une réponse automatique d'absence peut alors partir de l'adresse de routage. Pour que les réponses automatiques n'utilisent plus cette adresse, Microsoft renvoie vers une demande d'évolution (DCR) auprès de l'équipe Outlook. Pour une boîte partagée, l'envoi depuis un alias passe uniquement par Outlook sur le web (OWA), avec « Open another mailbox », et pas par le client Outlook.

Activer : un seul réglage pour tout le tenant

L'activation se fait en PowerShell Exchange Online :

Set-OrganizationConfig -SendFromAliasEnabled $True

Le réglage existe aussi dans le centre d'administration Exchange (EAC) : Settings > Mail Flow, option « Sending from Aliases ». Microsoft prévient : « It might take up to 60 minutes for this change to take effect in your tenant. »

Une fois sur $True, tous les alias du tenant peuvent servir d'adresse d'expédition, quel que soit leur domaine. Le levier que Microsoft documente consiste à fermer l'envoi sur un domaine entier (voir plus bas). Pour des restrictions plus fines, par exemple sur un alias ou un utilisateur, l'annonce renvoie aux règles de flux de messagerie ou à une politique interne que les utilisateurs doivent suivre.

Chaque domaine qui porte des alias devient un domaine d'expédition

Faites l'inventaire des domaines acceptés du tenant : ancien nom de marque, société rachetée, déclinaisons par pays, domaines défensifs contre le typosquatting. Ils reçoivent du courrier depuis des années, sans que personne se soit demandé s'ils pouvaient en envoyer. Désormais, ils le peuvent.

Le domaine de l'alias devient celui du From: visible (5322.From), sur lequel les destinataires évaluent DMARC. La documentation DMARC de Microsoft le rappelle : DMARC passe si SPF ou DKIM réussit et s'aligne sur ce domaine, et une signature DKIM ne s'aligne que si elle utilise le domaine personnalisé.

Pour chaque domaine concerné, trois contrôles :

ContrôleCe qu'il faut voirSi ce n'est pas le cas
DKIMSignature activée pour ce domaine dans Exchange OnlineLa signature ne porte pas le nom du domaine et ne peut pas s'aligner
SPFUn SPF publié qui autorise Exchange Online (include:spf.protection.outlook.com)Le domaine n'autorise pas les serveurs qui envoient pour lui
DMARCUn enregistrement _dmarc publié, avec une adresse rua pour les rapportsAucune politique à appliquer, aucun rapport pour voir ce qui part

DKIM d'abord : une signature faite avec le domaine de l'alias est la voie fiable vers l'alignement DMARC. Le SPF ne s'aligne que si l'adresse d'enveloppe (5321.MailFrom) porte ce même domaine ; vérifiez-le sur un message de test depuis l'alias, dans le champ smtp.mailfrom de l'en-tête reçu.

Pour activer DKIM sur un domaine d'alias, suivez notre guide DKIM sur Office 365 et Google Workspace, puis vérifiez avec le DKIM Selector Finder que des sélecteurs répondent sur ce domaine.

Sans signature ni SPF alignés, DMARC échoue ; si le domaine publie p=quarantine ou p=reject, le destinataire peut mettre le message en quarantaine ou le rejeter. Chez un destinataire Microsoft 365, l'échec se lit aussi dans le verdict composite (voir compauth=fail sur Microsoft 365). Le cas le plus traître : un domaine défensif déjà en p=reject, sans DKIM ni SPF qui autorise Exchange Online. Bien protégé contre l'usurpation, il fera échouer DMARC aux messages légitimes de vos utilisateurs, qui pourront être rejetés.

Avant et après l'activation de l'envoi depuis un alias : les domaines acceptés qui recevaient seulement peuvent aussi envoyer, chacun avec ses contrôles SPF, DKIM et DMARC, sauf le domaine passé en Receive Only

Fermer l'envoi sur les domaines qui ne sont pas prêts

Pour un domaine qui doit recevoir sans jamais envoyer, Microsoft propose de passer le domaine en « Receive Only » avec le paramètre SendingFromDomainDisabled de Set-AcceptedDomain. D'après la documentation de cette cmdlet, ce paramètre à $true empêche l'envoi depuis les adresses du domaine ; la réception relève d'un paramètre distinct, SendingToDomainDisabled, que cette commande ne modifie pas :

Set-AcceptedDomain -Identity ancienne-marque.com -SendingFromDomainDisabled $true

Faites-le avant d'activer SendFromAliasEnabled, pour chaque domaine dont SPF, DKIM et DMARC ne sont pas prêts : il garde ses alias et sa réception, qui dépend de SendingToDomainDisabled, mais ne peut plus servir d'adresse d'expédition. C'est le bon réglage par défaut pour les domaines défensifs et les marques abandonnées.

Après l'activation : règles, Message Trace et rapports DMARC

Microsoft prévient : « Rules set up that do not account for aliases such as journaling or routing rules, may not work as expected. » L'annonce cite l'hygiène, la journalisation et les règles de flux de messagerie. Une règle de transport qui ajoute une mention légale aux messages de julie@contoso.com risque d'ignorer ceux de julie@contoso.fr : relisez chaque règle qui filtre sur l'expéditeur.

Dans Message Trace, d'après Microsoft, une recherche sur l'adresse principale ignore les messages envoyés depuis un alias : cherchez sur l'alias. Prévenez le support de premier niveau avant qu'un ticket « mon message n'est jamais parti » ne tourne en rond.

Les premières semaines, suivez les rapports DMARC agrégés de chaque domaine ouvert : quelles sources envoient avec lui, et DKIM s'aligne-t-il ? La surveillance DMARC de CaptainDNS les centralise. Pour un contrôle ponctuel, envoyez un message de test vers une boîte externe et passez l'en-tête reçu dans l'analyseur d'en-têtes email : cherchez dkim=pass avec header.d sur le domaine de l'alias.

Les étapes, dans l'ordre :

  1. Lister les domaines acceptés qui portent des alias ; pour chacun, ouvrir ou fermer l'envoi.
  2. Domaines fermés : SendingFromDomainDisabled à $true.
  3. Domaines ouverts : activer DKIM, puis vérifier SPF et DMARC avec le vérificateur DMARC.
  4. Activer SendFromAliasEnabled, attendre jusqu'à 60 minutes, tester chaque domaine.
  5. Revoir les règles de flux et prévenir le support pour Message Trace.

FAQ

L'envoi depuis un alias fonctionne-t-il avec une boîte partagée ?

Oui, mais seulement dans Outlook sur le web (OWA), en ouvrant la boîte partagée avec « Open another mailbox ». Le client Outlook ne le permet pas pour les boîtes partagées.

Faut-il activer DKIM séparément pour chaque domaine d'alias ?

Oui. Sans DKIM activé pour le domaine de l'alias, la signature ne porte pas le domaine du From: et ne peut pas s'aligner pour DMARC.

Comment bloquer l'envoi depuis un domaine accepté sans couper la réception ?

Microsoft propose de le passer en « Receive Only » : Set-AcceptedDomain -Identity <domaine> -SendingFromDomainDisabled $true. D'après la documentation de Set-AcceptedDomain, ce paramètre empêche l'envoi depuis les adresses du domaine ; la réception relève d'un paramètre distinct, SendingToDomainDisabled, et le domaine continue de recevoir sur ses alias.

Guides connexes

Sources

Articles similaires