Bypassing or turning off "Reserved Aliases" when creating groups

MCob 11 Reputation points
2021-08-25T04:35:19.327+00:00

I'm unable to create groups with aliases such as abuse@keyman or postmaster@keyman . According to this document, "Groups with the following highly privileged email aliases can only be created by an Azure AD global administrator." However, I still get an error message "Email address is not available" when I try with a global admin account. Is there a way to disable this restriction completely?

Microsoft Exchange Online Management
Microsoft Exchange Online Management
Microsoft Exchange Online: A Microsoft email and calendaring hosted service.Management: The act or process of organizing, handling, directing or controlling something.
4,194 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,582 questions
0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vasil Michev 95,666 Reputation points MVP
    2021-08-25T05:56:54.277+00:00

    I seem to be able to repro this when using the Exchange cmdlets to create mail-enabled security group. Ignoring naming policy switch doesn't seem to help, so let me ask around.

    0 comments
  2. Siva-kumar-selvaraj 15,551 Reputation points
    2021-08-31T12:45:46.933+00:00

    Hello @MCob ,

    Thanks for reaching out.

    Unfortunately, no we can't disable default Reserved aliases however these highly privileged email aliases can only be created by an Azure AD global administrator.

    Are you facing issue with Azure as well on Office 365 admin portal ? also wondering are you getting unauthorize error when you try form Azure AD module New-UnifiedGroup and O365 module New-UnifiedGroup ? try sharing ReguestID and TimeStamp as shown below which would help me getting more insight on this issue. Thanks.

    127809-image.png

    ------
    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

  3. MCob 11 Reputation points
    2021-09-03T14:46:19.753+00:00

    Thanks for the reply, @sikumars-msft. I had already contacted Office 365 support, and they escalated the ticket internally a few times over almost 3 weeks now. In the end, the answer was (paraphrasing) "Sorry, that's how it is now." I asked why the change was made, or even when, and why there's no documentation anywhere (atypical for a system-wide modification like this) -- they said there is internal documentation on the change, but not released to the public.

    They also informed me of a workaround: create the group with a different name/alias/email. Then use PowerShell to add the email with the blocked word as an additional SMTP handler to the group. It's more work, but it completely bypasses the restriction. Then why have this obscure restriction at all?

    0 comments
  4. John 1 Reputation point
    2021-09-23T03:08:59.153+00:00

    Sorry but this kind of indifference in the product doesn't make any sense.

    We can create the alias on one object class but not another?

    We don't need to create M365 Groups for everything.
    We don't need to create Security Groups just to have an email address that isn't going to be used anywhere.

    It's a rather ridiculous enforcement policy to be honest - and as stated above , the errors and lack of documentation aren't just frustrating, it's unnecessary.

    https://office365itpros.com/2021/08/30/nconsistency-dealing-with-reserved-email-aliases-in-microsoft-365/

    Is the only complete list I can find and for Microsoft to introduce what is effective a breaking change without communicating with the community - at least, nothing I've seen - is also short sighted.

    https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/configure-external-postmaster-address
    This is the only documentation that I can find on configuring a postmaster address and to be frank, it's only use is for sending NDRs.

    The default behavior of adding an EMAIL DOMAIN should be to configure this option and allow it to be overwritten by other methods.

    By putting in this breaking change, I now cannot modify distribution lists that were created with postmaster/abuse@keyman .

    It should also be noted that executing: 

    Get-AzureADDirectorySetting | Select -ExpandProperty Values

    Returns the following: 

    PS C:\Windows\system32> Get-AzureADDirectorySetting | Select -ExpandProperty Values  
  
Name                          Value  
----                          -----  
EnableMIPLabels               false  
CustomBlockedWordsList  
EnableMSStandardBlockedWords  false  
ClassificationDescriptions  
DefaultClassification  
PrefixSuffixNamingRequirement  
AllowGuestsToBeGroupOwner     false  
AllowGuestsToAccessGroups     true  
GuestUsageGuidelinesUrl  
GroupCreationAllowedGroupId  
AllowToAddGuests              true  
UsageGuidelinesUrl  
ClassificationList  
EnableGroupCreation           false

    Notice that EnableMSStandardBlockedWords is set to False and you still can't use abuse/postmaster etc?