Switching Email Clients When You Have Five Accounts

Five accounts is the point at which switching email clients stops being a mechanical exercise and starts being an identity problem. Two Gmail addresses, a Microsoft 365 mailbox for the day job, an IMAP domain for the side business and a leftover iCloud address is the shape most multi-account users have — and the mistake is not folders or messages, which sit on the servers and re-render fine. The mistake is replying to a client from the wrong domain on the first Monday.

This post covers the connect order that keeps identities separate, the per-account setup that has to happen before the next account is added, the day-one wrong-sender guard, the switch itself, what breaks along the way, and the rollback that works because nothing on any of the five servers was ever modified.

What actually moves — and what doesn't#

For each of the five accounts, everything that lives on the server re-appears in the new client on its own. Folders, nested folders, messages, read and unread flags, replied and flagged flags, Gmail labels, server-side filters, and vacation responders are all stored on the mail server and are the same in every client that authenticates against the account. Whether you have one mailbox or five, that half of the switch takes no work; the servers keep the data and the new client is a viewer.

What does not move is per-account state that lived inside the old client. That is the entire failure mode for multi-account switches: each account needs its own signature, its own default From identity, its own reply-to, its own set of Send-As aliases, and often its own set of client-side rules and snippets. On five accounts, five sets of that state have to be recreated in the new client before it is safe to send. Miss one and the client happily uses the last account you looked at as the default sender, which is how a personal Gmail reply lands on a Microsoft 365 client thread.

• Server-side, survives untouched: folders, messages, flags, labels, Gmail filters, Outlook.com rules, vacation autoresponder, snoozes on Gmail.
• Client-side, must be recreated per account: signature, default From identity, reply-to address, Send-As aliases, client-only rules, snippets, Send Later queues, S/MIME and PGP keys.
• Cross-account only, needs a decision: what a unified inbox actually shows, and which account a New Message defaults to when the composer opens from an empty view.

Pre-migration checklist#

Spend twenty minutes on this before you install anything. On five accounts the checklist is not optional — the wrong-sender mistake is not caused by anyone being careless, it is caused by five sets of defaults being merged into one composer with no reminder about which account is speaking.

• List every account with its role: which is the day job, which is billing, which is the side business, which is personal. Write down which people expect to hear from which address. This is the ground truth the client's defaults have to match.
• Note the protocol for each. Gmail and Microsoft 365 are OAuth (Google Sign-In or Microsoft Sign-In). IMAP domains take a host, port 993, and either the account password or an app-specific password. iCloud and Yahoo require an app-specific password even when the underlying account has a normal password.
• Export each signature as plain HTML or plain text. Client-native signatures do not travel between clients, and rebuilding a five-line HTML signature from memory in five accounts is the point at which people give up on the switch.
• Screenshot each Gmail account's Send As list (Settings → Accounts and Import → Send mail as). Aliases are server-side on the Gmail record but the new client has to be told about each one, and the addresses often get forgotten.
• Note any reply-to rules — an address you send from but want replies to land on a different mailbox. These are per-account and have to be re-entered per account in the new client.
• Note any client-side rules that only lived in the old client. Promote them to server-side rules where the provider allows (Gmail filters, Outlook.com rules) so the next switch inherits them for free.
• Pick the low-stakes window. Friday afternoon into the weekend lets the initial sync for five mailboxes finish overnight, and any wrong-sender mistake on a Saturday is much easier to correct than one on Monday morning.

The switch, step by step#

Connect the accounts in a defined order rather than in the order you happen to remember them. The order below front-loads the accounts whose identity setup is longest (Gmail with aliases) and puts the ones with the fewest surprises (plain IMAP domains) last, so any protocol-level pain happens while your attention is fresh.

1. 1

   Install the new client. Leave the old one installed and running.

   Download from the vendor's site or an official store. Do not uninstall the old client — for the next one to two weeks it is your safety net, and IMAP, Exchange and Microsoft Graph are all designed so two clients can share the same mailbox in real time.

2. 2

   Connect Gmail account #1 (the primary Gmail).

   Use the Sign in with Google flow — the OAuth consent screen names the scopes the client is asking for. Immediately open the account's settings inside the new client, paste the signature, set the default identity, add every Send As alias from the screenshot you took, and set the reply-to address if it differs.

3. 3

   Send a self-test from Gmail #1 before touching anything else.

   Compose to your own address with subject "identity check acct 1" and body "account: work.gmail". Confirm the From address, the signature, and the reply-to are all correct. This one-minute check on each account is what prevents the first-week wrong-sender email.

4. 4

   Connect Gmail account #2 the same way.

   Signature, default identity, aliases, reply-to, then a self-test with subject "identity check acct 2". Do not skip the test on the second Gmail because it looked identical to the first — the two accounts share zero client-side state and the new client will happily default both to Gmail #1's signature if you missed the paste.

