Your desktop inbox is tidy and your phone is a disaster. Same mailbox, same account, completely different experience — and the reason is that the mail filters doing the tidying live inside your desktop application, and your phone has never heard of them.
That's the defining property of client-side mail filters: they run when the client runs. Close the laptop on Friday and nothing is sorted until Monday, at which point three days of mail reorganise themselves in one burst, generating notifications for messages you read on your phone two days ago.
Server-side mail filters don't have this problem, because they execute at the moment of delivery, before the message is stored. Every device that connects afterwards sees a mailbox that's already organised. The technology behind them is Sieve, it's thirty years old, and it's genuinely the correct answer.
Where Your Mail Filters Run Decides Everything
| Client-side rules | Server-side filters | |
|---|---|---|
| Run when | The app is open and syncing | The message is delivered |
| Apply on | That one device | Every device |
| Effect on notifications | Phone pings, then the message vanishes later | Filed before any device is told about it |
| Survive a reinstall | No — they live in the app's profile | Yes — they live in the mailbox |
| Work while you sleep | Only if the machine is on | Always |
The notification row is the one people feel daily. A newsletter arrives, your phone buzzes, and forty minutes later your desktop quietly moves it to Read later. The rule worked; it just worked after the interruption it was supposed to prevent. A server-side filter files the message before your phone is ever told it exists.
Sieve, Briefly
Sieve is a small language for exactly one job: deciding what happens to a message at delivery. It's standardised as RFC 5228, deliberately not Turing-complete, and it can't loop, call out to the network or run arbitrary code. Those restrictions are the feature — a filtering language that could do those things would be a way to make your mail server execute code chosen by whoever emails you.A script looks like this:
if header :contains "from" "billing@vendor.com" {
fileinto "Finance/Invoices";
stop;
}You don't need to write this. The visual builder generates Sieve behind the scenes; every one of your mail filters becomes part of the script that runs on delivery. Knowing it's Sieve underneath is useful mainly because it explains the behaviour — why rules stop at the first match, why forwarding from a filter is a real SMTP redirect, and why everything applies identically on every device.
Mail Filters Need Somewhere to Put Things
Mail filters need somewhere to put things, and a flat list of thirty folders isn't somewhere — it's a different kind of mess.
Folders nest arbitrarily deep, and the tree is derived on the server from the IMAP folder structure, which means the same hierarchy appears in webmail, Outlook, Apple Mail, and on your phone. Create a subfolder in one place and it's there in all of them.
Clients
Acme
Invoices
Contracts
Globex
Invoices
Finance
Receipts
Tax
Three things make a tree usable rather than merely present:
Collapse and expand, remembered per person. On a shared mailbox, each member's collapse state and folder colours are their own. Two people looking at the same team inbox don't fight over the sidebar, because the preference is stored per member rather than per folder.
Colours. A visual anchor on the four or five folders you actually use, so you stop reading the sidebar as a list of words.
Search that respects the hierarchy. The one that matters most. Searching Clients can search that folder alone, that folder and everything beneath it, or the entire mailbox. Without the middle option a hierarchy is actively harmful — you would have to search each leaf separately. See searching every mailbox at once for how the scopes work.
Building Mail Filters Visually
Mail filters are conditions and actions.
Conditions match on sender, recipient, subject, message body, size, or a specific header, with comparisons such as contains, is exactly, begins with, and ends with. Multiple conditions combine with all-must-match or any-may-match.
Actions file into a folder, forward to another address, mark as read, flag or star, discard silently, or reject with a message back to the sender.
Two actions deserve a warning.
Discard is silent and permanent. The message is accepted and dropped. There's no copy in Trash and no record. A discard rule with a condition that's broader than you thought will destroy mail you needed, and you won't find out for months. Prefer filing into a folder you rarely open; storage is cheaper than the alternative.
Reject bounces a message back to the envelope sender, which is frequently not the person who wrote it. On mail with a forged sender — most of what you would want to reject — the bounce goes to an innocent third party, and you've become a backscatter source. Almost always, filing into Junk is the right answer.
Forwarding from mail filters is worth understanding as a mechanism: it's a real SMTP redirect, which means the forwarded copy can fail authentication at its destination exactly as any forwarded mail can. SRS repairs the SPF side automatically. If you're forwarding to a Gmail address and it lands in spam, that's why.
Mail Filters Run in Order, and Order Matters
Mail filters are evaluated top to bottom, and that's where most filter sets quietly break.
Consider two rules:
- Anything from
@acme.com→ file into Clients/Acme - Anything with invoice in the subject → file into Finance/Invoices
An invoice from Acme matches rule 1 first and lands in Clients/Acme. Rule 2 never runs, because filing stops evaluation. Nothing is broken and nothing warns you — you simply never see Acme invoices in Finance, and it takes a while to notice.
Rules of thumb: specific before general. A rule about invoices from one vendor goes above the rule about that vendor. And when a rule stops working, look at what is above it before you look at the rule itself. Filters can be dragged into a different order at any time, and reordering is usually the fix.
When to Write Sieve by Hand
The visual builder covers nearly everything. The raw editor exists for mail filters it can't express, and it's available on the Agency plan.
Reach for it when you need nested boolean logic — this AND that but NOT the other — or regular expressions, or headers the builder doesn't expose, or a vacation auto-reply combined with filing and forwarding in one coherent script. It's also the practical way to maintain a template applied across dozens of mailboxes, since a script is text you can version and copy.
require ["fileinto", "regex", "imap4flags"];
if allof (
header :regex "subject" "^\\[TICKET-[0-9]+\\]",
not header :contains "from" "noreply@"
) {
setflag "\\Flagged";
fileinto "Support/Active";
stop;
}One caution: the raw editor and the visual builder manage the same set of mail filters. Switching to raw and editing by hand is the point at which the builder stops being the source of truth. Pick one per mailbox and stay with it. See the raw Sieve editor.
Patterns That Earn Their Keep
Route by alias, not by sender. If you use a distinct alias per service — newsletters@, receipts@, shopping@ — then one rule on the recipient address does the work of fifty rules on senders, and it keeps working when a service changes its sending domain.
File, don't delete. An Automated folder that receives every notification, alert, and receipt keeps the inbox for things a person wrote, and keeps everything findable. Deleting is irreversible; filing isn't.
Flag, don't move, for anything urgent. Moving a message out of the inbox is how it gets missed. Star it and leave it where you'll see it.
One catch-all rule at the bottom. A final rule that files anything not matched by anything else into a review folder, so you can see what your filter set isn't covering. Delete it once the set is stable.
Don't build the hierarchy first. Three levels of folders created in advance for mail you haven't received yet won't survive contact with reality. Add a folder when a pile appears.
Mail Filter Limits
| Plan | Mail filters per mailbox | Forwarding actions in filters | Raw Sieve editor | Auto-reply |
|---|---|---|---|---|
| Nano | 3 | — | No | No |
| Starter | 3 | — | No | Yes |
| Pro | 10 | 5 | No | Yes |
| Agency | 50 | 25 | Yes | Yes |
Forwarding actions are capped separately from mail filters in general, because a filter that redirects mail is sending on your behalf and counts against sending policy rather than storage.
Frequently Asked Questions
Do server-side mail filters work with Outlook and Apple Mail?
Yes, and that's the point. Mail filters run on the server at delivery, so every client sees an already-sorted mailbox. You configure nothing in the client.
Do I have to learn Sieve?
No. The visual builder writes it for you. The raw editor is there for cases the builder can't express, on the Agency plan.
Why did one of my mail filters stop working?
Nine times out of ten another rule above it matched first and stopped evaluation. Check the order before you check the rule.
Can mail filters run on messages that already arrived?
No. Mail filters execute at delivery time, so they apply to new mail only. Use search and bulk actions to reorganise what is already in the mailbox.
What is the difference between filter forwarding and mailbox forwarding?
Mailbox forwarding sends a copy of everything to another address. A filter forwards only messages that match its conditions. Conditional forwarding is what most people actually want.
Are folder colours shared with my team?
No. Colours and collapse state are stored per person, so each member of a shared mailbox arranges the sidebar their own way.
How deep can folders nest?
Arbitrarily, though anything past three levels tends to be harder to use than search. The tree is derived from the IMAP structure, so the same hierarchy appears in every client.
