複数のGmailを切り替える: how to decide what you need

There are four or five reasonable ways to run several Gmail accounts on one Mac, and comparing them feature by feature produces a tie. That is not a failure of the comparison. It happens because the deciding facts are not properties of the tools at all. They are properties of the accounts, the employer, the timeframe, and what a bad day looks like. Five questions settle it, and answering them takes about ten minutes.

The options are not where the difficulty is

The realistic set is small. Gmail's own account switcher keeps several accounts signed in and moves between them. Separate browser profiles give each account its own cookie store. A desktop mail client holds several accounts in one list. Forwarding consolidates delivery into a single inbox. A browser built around app windows keeps each account in a window of its own with its own session.

All five work. All five are used daily by large numbers of people. Which is why reading five feature lists side by side leaves the decision exactly where it started.

The questions below are ordered so that the ones eliminating the most options come first. Each is about a fact that is already true, not a preference. A preference can be argued with. A fact about who owns an account cannot, which is why starting there saves the most time.

Question one: who owns the second account

This is the question that removes options fastest, and it is the one people skip because the answer feels obvious.

An account issued by an employer or a client is not personally held. The organisation sets what may be done with the data in it, and the arrangement has to survive an offboarding process run by somebody else. That rules out anything which copies mail out of the account, which means forwarding is off the table regardless of how convenient it would be. It also rules out setups where the only copy of something lives in a personal tool.

A personally owned second account has none of those constraints. Consolidation, forwarding, mixing into one inbox: all available, and the decision moves on to comfort.

The mixed case is the common one. Two accounts owned personally and one issued by an employer. When any account in the set is issued by somebody else, the whole arrangement has to be designed as if separation is mandatory, because the issued account cannot be the exception. That single fact removes roughly half the options before anything is installed.

There is a second-order effect worth naming. Issued accounts often come with management applied to the browser or the device, and management follows the profile rather than the person. A policy that forces a particular extension, blocks a setting, or reports activity applies to whatever profile is signed in to that account, and it does not stop at the account boundary if everything shares one profile. Designing for separation here is not only about data leaving. It is also about policy arriving somewhere it was never meant to apply.

Question two: whether the second address has to send

Reading a second account and sending from it are different requirements with different constraints, and the constraints have recently changed.

Gmail supports adding other addresses as send-as addresses, with a documented ceiling: "You can send emails from up to 99 different email addresses." Each one requires confirming a link sent to that address, so the ability to send is gated on actually holding the mailbox.

The constraint that matters for a decision made now is narrower:

Important: Starting January 2027, Gmail will no longer support the "Send as" feature for third-party email addresses, such as @yahoo.com or @outlook.com. This change does not affect Google Workspace aliases or other Gmail addresses you own. Source: support.google.com

So the answer to this question splits three ways. If the second address is another Gmail address or a Google Workspace alias, send-as keeps working and one account can front all of them. If the second address is at Yahoo, Outlook or a similar provider, sending from it inside Gmail has a stated end date, and any design built on it now is a design with a rebuild scheduled. If the second address only ever needs to be read, none of this applies.

Answering honestly matters here. "Might need to send from it occasionally" behaves like yes, because the occasional case always arrives at the worst moment.

One further detail belongs to this question rather than to the next. Sending and receiving can be split across different tools without anything breaking, and that is often the cheapest answer. Reading a second account in a mail client while sending from it inside Gmail is a perfectly stable arrangement, provided the person using it knows which half lives where. It stops being stable when the split is accidental, which is the usual case.

Question three: where a link from outside has to land

Mail clients, chat apps, calendar reminders and PDFs all produce links, and every one of them hands the link to whatever the operating system considers the default browser. What happens next is entirely determined by the option chosen.

With a single browser holding several signed-in accounts, links open in whichever account is currently default, which Google documents as usually the first one signed in. With separate profiles, links open in the last used profile, which is effectively random from the reader's point of view. With per-app windows, the target is fixed by configuration rather than by recency.

