The Unified Inbox: Every Email Account in One Place, Without Forwarding

A unified inbox is one message list showing mail from every account you have, sorted by arrival time, with each row labelled by where it came from. That's the whole idea. Most people who go looking for a unified inbox have already tried forwarding, and already found out why it doesn't work.

The mail arrives, but the sender's wrong, half of it lands in spam, and when you reply the recipient sees an address they've never written to. So the second account goes back into its own browser tab, and you check it four times a day instead.

Forwarding fails here for a structural reason, not a configuration one. Re-sending an incoming message to a different mailbox breaks the authentication chain the receiving server uses to decide whether the message is real, and no amount of tweaking fixes that. It's the wrong mechanism for the job.

The right mechanism is one client reading all the mailboxes directly. Desktop apps have always done this. A server-side unified inbox does the same thing, with the difference that your phone sees the same merged list as your laptop.

Why Forwarding Is the Wrong Tool

Forwarding re-sends your message from a server the original sender never authorised. SPF fails. DKIM often survives, but only if nothing rewrote the message in transit. If both fail, DMARC fails, and a domain publishing p=reject has just instructed the receiving server to discard your mail. That's the short version of why a forwarding-based unified inbox loses messages.

Sender Rewriting Scheme patches half of it by rewriting the envelope sender to a domain that does authorise the forwarding server. SRS is worth having and it's applied automatically, but it repairs SPF only. It does nothing for a DKIM signature broken in transit, and it can't help you reply from the right address.

That last point is the one people underestimate. Forwarding is a one-way pipe. Mail sent to you@oldcompany.com lands in your new inbox, you hit Reply, and the recipient gets a message from you@newcompany.com — an address they've never seen, quite possibly in a thread with a client who now thinks they have the wrong contact. There's no fix for this inside forwarding, because forwarding never gave you the ability to send as the old address.

Then there's storage. A forwarded copy is a second copy. It occupies quota in the destination while the original still occupies quota at the source, unless you also configured the source to delete on forward — at which point you have no backup and one misconfigured rule silently destroys mail.

Forwarding is excellent at what it was designed for: routing an address with no mailbox behind it, like invoices@ going to whoever handles invoices this quarter. It was never designed to consolidate accounts you actively use. The full picture is in aliases versus mailboxes versus forwarding and SRS and forwarded mail.

The Other Old Answer, and Why It's Being Retired

The second traditional route to a unified inbox was fetch-and-copy: your provider logs into the other account over POP3 every so often, downloads new messages, and files them locally. Gmail's Mail Fetcher works this way. So did Outlook.com's Connected Accounts.

Both are going away. Microsoft removed Connected Accounts from Outlook.com years ago, and Google has announced the retirement of Gmail's Mail Fetcher and Gmailify. The mass-market providers are exiting multi-account consolidation.

The technical reasons are the reasons we didn't build it that way either. Fetch-copy polls, so mail is late by whatever the poll interval is. It downloads into the destination, so every message is stored twice and counted against your quota twice. Because it copies rather than proxies, the two sides drift: read a message in one place and it stays unread in the other, delete it here and it survives there. And it's POP3, so folders don't come along at all.

Three Ways to Build a Unified Inbox

There are three architectures for a unified inbox and each has a signature failure mode. Forwarding re-sends and breaks authentication. Fetch-and-copy polls and duplicates. A live IMAP proxy holds an authenticated session to each account and reads on demand, which costs nothing in storage and surfaces a dead credential immediately.

TrekMail's unified inbox is the third one. Nothing is copied. When you open the merged view, the server opens IMAP sessions to each connected account, fetches the headers it needs, merges them by internal date, and caches the result briefly. Read a message and it's marked read on the source server, because there's only ever one copy — the one that was always there.

The practical consequence is that adding an account to your unified inbox changes nothing about that account. Your Gmail is still your Gmail, with its own storage, its own filters, and its own web interface if you want it. Disconnect and there's nothing to clean up.

What It Looks Like in Practice

There are two views, and the distinction matters more than it sounds. One merges everything for triage; the other scopes to a single account for focused work. Most people live in the first and switch to the second when they need to concentrate on one context.

All inboxes is the unified inbox proper: every mailbox and connected account merged into a single list, sorted by arrival time. Each row carries a badge showing where it came from — the provider's logo for a connected account, a coloured initial for a TrekMail mailbox — so you always know what you're looking at before you open it. Reply from that list and the correct sending identity is preselected.

Per-account view is the sidebar switcher. Click a connected account and the interface scopes to it: its own folder tree, its own drafts, its own Sent.

The unified inbox fans out across mailboxes in parallel rather than one after another, because a serial round trip to eight IMAP servers is a visibly slow page. If one source is unreachable — an expired app password, a provider having a bad morning — that account is skipped and the interface names it, rather than failing the whole view. One broken credential should never take out your inbox.

Sending: the Part Everyone Gets Wrong

When you reply from the unified inbox to a message that arrived at your Gmail address, the reply is submitted to Google's SMTP server, authenticated as you, and it leaves Google's infrastructure. It isn't relayed through us.

