Two Outlook accounts open in one browser

Two tabs, both Outlook. One is the work mailbox, one is the personal account or a second tenant belonging to a client. Refresh the first tab and it has become the second account. Sign back in and the other tab breaks instead. Repeat until something gets sent from the wrong address.

Anyone arriving from Gmail expects this to work, because Gmail holds several signed in accounts in one browser and gives each a numbered address. Outlook on the web does not work that way, and no amount of tab discipline changes it. The behaviour comes from how Microsoft handles sign in, and the practical answer is not a setting inside Outlook. It is a decision about containers.

Why the two accounts fight

Gmail multiplexes. One browser session can hold several Google accounts at once, each addressed by an index in the URL, and the server keeps them apart. Microsoft's sign in does not multiplex in the same way. The identity layer that fronts Outlook on the web maintains a session for the browser, and navigating to a second account renegotiates that session rather than adding to it.

The consequence is that the second sign in wins and the first tab is left holding a token that no longer matches. The first tab often looks fine until something forces it to talk to the server. Then it either silently reloads as the other account or drops to a sign in screen.

Three symptoms all mean the same thing:

• A tab that was open for an hour suddenly shows a different mailbox after a refresh.
• A message saying the account signed in is a personal account where a work or school account is required, or the reverse.
• An endless redirect loop between the sign in page and the mailbox, sometimes ending in a request to close the browser and start again.

None of these are bugs to work around inside the page. They are the expected result of asking one browser session to hold two identities from a provider that keeps one.

The personal and work split makes it worse

Outlook on the web is really two products at two addresses. Personal Microsoft accounts live at outlook.live.com. Work and school accounts, meaning anything provisioned through Microsoft 365, live at outlook.office.com. They share branding, a lot of interface, and the same sign in front door, which is exactly why the collision is so confusing. A personal account and a work account are not two accounts of the same type. They are two account systems that happen to meet at one sign in page.

Anyone whose two accounts are one of each will hit the mismatch messages more often, because the sign in flow has to decide which system to route to and it uses the session it already has.

Containers that actually hold two accounts

The reliable answers all involve giving each account its own cookie store. They differ in how much work they cost and how well they survive daily use.

Container	Holds both at once	Survives a restart	Setup effort	Main drawback
Private or incognito window	Yes	No	None	Signs out every time the window closes
A second browser profile	Yes	Yes	A few minutes	One Dock icon, one Cmd+Tab entry for both
A second browser application	Yes	Yes	A download	Two browsers to maintain and update
Firefox container tabs	Yes	Yes	An extension	Firefox only
A browser that isolates each app window	Yes	Yes	Varies	A new browser to learn

Private windows are a test, not a setup

Opening the second account in a private window works, immediately, with no configuration. It is the right way to confirm that a session collision is the actual problem rather than a broken password or a conditional access rule.

It is a poor daily arrangement, because the session is discarded when the window closes. That means signing in every morning, and it means going through multifactor authentication every morning, which for many tenants is the part that makes the whole thing intolerable.

Browser profiles are the standard answer

Every Chromium browser and Firefox supports profiles, and each profile has its own cookies, extensions, history and autofill. One profile per Outlook account keeps the sessions permanently apart, including the multifactor state, so the second account stays signed in between restarts.

Microsoft's own guidance for people working across tenants points here, and Edge in particular is built around the idea, with a work profile and a personal profile as the expected shape. What profiles do not fix is anything above the browser. Two profiles are still one application to macOS, so:

• Cmd+Tab lands on the browser, not on an account.
• Notification Center says the browser name, not which mailbox received the message.
• Quitting closes every profile at once.
• Links clicked in other applications open in whichever profile happened to be frontmost.

That last one matters more for Outlook than for most services, because meeting invitations, shared documents and Teams links arrive constantly and every one of them is a link that has to land in the right tenant.

A second browser is cruder and sometimes better

Keeping work in one browser application and personal in another gives each its own Dock icon, its own Cmd+Tab slot, and its own notification identity. It also gives each its own updates, its own extension set to maintain, and a permanent question about which one is the default browser, since only one application can hold that role.