5. 5

   Connect the Microsoft 365 account.

   Use the Sign in with Microsoft flow, which runs the OAuth handshake against your tenant. If your organisation uses conditional access, the sign-in may need to happen on a managed device or through a browser prompt for MFA. Set the signature and default identity, then run the self-test with subject "identity check acct 3".

6. 6

   Connect each IMAP domain with an app-specific password.

   For each remaining mailbox, enter the IMAP server (imap.yourhost.com, port 993, SSL/TLS) and the SMTP server (usually smtp.yourhost.com, port 465 or 587) with an app-specific password rather than the account password where the provider requires one — Fastmail, iCloud, Proton (via Bridge) and Yahoo all do. Repeat the signature, default identity and self-test on each.

7. 7

   Set the global default sender last.

   In the new client's global settings, set the default From identity for a New Message opened from an empty view. Pick the mailbox where a mis-send hurts least — usually the day-job address, because a personal reply going to a client is worse than a work reply going to a friend.

8. 8

   Turn on per-account colour or account label in the unified inbox.

   A unified inbox is only safe if every row shows which account it belongs to. Turn on the per-account colour bar, letter tag or account name column. Every action a five-account user takes — reply, forward, archive — starts by reading that tag.

9. 9

   Run both clients side by side for one to two weeks.

   Both apps see the same server-side mailboxes; a folder rename, an archive, or a reply in one shows up in the other within seconds. This is the ground-truth check that identities, aliases, signatures and defaults are all correct on all five accounts before you commit.

What survives, what breaks, what you have to rebuild#

The honest inventory for a five-account switch. Everything in the "Yes" rows requires no action beyond patience while the initial sync completes on each mailbox. Everything in the "No" rows is why the checklist and the ordered connect exist — each has a five-minute fix in isolation, but repeated across five accounts they compound into an afternoon.

Does a unified inbox mix up my identities?#

Only if the client's unified inbox is a merged stream with no per-row account marker. A unified inbox is a rendering choice — the underlying accounts are still separate and each message still belongs to exactly one mailbox — so the safety of the model depends entirely on two things: whether every row is tagged with its account, and whether the composer's From field is pinned to the account the thread belongs to.

When both are true, unified is safer than juggling five separate inbox windows because you can see every mailbox without switching accounts and losing your place. When either is missing, a merged stream is the fastest known way to reply from the wrong address. If the client you are evaluating hides the account on the row or lets the composer default to a global From regardless of the thread, treat that as disqualifying for a five-account setup — the mistake it enables is exactly the mistake the switch is supposed to eliminate.

The rollback plan, if the new client does not stick#

Because you kept the old client running for a week or two and nothing on any of the five servers was modified, rolling back is a two-step operation regardless of how many accounts you added. Open the old client — it re-syncs any changes the new one made across all five mailboxes — and remove each account from the new client. That is the whole rollback. No folders are destroyed, no messages are lost, no DNS records are touched, no addresses are changed. Every mailbox on every server carried on being itself throughout.

The one thing worth keeping from the failed attempt is the checklist artefacts — the signature exports, the alias list, the reply-to notes. Those hold their value for the next client you try, so the twenty minutes of pre-migration work is a one-time cost across all future switches rather than a per-switch cost.

Doing the five-account switch without downtime#

IMAP, Exchange and Microsoft Graph are all designed so multiple clients can share a mailbox in real time. Connect all five accounts to the new client over lunch, use it for real work in the afternoon, and switch back to the old client the moment anything is missing or feels wrong. Both apps talk to the same servers per account; a folder rename, a read, a reply in one shows up in the other within seconds.

In practice this means the total downtime for a five-account client switch can be zero. There is no cutover; there are only two clients running in parallel, and after a week or two of use you know which one you actually want. The old client goes when you are ready, not when a schedule says it must.

Where AI Emaily fits in a five-account switch#

We build AI Emaily, and the reason to mention it in a post about multi-account switches is narrow and load-bearing: it was designed as one client for Gmail, Microsoft 365 and plain IMAP together rather than as a Gmail app that later grew Outlook support. Connecting each account is an OAuth consent or an app-password paste; the unified inbox tags every row with the account it came from; the composer pins the From field to the account the thread belongs to rather than to a session default; and per-account signatures, default identities, aliases and reply-to are configured per mailbox on the same settings page.

Where we are not the right fit: if all five accounts are Gmail, a single-vendor Gmail-native client like Shortwave has built harder on Gmail-specific keyboard workflow than we have and would feel tighter. If your only account is Gmail and you want the smallest possible memory footprint on macOS, Mimestream is the honest recommendation. AI Emaily is a seven-day free trial on Pro or Autopilot — card taken, $0 charged if you cancel before day seven — so a real evaluation of the five-account switch with your live mailboxes costs nothing. Pricing detail is on the /pricing page.