Azure Entra ID / Microsoft Graph – What email address characters are actually supported when creating users? (+, ', special characters)

1. Official list of allowed / disallowed characters

For Microsoft Entra ID user creation, the authoritative guidance is the user name (UPN) policy. When creating users, the userPrincipalName must follow the user name policies documented for Microsoft Entra ID. If a UPN contains unacceptable characters, Microsoft Graph returns Property userPrincipalName is invalid.

The documentation explicitly states that:

• The user name and email address properties can't contain accent characters.
• There is a defined set of allowed and disallowed characters for userPrincipalName (UPN) that must be followed. When disallowed characters are used, user creation fails with the Property userPrincipalName is invalid. error.

Additionally, when synchronizing from on-premises via Microsoft Entra Connect, certain characters in proxyAddresses or mail are treated as special and replaced:

• If proxyAddresses or mail contains any of the following characters before @domain.com, they are replaced with _ (underscore) in Microsoft 365:
  • space
  • ``` (accent grave)
  • (, )
  • | (pipe)
  • =
  • ?
  • /
  • %

These characters are treated as special characters in Microsoft 365 and may cause issues such as service disruption, so they are effectively disallowed in practical use for email addresses synchronized into Microsoft Entra ID / Exchange Online.

2. Plus addressing (+) support when creating users

Plus addressing is explicitly supported in Exchange Online as a recipient feature:

• Plus addressing uses <local-part>+<tag>@<domain>.
• The original email address must be valid; the +tag is arbitrary (subject to normal SMTP character rules).
• When Exchange receives mail for local-part+tag@domain, it first tries to resolve that full address; if that fails, it retries with local-part@domain.
• Plus addressing is enabled by default in Exchange Online.

However, plus addressing is designed for dynamic, disposable receive-only addresses that are extensions of an existing mailbox address. It is not intended as the primary userPrincipalName or primary SMTP address of a user object.

There is also explicit guidance that some Microsoft identity/email surfaces do not support + in email addresses:

• When inviting external B2B users, Microsoft Entra does not currently support plus symbols in email addresses. The guidance is: “To avoid delivery issues, omit the plus symbol and any characters following it up to the @ symbol.”

This means:

• + is supported by Exchange Online for plus addressing as a mail-routing feature.
• + is not universally supported in all Entra ID scenarios (for example, B2B invitations), and therefore cannot be assumed to be valid in all user-creation contexts.

3. Recommended validation strategy for applications

Given the above constraints:

• Applications should not rely solely on RFC-compliant email validation. Instead, they must align with Microsoft Entra ID / Microsoft 365 constraints.
• For userPrincipalName and primary SMTP addresses:
  • Enforce the Entra user name policies (which define allowed/disallowed characters) and reject values that would cause Property userPrincipalName is invalid.
  • Avoid accent characters in user name and email address properties.
• For synchronized or Exchange-backed addresses (mail, proxyAddresses):
  • Avoid the special characters that are replaced or treated specially in Microsoft 365 (space, `, (, ), |, =, ?, /, %) before the @.
  • Treat these characters as disallowed in application-level validation to prevent creating unusable or transformed addresses.
• For plus addressing:
  • Do not use + in the primary UPN or primary SMTP address of the user.
  • If plus addressing is needed, treat it as a mail-routing feature (aliases / subaddresses) rather than as the canonical identity value.
• For B2B / external users:
  • Follow the documented restriction that plus symbols in email addresses are not supported for invitations; strip + and everything after it up to @ when capturing invite addresses.

4. Expected behavior and treatment as a technical limitation

The behavior described is expected and is driven by Microsoft Entra ID and Exchange Online constraints:

• User creation fails with Property userPrincipalName is invalid. when the UPN violates Entra user name policies.
• Directory synchronization replaces certain special characters in proxyAddresses / mail with _, because those characters are treated as special and can cause service issues.
• Exchange Online plus addressing is implemented as a mailbox feature, not as a general-purpose identity format, and Microsoft Entra explicitly does not support + in some scenarios (such as B2B invitations).

Applications should therefore treat these constraints as hard technical limitations and design validation and UX accordingly:

• Enforce Entra UPN policies for userPrincipalName.
• Avoid the documented special characters in mail / proxyAddresses before @.
• Avoid using + in primary identity fields and avoid + entirely for B2B invite addresses.
• Assume that even RFC-valid addresses may be rejected if they violate these Microsoft 365-specific rules, and validate against those rules rather than RFC alone.

The specific error messages observed:

• Property userPrincipalName is invalid. – directly corresponds to violating the Entra user name policies.
• Filter errors like Invalid filter clause: Syntax error ... or unterminated string literal are due to OData filter syntax (unescaped ' or other characters) rather than the underlying email validity; these must be handled by properly escaping or quoting values in $filter expressions.

References:

• Troubleshoot user creation and deletion issues in Microsoft Entra ID
• Microsoft 365 email address contains an underscore character after directory synchronization
• Add and manage B2B collaboration users in the Microsoft Entra admin center
• Plus Addressing in Exchange Online