For a strict two way split that rarely changes, this is a legitimate answer and it takes no setup beyond a download. For three or more tenants it stops working, because there are not enough browsers.

What breaks after a month

The setup usually survives the first week and then erodes in four predictable places.

Default browser routing. macOS sends every link to one browser. Under a two profile arrangement the link lands in the wrong tenant regularly, and the recovery is copying the URL and pasting it into the other window, which is slow enough that people stop bothering and just click through in the wrong account.

Multifactor fatigue. Any container that does not persist cookies triggers a fresh authentication. Private windows do this every session. Aggressive privacy extensions and cookie clearing tools do it unpredictably, which is worse, because the reader cannot tell whether the prompt is expected.

Teams and the rest of the suite. Outlook is rarely alone. The same session logic applies to Teams, SharePoint, OneDrive and the admin centres, so a container that isolates Outlook has to hold the whole tenant, not just the mailbox. Splitting Outlook by profile while leaving Teams in a single browser session reintroduces the collision through a different door.

Guest access. Being a guest in another tenant is not the same as having a second account there. Guest access is reached through the home account and switching directory, and it behaves differently from a native mailbox. Anyone trying to build a container for a guest identity is usually solving the wrong problem.

Check these before blaming the browser

Session collision explains most of it, but three other causes produce identical symptoms and none of them are fixed by adding a container. Ruling them out first saves rebuilding a setup that was never the problem.

A conditional access policy. Many tenants restrict sign in by device, network or compliance state. A second account that fails only from certain locations, or only outside a company network, is being refused by policy rather than by the browser. The message usually mentions the organisation or the device rather than the account, and the fix is a request to whoever administers that tenant.

Stale credentials in the Keychain. macOS stores tokens and saved passwords per user account, and a stale entry for one Microsoft address can cause the browser to re authenticate constantly or to send credentials for the wrong account. Searching the Keychain for office or microsoft shows what is stored, and removing an obviously outdated entry costs one fresh sign in.

A privacy extension clearing cookies. Content blockers and cookie cleaning extensions routinely break Microsoft's sign in flow, because that flow bounces across several domains before landing on the mailbox. A redirect loop that appears only with extensions enabled has nothing to do with holding two accounts. Testing in a private window with extensions disabled separates the two causes in under a minute.

The order to test in

Start with a private window and one account. If that fails, the problem is the account, the policy or an extension, and no container will help. If it succeeds, add the second account in a second private window. If both work simultaneously there, session collision is confirmed and the only remaining question is which persistent container to build.

Doing it in this order matters because the symptoms are shared. Someone who jumps straight to creating browser profiles, and whose real problem was a conditional access rule, ends up with two profiles that both fail and no additional information about why.

The desktop client alternative

Outlook as an installed application handles several accounts in one interface, including accounts from different tenants and, in current versions, accounts from other providers. For someone who only needs mail and calendar, this removes the browser session problem entirely, because the client holds tokens per account rather than a session per browser. Adding a second tenant is an account addition rather than a sign in negotiation, and the two mailboxes appear side by side in one sidebar with no possibility of one replacing the other.

It does not remove the problem for everything else. Teams, SharePoint, the Power Platform and the various admin portals are still web properties reached through a browser, and they still collide. A desktop mail client plus a single browser session leaves the reader back where they started for every non mail task.

This is the point where the shape of the answer becomes clear. What is needed is not a better mail client and not more profiles. It is per window session isolation, so that each tenant occupies its own window with its own cookies and its own identity in the Dock, and so a click in one window cannot leak into another. That is what an app aggregation browser is built to do, and comparing it against the profile approach on the feature list is more useful than comparing browsers on speed. If the working pattern is one tenant in the morning and another in the afternoon, saving each as a separate set of workspaces removes the manual switching entirely.

What to change first

Confirm the diagnosis in a private window today. If both accounts work there, the problem is session collision and nothing inside Outlook will fix it. Then pick a container based on how many tenants are in play: two profiles for two accounts, and for three or more, a browser that keeps each app window in its own session, such as SpaceDeck.