Routing rules

How rules are evaluated

Each rule belongs to a domain and holds a list of conditions. Rules are ordered by priority, lowest first, and the first rule that matches wins — evaluation stops there. Inactive rules are skipped entirely.

A rule with no conditions never matches. This is deliberate: an empty rule is almost always a half-finished one, and matching everything would be a surprising default.

Conditions

A condition is a field, an operator, and a value. Four fields are available:

Field	Matched against
from	The sender's address.
to	The recipient address the message arrived on.
subject	The decoded subject line.
body	The plain-text body, plus the preview.

And six operators:

Operator	Matches when the field…
contains	contains the value anywhere
not_contains	does not contain the value
equals	is exactly the value
starts_with	begins with the value
ends_with	ends with the value
regex	matches the regular expression

Matching is case-insensitive. Both the field and your value are lowercased before comparison, including for regex. Do not add your own case handling — Invoice and invoice are the same value here.

All or any

A rule with several conditions combines them one of two ways:

• All — every condition must match. Use this to narrow.
• Any — one match is enough. Use this to gather several senders into one bucket.

There is no nesting. A rule is one flat list joined by AND or by OR, which keeps rules readable at the cost of expressing "A and (B or C)" — express that as two rules instead.

Worked examples

Everything from a payment provider

One condition: from ends_with @stripe.com. Using ends_with on the domain rather than contains means a sender like stripe.com.phish.example does not match — the value has to terminate the address.

Invoices, from anyone

Match mode any, with subject contains invoice, subject contains receipt, and subject contains factuur. Three conditions, one bucket.

Per-signup addresses

With a catch-all in place, a condition of to starts_with shop- isolates every address you handed out with that prefix — shop-newsletter@, shop-support@ — without creating any of them in advance.

Ticket references with a regular expression

subject regex \[#[0-9]{4,}\] catches subjects carrying a bracketed ticket number. The expression is matched case-insensitively; a malformed expression simply never matches rather than erroring the message.

Dropping noise

Match the sender or subject you never want, and let the rule drop it. Those messages are recorded with status filtered, so you can confirm the rule is doing what you think before you forget it exists.

Ordering rules

Because the first match wins, put the most specific rules at the lowest priority numbers and the catch-alls last. A broad "anything containing invoice" rule sitting above a narrow "invoices from Stripe" rule means the narrow one never runs — the logs will show mail matching a rule you did not expect, which is usually the first sign the order is wrong.