Group email addresses for Teams sometimes contain “+” or “/” characters

Hi CodeNish​ 

What you are seeing is related to how Microsoft 365 generates unique mail aliases (mailNicknames) for Microsoft 365 Groups, which are automatically created when a Team is created.

When a Team is created, Microsoft Teams actually provisions a Microsoft 365 Group in the background. The email address shown in the Teams or Entra interface is derived from the Exchange Online alias (mailNickname) assigned to that group.

If multiple Teams are created with the same display name (for example example2026), Microsoft 365 must generate a unique alias for each group. When the base alias is already taken, Exchange Online resolves the conflict by automatically appending a random suffix.

Historically, this suffix was mostly alphanumeric. However, newer backend logic appears to use a base64-like random generator when resolving alias collisions. Because of that, characters such as:

/

may occasionally appear in the generated alias.

From a standards perspective this is technically valid. According to RFC 5322, characters such as + and / are allowed in the local part of an SMTP address. Exchange Online therefore accepts them as valid alias characters.

However, in practice these characters can cause issues in certain scenarios:

• + can interfere with plus addressing workflows used in some mail processing systems.
• / can cause problems when the address is interpreted in URLs, APIs, or calendar integrations.
• Some legacy tools assume group aliases are strictly alphanumeric, which is not enforced by Exchange.

This explains why the issue appears only occasionally when you create many Teams with the same name. The alias generator is simply resolving collisions and randomly selecting characters from its allowed character set.

It also aligns with your observation that the “+” case appears to have been corrected, while / can still occur. Microsoft likely adjusted part of the alias generation logic but did not fully restrict the character set used for collision resolution.

To avoid this behavior, organizations typically implement one of the following approaches.

First, ensure the Team names generate unique aliases. For example:

example2026-team1
example2026-projectA
example2026-hr

If the base alias is unique, the system does not need to generate a random suffix.

Second, create the Microsoft 365 Group first and define the alias explicitly, then enable Teams on the group. For example using PowerShell:

New-UnifiedGroup -DisplayName "example2026-team1" -Alias "example2026-team1"

This guarantees the alias remains strictly alphanumeric.

Third, many large environments implement group provisioning automation (PowerShell or Microsoft Graph) to enforce alias naming rules before the group is created.

The key takeaway is that this behavior is not specific to Teams itself. It originates from Exchange Online alias collision handling for Microsoft 365 Groups. Teams simply consumes the group object that already exists in the directory.

While the characters are technically valid under SMTP standards, restricting the automatically generated suffix to URL-safe characters would likely reduce compatibility issues across Microsoft 365 services and integrations.