Here is a link that describes how to use PowerShell to add an alias:

Add Additional SMTP Aliases to Office 365 Groups

Concise Instructions

Open PowerShell.

Allow Remote, Signed scripts so you can import Microsoft O365 Exchange commands. We will set this back to default when done:

Set-ExecutionPolicy RemoteSigned

Enter your credentials so you can manage the O365 environment you are working on. It will prompt you for your username and your password:

$UserCredential = Get-Credential

Create a new PowerShell session to import the Microsoft O365 Exchange commands:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $UserCredential -Authentication Basic -AllowRedirection

Import the session. You should see the standard PowerShell progress bar as the commands are imported:

Import-PSSession $Session

Now you are ready to issue your commands. First, make sure you can read the properties of the Exchange Group:

Get-UnifiedGroup -Identity | FL EmailAddresses

It should output the aliases assigned to the Outlook Group.

To add the alias, enter this command. I will use my example in the question above to show what it looks like:

Set-UnifiedGroup -Identity -EmailAddresses @{Add=""}

You can then run the Get-UnifiedGroup command and see the alias now listed in the email addresses.

Return to the default execution policy:

Set-ExecutionPolicy Default

Next Steps

At this point the group has an alias. You can email the alias internally to your O365 account. For instance, can email and it will work correctly. It will be received in your O365 Human Resources group.

However, if you attempt to send email to the alias from external, you will get a 5.4.1 access denied error. You will get this even if you are able to email (If you can't email the primary alias externally, you have another problem where the group is not set to receive external email, that can be set in the EAC.)

The problem where the alias cannot receive external email has to do with Directory Based Edge Blocking (DBEB). Essentially, before O365 performs any of its protection actions (anti-malware, anti-virus, SPAM, etc.) it performs a simple lookup into your Active Directory. It looks to see "Hey, does this user even exist here?"

For instance, if you are sending email to, DBEB looks up the directory and say, OK, that user exists, send it on. It does the same for However, the lookup fails for additional aliases assigned to O365 Groups. There is a workaround.


The workaround is disabling DBEB for the domain. This does not disable the additional layers of protection of email hygiene (anti's, spam, etc.). To do so, you need to go into the EAC of your O365 account and change the Accepted Domains from Authoritative to Internal relay.

If you have natively started in O365, this is probably set to Authoritative. If you have a hybrid (O365 and Onsite), or did a migration from Onsite to O365 it is most likely already set to Internal relay (Unless post-migration you changed it to Authoritative). This is why for some people, just adding the alias works for them. DBEB is already disabled. Again, this only disables the first check of a valid user or not and the remainder of the hygiene stack is still in place.

After this change, your O365 Groups should now receive external email to their additional aliases.

Better Ways?

Yes, there should be better ways to add aliases to O365 Groups, like going to the group, selecting aliases, and adding them. That way we aren't in the shell and EAC making things work like they should. Microsoft, make it so!

Another way may be somehow to use New-EOPMailUser to create an entry in the Directory for the alias. When I tried to create a new Contact in the EAC, it stated that the email address was already in use. So, I got it to work and haven't looked at other options. I am assuming Microsoft will get aliases added in a more admin friendly way (PLEASE?!).

Keep Calm and Cloud On!