That isn't an implementation detail; it's the whole point. Gmail's SPF record authorises Google's servers. If we accepted your @gmail.com message and sent it from our own IP, SPF and DMARC would both fail, and we'd have reinvented the forwarding problem on the outbound side. Sending through the account's own provider keeps SPF and DKIM aligned with the From address, which is the only way a receiving server can confirm the message is legitimately yours.

The same rule applies to every account in the unified inbox: mail from a Fastmail address goes out through Fastmail, mail from a self-hosted server goes out through that server's SMTP. The From menu only ever lists addresses you're currently authorised to send from — the mailbox's own address, aliases with sending enabled, shared mailboxes where you have reply permission, and connected accounts. If an address isn't in that list, it's because sending from it would fail authentication, and saying so up front beats a bounce two minutes later.

App Passwords and OAuth

Plain passwords are dead for IMAP at every large provider, so every account you add to a unified inbox uses either an app password or OAuth. Which one depends on the provider, and it decides what the setup flow looks like.

An app password is a long random string granting access to one protocol, revocable on its own without changing your real password or logging you out anywhere else. It's strictly better than handing an app your actual credentials, which is why the setup wizard links you straight to the right generation page for whichever provider it detected.

Detection is automatic. Type the address and the domain is matched against a table of known providers; if it's a custom domain, the MX records are checked, which catches Google Workspace and Microsoft 365 domains that don't look like @gmail.com. You only fill in server details by hand when neither pass recognises the host.

For manual setup, IMAP is accepted on port 993 (implicit TLS) or 143 (STARTTLS), and SMTP on 465, 587 or 2525. TLS certificate validation is unconditional — a server with a self-signed or mismatched certificate is refused rather than connected with a warning. That's deliberate: an IMAP session carries your entire mail history, and a certificate you can't verify means you don't know who's on the other end.

Connecting an Account

1. Open webmail and go to Settings → Connected accounts.
2. Click Connect account and enter the address you want in your unified inbox.
3. If the provider was detected, follow the prompt: either the link to generate an app password, or the Microsoft sign-in page for an Outlook.com address. If it wasn't, enter the IMAP and SMTP host, port and encryption from your provider's documentation.
4. Click Test connection. Both legs are tested separately, so a failure tells you whether reading or sending is the problem rather than just saying "login failed".
5. Save. The account appears in the sidebar and its inbox joins the unified All inboxes view.

Folder mapping happens on first connection. Providers disagree about what to call the special folders — [Gmail]/Sent Mail, Sent Items, Sent — so special-use flags are read where available and names are matched where they aren't. Gmail's virtual folders such as All Mail are hidden, because they hold copies of messages that already appear in real folders and would otherwise show everything twice in your unified inbox.

Per-provider guides live in the docs: Gmail, Outlook and Microsoft, iCloud, Yahoo and AOL, and any other IMAP server.

What Breaks, and What It Looks Like

A revoked app password. The most common failure by a wide margin. Someone changes their Google password, Google invalidates every app password on the account, and the connection starts failing. The account shows a reconnect banner rather than quietly vanishing from your unified inbox. Generate a new app password and paste it in.

IMAP switched off at the provider. Some corporate Google Workspace and Microsoft 365 tenants disable IMAP by policy. There's no way around that from our side; an administrator has to enable it.

An expired OAuth grant. Microsoft tokens refresh automatically, but a tenant administrator revoking consent, or a password change, ends the grant. Same reconnect banner, sign in again.

A slow source server. Each source has a timeout. A provider that takes too long is skipped for that page load and reported as skipped, rather than being retried indefinitely at the cost of everything else on screen.

Full troubleshooting is in connected accounts troubleshooting.

Limits

Connected accounts are available from the Starter plan upward:

The unified inbox fans out across up to 25 sources at once. Past that the parallel fetch stops being fast enough to be worth waiting for, and the per-account views are the better tool anyway. Connected accounts consume no storage on your plan — the messages stay where they already are.

Frequently Asked Questions

Does a unified inbox move my mail?

No. Nothing is copied or moved. Your messages stay on the original provider's servers and are read over IMAP on demand. Disconnect the account and the source mailbox is exactly as it was.

What's the difference between a unified inbox and migration?

Migration copies mail permanently into a TrekMail mailbox, because you're leaving the old provider. A unified inbox leaves everything in place, because you're keeping the old provider and just want one screen. If you're consolidating for good, see bulk migration instead.

Will replies come from the right address?

Yes. A reply to a message that arrived at a connected account is sent from that account's address, through that account's own SMTP server, so SPF and DKIM stay aligned and the recipient sees the address they wrote to.

Why does Gmail need an app password instead of a sign-in button?

Reading mail over the Gmail API is a restricted scope requiring an annual third-party security audit. App passwords give the same access over standard IMAP, and you can revoke them individually from your Google account at any time.

Can I add a mailbox on my own server?

Yes — enter the IMAP and SMTP host, port and encryption manually. The certificate has to validate, so a self-signed one needs replacing first. A free certificate from any public CA is enough.

Does the unified inbox work on mobile?

Yes. Connected accounts are configured on the server, not in a local app profile, so every device you sign in from sees the same accounts and the same merged list with no per-device setup.

What happens if I downgrade to a plan without connected accounts?

The account stops being read and shows as unavailable. It isn't deleted, and nothing at the source provider is affected. Return to a plan that includes them and your unified inbox resumes.