Table of Contents
Current Implementation Blocks Some but Not All Use of Reserved Aliases with Groups
SMTP email addresses are composed of an alias (otherwise called a mail nickname) and a domain. The alias is assigned to a mailbox or other mail-enabled object to allow it to receive email. User clients tend to generate aliases automatically when creating new groups. Administrative interfaces like the Microsoft 365 admin center or PowerShell allow more control over the alias given to new mail-enabled objects. And then we come to the question of reserved email aliases.
A reserved alias is a sensitive name that’s usually kept for specific purposes. Azure AD defines a set of reserved or highly-privileged aliases which it doesn’t allow for (some) mail-enabled groups. The purposes that these aliases often serve including being the contact address for an email system or web site. Obviously, you don’t want a common-or-garden group to hijack an email address which people might assume is used for a different purpose.
It is not unusual for email systems to ring-fence reserved aliases. Google Workspace does the same, explaining that “The following words can’t be used in the email addresses of groups that you create in groups.google.com:
- abuse
- admin
- administrator
- hostmaster
- majordomo
- postmaster
- root
- ssl-admin
- webmaster
Azure AD adds “secure” and “security” to the list.
Testing the Creation of Groups with Reserved Aliases
The Azure AD documentation says that an Azure AD global administrator can create groups with reserved aliases. This isn’t altogether true as it depends on the administrative interface used, which points to an inconsistency of implementation across Microsoft 365. Table 1 shows the results of some tests I did to see if I could create groups with reserved aliases.
Admin endpoint | Group Type | Creation with reserved alias possible? |
Microsoft 365 admin center | Mail-enabled security group | No |
Security group | Yes | |
Distribution list | No | |
Microsoft 365 group | Yes | |
Exchange admin center | Distribution list | No |
Mail-enabled security group | No | |
Dynamic distribution list | Yes | |
Azure AD admin center | Microsoft 365 group | Yes |
PowerShell New-AzureADGroup | Security group | Yes |
New-UnifiedGroup | Microsoft 365 group | Yes |
New-DistributionGroup | Distribution list | No |
I am a global tenant administrator, so finding five administrative endpoints where it’s possible to create a mail-enabled group with a reserved alias confirms that the documentation’s assertion that global administrators can create these groups is correct. A more exhaustive test might find more, especially in PowerShell cmdlets.
However, the problem is the five places where a global administrator couldn’t create groups with reserved aliases. Three of these are distribution lists, the others are mail-enabled security groups. That’s where the inconsistency exists. Microsoft’s documentation mentions “groups,” a term which covers a spectrum of different types of group objects and doesn’t focus on any specific kind of group. This raises the question of why are distribution lists and mail-enabled security groups treated differently?
Testing is simple. Select an administrative interface and see if you can create a group with a reserved alias (Figure 1).

When the Microsoft 365 admin center or Exchange Online admin center detect a problem creating a group with a reserved alias, it flags the error. The error text is by no means perfect. It starts off by pointing to a synchronization issue between Azure AD and Exchange Online before saying that the value for the alias is incorrect as it contains a blocked word.

Pointing to synchronization between Azure AD and Exchange Online is misleading. The two workloads use a dual-write process to make sure that the creation or update of a mail-enabled object occurs in both directories or not at all. Microsoft introduced the double-write some years ago to avoid synchronization issues between Azure AD (the directory of record for Microsoft 365) and Exchange Online (which has its own directory for mail-enabled objects). Reading the text, I assume that Exchange Online rejected the attempt to create the new group because of the reserved alias and Azure AD then declined the write.
PowerShell Inconsistencies Too
Other administrative interfaces give different errors. For instance, here we create a new security group with Azure AD PowerShell. Azure AD accepts the reserved alias because this group is not mail-enabled. If we try to mail-enable the group, we get an error.
New-AzureADGroup -Description "Abuse Group" -DisplayName "Abuse Group" -MailNickName Abuse -MailEnabled $False -SecurityEnabled $True ObjectId DisplayName Description -------- ----------- ----------- d347eec5-62f1-4436-af41-e53fa18090be Abuse Group Abuse Group Set-AzureADGroup -ObjectId d347eec5-62f1-4436-af41-e53fa18090be -MailEnabled $True Set-AzureADGroup : Error occurred while executing SetGroup Code: Request_BadRequest Message: The service does not currently support writes of mail-enabled groups. Please ensure that the mail-enablement property is unset and the security-enablement property is set.
The Exchange Online cmdlets to work with Microsoft 365 groups are happy to accept reserved aliases:
New-UnifiedGroup -DisplayName "Majordomo Group" -Alias Majordomo -Members Tony.Redmond@office365itpros.com -Owner Tony.Redmond@office365itpros.com Set-UnifiedGroup -Identity Majordomo -PrimarySmtpAddress Majordomo@office365itpros.com Get-UnifiedGroup -Identity Majordomo | fl EmailAddresses EmailAddresses : {SPO:SPO_720c5dd5-e387-4c93-836d-899466759f64@SPO_b662313f-14fc-43a2-9a7a-d2e27f4f3478, smtp:majordomo@office365itpros.onmicrosoft.com, SMTP:majordomo@office365itpros.com}
But the Exchange Online cmdlets for distribution lists are not so content to assign reserved aliases:
New-DistributionGroup -DisplayName "Secure" -Alias "Secure" -PrimarySmtpAddress Secure@Office365itpros.com -Name "Secure Group" An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message: The value specified for property Alias is incorrect. Reason: ContainsBlockedWord RequestId : 514d14b4-cc5f-4581-b97a-9930dff98542 The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information. + CategoryInfo : NotSpecified: (:) [New-DistributionGroup], UnableToWriteToAadException + FullyQualifiedErrorId : [Server=DB9PR04MB8445,RequestId=9f8a149c-dc90-4196-9274-7625148d6280,TimeStamp=25/08/202 1 12:05:53] [FailureCategory=Cmdlet-UnableToWriteToAadException] AEC31773,Microsoft.Exchange.Management.RecipientTasks.NewDistributionGroup + PSComputerName : outlook.office365.com
Moving along, we can assign a reserved alias to a dynamic distribution list.
Get-DynamicDistributionGroup "Secure DDL" | fl primarysmtpaddress PrimarySmtpAddress : Secure@office365itpros.com
The Need for Consistency
One way of looking at this is to say that so many ways exist to create new mail-enabled groups within Microsoft 365 that it’s inevitable that some inconsistencies will creep in. However, the current situation shows all the signs of poor attention to detail. Global administrators usually know what they’re doing when they create groups. Users can create distribution lists and Microsoft 365 groups/teams (if allowed by policy), so user-driven creation is where an absolute block should exist on reserved aliases.
It would be nice if Microsoft either lived up to its assertion that global administrators aren’t subject to the block on using reserved aliases or documented exactly where they can and cannot create groups with reserved aliases. Knowing what to expect and where to do it is so much better than probing holes in documentation.
Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.
Tony,
Thank you for the article. This was driving me crazy with the inconsistency . Nice to at least have a list of what does and does not work for an admin. You are spot on with the request to MS for either consistency or documenting their intention and practice with reserved group aliases.