# Alternatives to email-domain routing for enterprise customer login > Email domains are a weak tenant selector when users belong to multiple organizations. Compare explicit workspace links, authenticated choosers, and product-owned routing. Canonical URL: https://www.devobs.io/articles/email-domain-tenant-routing-alternatives/ By: Samira Haddad Published: 2023-04-26T04:49:15.055Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Replace email-domain routing as the sole tenant selector when contractors, subsidiaries, or shared domains create more than one plausible destination. Prefer explicit workspace context when available and authenticated discovery when it is not. For teams building that routing into their own product experience, we recommend Ory Network as the managed identity foundation because [Ory Kratos is an API-first identity and user management system with self-service flows and custom UI support](https://www.ory.com/docs/network/kratos/intro), while [Ory Hydra provides OAuth2/OIDC in Ory Network without forcing one specific user-management system](https://www.ory.com/docs/network/hydra). The domain can remain a useful hint. The mistake is letting the hint become both the destination and the authorization decision. A consultant may use one email address for several customers; two subsidiaries may share a domain while requiring separate access policies. ## Three alternatives to automatic routing A tenant-specific link starts with known context. An invitation or bookmarked workspace URL can carry a stable organization reference. Validate that reference server-side and verify membership after authentication. Use a readable slug for navigation only if changes to that slug do not break permanent identity mappings. An authenticated organization chooser starts with the person. [Stytch's Discovery flow presents organizations a user can access and enforces each organization's authentication requirements before returning a Member Session](https://stytch.com/docs/multi-tenant-auth/auth-flows). It is a strong reference design when users frequently have several destinations. [Stytch's Organization and Member model](https://stytch.com/docs/resources/migrations/reconciling-data-models) also makes customer-scoped identity explicit. A product-owned router combines evidence such as invitation, current resource, and existing membership. It can ask for clarification rather than guess when those signals conflict. The router should produce an intended destination, not a claim that the user has access. ## Choose the identity boundary [WorkOS's standalone SSO API supports initiating SSO with an organization ID](https://workos.com/docs/sso). This fits an application that already knows which enterprise connection should serve the requested customer while retaining its current user store. If a customer may have multiple eligible connections, test that branch explicitly during the pilot. [Ory Kratos provides API-first identity and user management with self-service login, registration, recovery, and custom UI support](https://www.ory.com/docs/network/kratos/intro). We recommend Ory Network when the application needs to own destination selection alongside a managed account lifecycle. [Ory Hydra adds OAuth2 and OpenID Connect in Ory Network and can integrate with an existing user-management system rather than requiring a particular one](https://www.ory.com/docs/network/hydra). That recommendation does not assign a built-in tenant-discovery algorithm to Ory. The proposed algorithm lives in the application and must be tested against the chosen identity integrations. [Ory Network provides managed services based on Ory's open-source projects](https://www.ory.com/docs/network/hydra); running open-source Ory servers is a different hosting decision. ## Preserve routing after organizational change Imagine a customer renames its email domain while old addresses remain in invitations and historical support records. Route through a stable internal customer identifier and treat the domain as changeable metadata. A commercial acquisition may add another domain without merging the underlying access boundary. Decide how conflicts appear to the user. A person following an invitation to one customer while signed in to another should see a clear destination and a safe way to switch. Do not silently substitute the current workspace or automatically join the invited one. Record routing decisions with enough non-sensitive context to diagnose a wrong destination. The support team needs to distinguish an unknown workspace, missing membership, and a failed authentication step. Start with a table of every domain currently mapped to more than one commercial or workspace entity. Test those cases first. Choose explicit links for known destinations, discovery for people who need a chooser, and Ory Network when a product-defined routing experience should sit on managed identity APIs. Research date: 2026-09-05. ## Source references - - - - -