The decisive question is whether landing in the wrong account is merely annoying or actually a problem. Opening a personal document in a work session costs a few seconds. Opening a client document in a personal session, on a machine where the client's security policy applies, is a different category of event. If any account in the set belongs to somebody else, link routing stops being an ergonomics question and becomes a constraint, and the options that cannot fix a link's destination drop out. How that destination is pinned per service is described in Features.

Question four: how long it has to last, and what breaks it

Two things get decided together here, because both are about time.

A second account needed for three months is not the same problem as one needed indefinitely. Short lived arrangements should cost nothing to unwind: a profile that gets deleted, a client account removed from a list. Anything requiring migration on the way out is the wrong shape for a temporary need. Long lived arrangements can justify setup effort, because the effort amortises.

The related fact is that Gmail's own consolidation routes now carry dates. The POP based "Check mail from other accounts" stops supporting new users after the first quarter of 2026 and existing users until January 2027. A published end date is a lifespan property, and it belongs in this question rather than in a feature list: a mechanism with a known end date is fine for a nine month arrangement and unsuitable for a permanent one.

A second lifespan factor is who else has to live with the arrangement. A setup used by one person can be as idiosyncratic as that person likes, because the cost of remembering how it works falls on the person who built it. A setup that a colleague will inherit, or that has to be explained during a handover, needs to be describable in three sentences. Anything requiring a diagram gets abandoned by the next person, who then rebuilds it differently and reintroduces every problem it was designed to remove.

Then the bad day. Work out in advance what happens when the phone holding verification codes is lost, or when an account gets locked. If every account depends on one device and one recovery path, the answer is that everything stops at once. The correction is cheap and has to be done before consolidating, not after: register a second verification method, and keep backup codes somewhere that is not the device being backed up. Options that funnel all accounts through a single sign-in make this worse and should be weighted accordingly.

Running the criteria against the options

Option	Works with issued accounts	Sending from the second address	Link destination	Unwinding cost
Gmail account switcher	Yes	Send-as, subject to the 2027 third-party change	Follows the default account	None
Separate browser profiles	Yes	Independent per profile	Follows last used profile	Low, delete the profile
Desktop mail client	Depends on policy	Per account	Not applicable, mail only	Low
Forwarding into one inbox	Usually not permitted	Requires send-as as well	Single destination	High, delivery has to be rerouted
Per-app windows with separate sessions	Yes	Independent per window	Fixed by configuration	Low, remove the window

Read down the first column before anything else. If an issued account is in the set, one row is already gone. Then read the fourth column, because link destination is where daily friction actually accumulates, and it is the column most feature comparisons omit entirely. Differences between products in the last row are set out in Compared with Shift.

What the criteria do not decide

Price is not on the list, and that is deliberate.

The monthly figures in this category sit within a few dollars of each other, and several options cost nothing at all. A difference of that size does not survive contact with a setup that fails question one or question three. Choosing on price means choosing among options that have not yet been filtered, which is how people end up paying for something that cannot hold two accounts of the same service open at once.

Familiarity is the other weak input, and it is more persuasive than price because it feels like evidence. Having used a browser for years says a great deal about habit and nothing about whether it can hold two accounts of one service open at once. The five questions are all answerable without opening anything, which is the point: they are about the situation rather than about what is already installed.

Feature counts are similarly weak as a deciding input. A long list is evidence of scope, not of fit. The five questions above each eliminate something. A feature list eliminates nothing, which is precisely why comparing them produces a tie. Common questions about how the boundaries behave in practice are collected in the FAQ.

What to change first

Answer question one for every account currently in use, and write the answers down. If any account is issued by somebody else, design for separation and stop considering consolidation. Then answer question three, because that is where the daily cost lives, and evaluate whether the option under consideration can fix a link's destination rather than following whatever was used last. SpaceDeck is built on macOS around that fixed destination.