Sending From Email Aliases – General Availability

Today we are announcing the General Availability (GA) of Sending from Aliases for Exchange Online. This was a highly requested feature that now empowers users to send emails from any alias (proxy address) associated with their mailbox, not just their primary SMTP address. Read on to learn how it works, how to enable it, and what’s next.

What Is Sending From Aliases?

Sending from Aliases allows Exchange Online users to send emails using any of their configured aliases or proxy (or secondary) SMTP addresses. Previously, aliases could only receive mail, and all outgoing messages used the primary SMTP address of the mailbox. Workarounds like shared mailboxes or distribution groups were used in the absence of native alias sending support.

With the Sending From Aliases feature, which until now has been in Public Preview, users can:

• Send from any alias directly using Outlook clients.
• Reply from aliases when an email was addressed to it.
• Select which aliases to display in supported clients.  

How Does It Work?

Admin Setup

• Enable at the tenant level via PowerShell:

Set-OrganizationConfig -SendFromAliasEnabled $True

• Or use the Exchange Admin Center:

Go to Settings → Mail Flow → Turn On Sending from Aliases.

• Aliases for users are managed in the M365 Admin Center.
• Admin who wishes to block a domain from being able to send can set the domain as Receive Only in the M365 Admin Center.

It might take up to 60 minutes for this change to take effect in your tenant.

User Experience

Replies automatically use the alias the message was sent to.

Aliases are given to users for various reasons. If, for whatever reason, a user should not receive or send messages using a given alias, it is possible to set the entire domain to Send-only or Receive-only. To set a domain to Send-only or Receive-only, use the SendingFromDomainDisabled or SendingToDomainDisabled parameter of Set-Accepteddomain cmdlet from Exchange Online Powershell.

More nuanced restrictions would need to be implemented with mail flow rules or organizational policies that users should follow. 

Known Gaps or Behavior Changes

There are certain features that rely on the email address used to send or receive messages. Rules set up that do not account for aliases such as journaling or routing rules, may not work as expected. Other features may work with the mailbox identity and be unable to differentiate between aliases used.   

• This feature is for Exchange Online-hosted mailboxes only. Messages to and from on-premises can be subject to rewriting the aliases on those servers.
• In Hybrid scenarios, when email is sent from on-premises to Exchange Online, email is sent to user’s mail.contoso.onmicrosoft.com address. With send-as-alias feature enabled, this address is preserved and not resolved to user’s primary address. This can cause issues like OOF response coming from user’s mail.contoso.onmicrosoft.com address instead of the email address representing user’s actual email domain name (contoso.com). Please raise a DCR with the Outlook team if your organization would like autoreply messages to avoid using mail.contoso.onmicrosoft.com addresses.
• For shared mailbox, send from alias feature works only with OWA when delegate opens it using “Open another mailbox” option. For Outlook client, send from alias feature is not supported for shared mailbox at all.
• Various types of rules in Exchange Online may look for specific email addresses and not match aliases, resulting in the rule not acting on a subset of messages from a given mailbox. Features with rules include hygiene, journaling, and mail flow rules.
• Message Trace queries using a primary SMTP address return results that do not include messages sent using an alias. To trace messages sent to or from an alias, you need to use the alias in your query. This is less of a known issue and more about highlighting the change to existing behavior.
• Some companies have set up Outlook clients with aliases or display names that differ from the user’s primary email address and display name stored on the mailbox. Different email addresses or display names may appear on messages when the feature is enabled. When the sending from aliases feature is enabled, it may cause a change in behavior for what shows up in sent messages’ From field.

Future Enhancements

While the GA release delivers the core functionality, we still plan to expand the feature set in future updates. GA is a major milestone for this important feature, and we want to show our commitment to supporting it and customers who choose to use it with this announcement.   

Additional functionality we’re investigating (but not necessarily committing to) includes:

• Display names per alias
• Additional filtering or default controls
• Calendar support

Follow up communications will announce which features we plan to work on and deliver post-GA. 

Next Steps

• Admins who have not done so already can review and enable the feature for your organization using the guidance above.
• Please raise support tickets if you uncover any issues that you discover and are not called out in the Known Gaps section. This feature was a significant shift from the previous behavior of Exchange Online and edge cases may still exist.
• Monitor for announcements on future enhancements to the feature.

 Exchange Online Team