You remember the message. It was from someone at the client, sometime in spring, and it had the signed statement of work attached. What you don't remember is which mailbox it landed in — your own, the shared projects@ inbox, or the old address you still keep connected.
So you run three separate searches, in three places, with three slightly different queries, and eventually give up and ask the client to resend it.
The problem isn't that you forgot where the message was. It's that almost every client defaults mailbox search to the folder you happen to be looking at, which is the narrowest and least useful scope available. This covers what the right scopes are, how a mailbox search that spans every account works underneath, and the operator syntax that turns a vague memory into one query.
Why the Default Scope Is Wrong
Folder-scoped mailbox search made sense when a mailbox was one flat file and searching it meant reading the whole thing off a spinning disk. Narrowing to a single folder was the difference between a result and a coffee break.
None of that is true now, and the default survived anyway. It produces a specific and very common failure: you search, get nothing, and conclude the message doesn't exist. In fact you were standing in Inbox and the message was archived eight months ago. A mailbox search that silently excludes most of your mail is worse than no search, because a null result reads as an answer.
The second failure is subtler. If you keep a folder hierarchy — Clients/Acme/Invoices under Clients — then searching Clients in a client that only looks at the exact folder returns nothing, because every actual message lives a level or two down. The folder you clicked is a container, not a location.
Three Scopes Within One Mailbox
Inside a single mailbox there are three sensible answers to "where should I look", and all three are useful. The middle one is the one most clients don't have, and it's what makes a folder tree worth maintaining.
| Scope | Searches | Use it when |
|---|---|---|
| This folder | The selected folder only | You know exactly where it is and want to narrow a common word |
| This folder and below | The folder plus every descendant in the tree | You keep a hierarchy and want everything under Clients/Acme |
| All folders | Every folder in the mailbox, including Archive, Sent and Trash | The default you actually want most of the time |
If searching a parent folder doesn't include its children, a hierarchy is decoration. And an all-folder mailbox search includes Sent, which matters more than it sounds: roughly half the time you're hunting for "that thread about the contract", the message you want is the one you wrote.
Searching Across Every Account
The scopes above still operate inside one mailbox. The bigger problem is that most people have several, and they're different kinds of thing: your own mailbox, shared team inboxes you're a member of, and connected accounts at other providers.
A cross-account mailbox search runs the same query against every one of these at once and merges the results into a single list, newest first, with each row tagged by the mailbox it came from. Two scopes apply at this level: search every mailbox's inbox, or search every folder in every mailbox. The first is triage. The second is the "find that thing" search, and it's the one that ends the three-tabs ritual.
What matters here is that the search runs against the real mailboxes, not a copy. A shared inbox is searched on the server where it lives. A connected Gmail account is searched by issuing an IMAP SEARCH to Google. Nothing had to be synchronised in advance, so a message that arrived thirty seconds ago is already in the results.
What Happens Underneath
Merging results from a dozen independent IMAP servers is more awkward than it looks, and the awkwardness explains the design.
The query is translated, not interpreted locally. Your search string is parsed into criteria and sent to each server as a real IMAP SEARCH command. The server does the work and returns matching identifiers. Nothing is downloaded to be filtered afterwards, which is what makes searching a 40 GB mailbox from a phone feasible.
Body search needs an index. IMAP servers will happily scan every message body for a substring, and on a large mailbox that takes long enough to time out. A full-text index sits in front of that, so body searches return in tens of milliseconds rather than tens of seconds. Connected accounts depend on whatever indexing their own provider does — excellent at Gmail and Fastmail, possibly nothing at a small self-hosted server.
Sources are queried in parallel. Ten mailboxes queried one after another means ten round trips stacked end to end. They're fanned out concurrently instead, and results merge as they arrive.
A slow source can't hold up the page. Every source has a timeout. If one provider's having a bad morning it's skipped and named as skipped — you get nine sets of results and a note about the tenth, rather than a spinner. Being told your results are incomplete is far better than being shown incomplete results silently.
Results merge by arrival time. Each server returns its matches with no idea the others exist, so the merge is done by internal date. That's why a cross-account result list is strictly chronological rather than relevance-ranked: there's no shared relevance score across independent servers to rank by.
Operators
Plain words search sender, subject and body. Operators narrow it, and they combine — every operator you add is an AND.
| Operator | Matches | Example |
|---|---|---|
from: | Sender address or display name | from:anna@acme.com |
to: | Recipient address | to:billing@ |
subject: | Subject line only | subject:invoice |
has:attachment | Messages carrying a file | has:attachment |
is:unread | Unread messages | is:unread |
is:starred | Starred or flagged messages | is:starred |
after: | On or after a date, YYYY-MM-DD | after:2026-04-01 |
before: | Before a date, YYYY-MM-DD | before:2026-07-01 |
larger: | Bigger than a size | larger:10M |
smaller: | Smaller than a size | smaller:200K |
Two details worth knowing. Multi-word values need quotes: subject:"quarterly report" searches for the phrase, while subject:quarterly report searches the subject for quarterly and the whole message for report. And a bare number in a size operator means megabytes — larger:5 is 5 MB. Kilobytes was the older interpretation and it was a trap, because nearly every message is larger than 5 KB, so the filter appeared to do nothing.
If you'd rather not memorise any of this, the filter icon next to the search bar opens the same thing as form fields.
Mailbox Search Recipes That Find Things
The attachment you know exists.
from:acme has:attachment after:2026-03-01 before:2026-06-01Sender, a file, and a season. Run that mailbox search across all accounts and all folders and it'll be in the first ten rows.
What's actually eating your quota.
larger:20MSorted newest first across every folder. This is usually a short and very informative list, and deleting six of those rows buys back more space than an afternoon of tidying.
What you promised and forgot.
to:client@example.com after:2026-06-01Searching Sent across all mailboxes reconstructs your side of a conversation, including replies you sent from a shared inbox rather than your own address.
Genuinely unread, not merely unopened.
is:unread after:2026-07-01Across every mailbox at once, which is the only honest answer to "what haven't I dealt with".
The thread you only half remember.
subject:"statement of work" larger:100KA phrase in the subject plus a size floor, on the theory that the version with the attachment is the one you want.
Server-Side Beats Client-Side
Desktop clients search a local copy. That's fast, and it has three consequences people discover at the wrong moment.
It only covers what's been downloaded. Most clients keep a rolling window — the last few months, or headers only for old mail — so a mailbox search returning nothing may simply be searching a subset. It only works on that machine: search on your phone and you're searching a much smaller cache. And it can't see mailboxes that machine hasn't been configured with, which is exactly the shared inbox you were looking for.
Server-side mailbox search has none of those properties. The query runs where the mail is, so the answer is the same on every device, covers the entire mailbox regardless of age, and includes every mailbox you have access to whether or not that device knows about them.
Where It Gets Imprecise
Connected accounts search at their own provider's quality. A cross-account mailbox search issues IMAP SEARCH to each remote server; what comes back depends on that server. Gmail applies its own tokenisation, so partial-word matches behave differently there than on your TrekMail mailbox.
Attachment contents aren't searched. has:attachment finds messages with files attached. Text inside a PDF isn't indexed. That's a document-search product, not a mail-search one.
Results are chronological, not ranked. There's no cross-server relevance score. Narrow with operators rather than hoping the best match floats up.
The fan-out is capped. A merged view spans up to 25 mailboxes at once. Past that the parallel queries stop finishing quickly enough to be worth waiting for, and searching a specific mailbox is the better move anyway.
Trash is included. This surprises people. It's deliberate — "I deleted it last week and now I need it" is a normal Tuesday — but it does mean a result may be something you already threw away. The folder badge on each row tells you.
Frequently Asked Questions
Does mailbox search include shared inboxes?
Yes, every shared mailbox you're a member of is searched alongside your own, and results are tagged with which inbox they came from. Mailboxes you aren't a member of aren't searched, because they aren't yours to read.
Does mailbox search cover connected external accounts?
Yes. Connected accounts are queried over IMAP like any other source, and their results appear in the same merged list with the provider's badge on the row.
Is my mail sent anywhere to be searched?
No. The query is translated into an IMAP SEARCH and executed by the server that already holds the mail. Message contents aren't copied out to a third-party index.
Why does the same query return more results on the web than in my desktop client?
Because the desktop client is searching its local cache and the server is searching everything. Local caches are usually a rolling window of recent mail, so anything older is invisible to a client-side search.
Can I run a mailbox search by date without typing operators?
Yes — the filter panel next to the search bar has date fields, sender and recipient fields, and toggles for unread, starred and attachments. It builds the same query.
Why does mailbox search return results in date order instead of best match first?
Results come from several independent servers, each ranking only against its own mailbox. There's no shared score to sort by, so the only meaningful merge order is time. Use operators to narrow instead.
Does mailbox search cover the Junk folder?
All-folder scope includes Junk. If you're hunting for something a filter caught by mistake that's the fastest way to confirm it — and if you find it there, see why messages end up in spam.
