Non-Unique Emails is currently in Early Access. To learn more about Auth0 releases, review Product Release Stages.
Considerations
Email cannot be used as the primary identifier when using Non-Unique Emails. You must configure another attribute as the primary identifier, which will be used for authentication, password resets, and account management.
For more information about identifiers and attributes, read Flexible Identifiers.
Password resets
Irreversible settings
Flexible identifiers
API behavior changes
GET /api/v2/users-by-email returns all users that share the same email address.
DELETE /api/v2/connections/{id}/users is not compatible with non-unique email connections.
POST /dbconnections/change_password does not work with Non-Unique Email connections because it requires a unique email address to find the user account. Users must use flows that leverage the primary identifier to reset their passwords.
Enable Non-Unique Emails in the Auth0 Dashboard
- Go to Authentication > Database andcreate a new connection.
- Navigate to the Choose one or more attributes as user identifiers section and toggle Email Address to On, then enable the Allow non-unique email addresses toggle that appears.
- Pick either username or phone number to toggle On as well to serve as a primary identifier for login and password reset flows.
- After confirming that email will not be used as an identifier, choose Create to save the Connection.

Enable Non-Unique Emails via the Management API
POST /api/v2/connections endpoint in the Management API to create a database connection that supports Non-Unique Emails.
When creating the connection:
- Set unique: false in the
options.attributes.emailobject to allow multiple accounts with the same email address. Set identifier.active: false to ensure that the email cannot act as the primary identifier when it’s not unique. - Choose another attribute as the primary identifier and set identifier.active: true for the attribute you chose.
Example request
- All email communications (e.g., password reset links, notifications) will be delivered to the same inbox, regardless of which user initiated the action.
- This could lead to confusion for users or unintended access to email-based links if the inbox is shared.
- Shared email scenarios are appropriate for your use case.
- End-users are informed and trained accordingly.
- Your application design accounts for potential overlaps in email-based workflows.