10 Sieve Email Filtering Examples That Save Time
A mailbox usually becomes messy for a boring reason: every message lands in the same place, then waits for someone to decide what it is. These Sieve email filtering examples move that decision to the mail server. A receipt can go to Receipts before your phone checks mail. A monitoring alert can skip the inbox entirely. A message from a specific address can be discarded, filed, forwarded, or answered based on rules you control.
That matters when email is infrastructure rather than a chat feed. You may have a custom domain with addresses for invoices, client work, family accounts, server alerts, and online signups. Creating those addresses is easy. Keeping them useful requires rules that run consistently, whether you use webmail, Apple Mail, Thunderbird, Outlook, or a script over IMAP.
Sieve is the standard language for those rules. It runs on the server at delivery time, not inside one particular mail app. The trade-off is that it is text configuration, not a drag-and-drop rule builder. In return, the behavior is portable, inspectable, and not tied to a vendor's desktop client.
How a Sieve filter works
A Sieve script tests parts of an incoming message, then performs an action. Common tests look at the sender, recipient, subject, message size, headers, or body. Common actions file a message into a folder, redirect it, reject it, discard it, add a flag, or send an automatic reply.
Every script should begin by declaring the extensions it uses. For example, a rule that files a message and stops later rules from changing it needs `fileinto` and `stop`:
```sieve require ["fileinto"];
if address :is "from" "billing@example.com" { fileinto "Receipts"; stop; } ```
Folder names must match the folders in your mailbox. `Receipts` is not the same as `receipts`. Also, test new rules with one known message before relying on them for mail you cannot afford to lose.
Rule order matters. Sieve reads from top to bottom. A broad rule placed before a specific one can catch mail first. The examples below use `stop;` where the message should not continue through the rest of the script.
Sieve email filtering examples for real mailboxes
1. File receipts and renewal notices
Use a dedicated address such as `receipts@yourdomain.com` for purchases and subscriptions, then keep the inbox clear without deleting financial records.
```sieve require ["fileinto"];
if address :is "to" "receipts@yourdomain.com" { fileinto "Receipts"; stop; } ```
Filtering by the address that received the message is safer than filtering every sender whose subject says “receipt.” Companies change subject lines. Your address does not.
2. Sort automated system alerts
A small team may use a catch-all address or aliases for uptime monitors, hosting providers, backups, and source control. Put routine notifications in a folder, while preserving the ability to search them later.
```sieve require ["fileinto", "regex"];
if header :regex "from" "^(alerts|monitoring)@" { fileinto "System Alerts"; stop; } ```
Regular expressions are useful but easy to overdo. Start with an exact sender or a specific alias when possible. A loose pattern can accidentally catch a legitimate human message from a similar address.
3. Mark mail sent to a project alias
Aliases are a clean way to separate projects without buying another mailbox. Instead of filing the message away, you may only want a visible marker in your inbox.
```sieve require ["imap4flags"];
if address :is "to" "project-red@yourdomain.com" { addflag "Project Red"; } ```
Whether a custom keyword appears as a tag in your mail client depends on the client. The message still remains in the inbox, which is useful for work that needs attention now rather than later.
4. Send invoices to accounting
If an outside bookkeeper needs invoices but not access to your entire mailbox, redirect only the messages sent to a designated address.
```sieve require ["redirect", "copy"];
if address :is "to" "invoices@yourdomain.com" { redirect :copy "bookkeeper@example.net"; } ```
The `:copy` option keeps the original message in your mailbox while sending a copy onward. This is preferable to forwarding from a mail client, which only works when that client is running and configured. Confirm the recipient actually wants this flow, especially if invoices include personal or payment information.
5. Quiet known newsletters without pretending they are spam
Newsletters are not necessarily spam. They may be useful, just not urgent. File them based on a list header rather than the sender address, which can change across a publisher's delivery system.
```sieve require ["fileinto"];
if exists "list-id" { fileinto "Reading"; stop; } ```
This is intentionally broad: it files all mailing-list messages. If you want only one publication, inspect a real message's `List-Id` header and use an exact `header :is` match instead. That extra specificity avoids burying a community list or product announcement you actually need to see.
6. Discard a persistent unwanted sender
Use discard sparingly. A filter that silently removes mail is harder to audit than one that files it to a Junk or Review folder. But for a sender that repeatedly ignores unsubscribes, it is a reasonable last step.
```sieve if address :is "from" "unwanted@example.com" { discard; stop; } ```
Do not use a broad domain match unless you are certain. Many legitimate services send from shared domains or rotate addresses. Filing first and reviewing for a week is the less exciting, safer option.
7. Reject oversized attachments
A size rule can prevent a mailbox from filling with files that should have been shared another way. The sender receives a delivery failure rather than assuming the message arrived.
```sieve require ["reject"];
if size :over 25M { reject "Please share files larger than 25 MB using a file-sharing service."; stop; } ```
Choose the threshold based on your storage and workflow. A 25 MB message does not necessarily consume only 25 MB after email encoding, and large attachments also make backups and migrations slower. Rejection is clearer than accepting mail and later discovering that storage is full.
8. Reply automatically while away
Vacation responses belong on the server because they should work even when every device is off. Keep the message short and avoid revealing travel details to unknown senders.
```sieve require ["vacation"];
vacation :days 7 :subject "Out of office" "I am away until April 18 and will respond when I return."; ```
The `:days 7` setting prevents repeat replies to the same sender for seven days. Avoid an auto-reply for a public catch-all address. Those addresses receive mailing lists, automated notices, and occasional junk, none of which need a response.
9. Route mail by recipient with a catch-all domain
Catch-all addresses are useful for tracking who received your address or for giving every vendor its own alias. A Sieve rule can separate mail sent to a whole naming pattern.
```sieve require ["fileinto", "regex"];
if address :regex "to" "^shop-.*@yourdomain\\.com$" { fileinto "Shopping"; stop; } ```
This works well when you deliberately use addresses like `shop-hardware@yourdomain.com` and `shop-books@yourdomain.com`. It does not prove that a sender is trustworthy. An alias tells you where a message was addressed, not whether its contents are safe.
10. Keep an audit copy of mail sent to a role address
For a shared role address such as `support@` or `contracts@`, keeping a copy in an archive folder can prevent a staff change from turning into a missing-record problem.
```sieve require ["fileinto", "copy"];
if address :is "to" "contracts@yourdomain.com" { fileinto :copy "Archive/Contracts"; } ```
Because of `:copy`, the message continues to normal delivery after the archive copy is made. This is a sensible pattern for records that should remain visible to the assigned mailbox while also being retained centrally.
Build rules that fail safely
The best first filters organize mail without removing it. Start by filing messages into a reviewable folder, then move to redirects, flags, or discard only after you have seen the rule behave correctly. Keep exact-match rules above broad matches, and add a short comment whenever a rule exists for a non-obvious reason.
```sieve
Vendor changes sender addresses often; filter the dedicated alias instead.
if address :is "to" "hosting@yourdomain.com" { fileinto "Infrastructure"; stop; } ```
At FranklyMail, Sieve is available as part of the email service rather than as an enterprise-tier add-on. That fits the point of server-side filtering: create the addresses you need, apply rules once, and let standard mail clients remain interchangeable.
A mailbox does not need more folders to become manageable. It needs a few rules that reflect how you actually work - and enough restraint that a useful message never disappears just because a filter looked clever.