Skip to the documentation
Knowledge base

Rules you write yourself

Your own conditions, and what should happen to anything that matches them.

Details

  • Written in Settings → Rules, and over the REST API at /rules, which is on for every workspace. A rule is a list of conditions over an arriving message and a list of actions to take on anything matching them: 100 rules per mailbox, each holding at most 20 conditions and 10 actions. Those are guards against a script in a loop rather than plan limits. The 101st rule is refused with a message saying so, not billed for.
  • Twenty-one things a condition can ask about: the From address and its domain (where a match on example.com covers mail.corp.example.com too), the SMTP envelope sender, To, Cc, Bcc, any recipient, Reply-To, the address the copy was actually delivered to with its plus-tag stripped, subject, body, any named header, the List-Id, an attachment’s name, type or size, whether there is an attachment at all, the whole message size, the spam verdict, and the hour and weekday it arrived in UTC. Matching is a glob (* and ?), or contains, equals, starts with, ends with, and greater or less than on the four numeric ones. A pattern has to carry two alphanumeric characters of its own, so a bare * is refused when you write it rather than matching every message that will ever arrive.
  • All of the conditions or any of them, with a NOT on each one individually. There is no nested bracketing: (A and B) or C is two rules, which is how you read it back six months later anyway.
  • Eleven actions: label, remove a label, archive, mark read, star, file as spam, trash, forward, auto-reply from a template, block the sender, and refuse the message outright. Rules run in the order you put them in, lowest first, and any of them can be switched off without being deleted. A rule marked stop processing ends the pass, so nothing below it is considered, and where two rules both name a folder, the later one wins, because that is what a numbered list means.
  • Refusing at the door is envelope-only, and it is refused at write time otherwise. A 550 is answered by whoever handed us the message, and on a mailing list that is the LIST, which reads it as a bouncing subscriber and unsubscribes you from something you only wanted one person to stop posting to. A rule matching a sender on the From header alone files under Spam instead, exactly as blocking one does.
  • Auto-reply will not answer a machine. It is suppressed on Auto-Submitted, Precedence: bulk, list or junk, a List-Id or List-Unsubscribe header, X-Autoreply, X-Autorespond, and on the empty envelope sender every bounce carries. Beyond that, one sender gets at most one reply per day. Two mailboxes with reply rules and no guard mail each other until somebody notices.
  • A forward is a rebuilt copy rather than the message that arrived: it goes out through the send path, so the sender’s DKIM signature does not survive it, nor do unusual headers and exotic parts. The original rides along as a .eml attachment so the headers and the exact parts are still there to read, unless it is over the 5MB attachment ceiling, in which case the forward still goes with the readable body and the original stays behind in your own mailbox. Nothing tells you that happened, which is the part worth knowing. The destination is checked when you write the rule, but only for shape: ops, or ops@example with no dot, is refused as you write it rather than failing once per matching message afterwards. A typo that is still a valid address ([email protected] for [email protected]) is accepted, and a rule’s destination is never asked to confirm itself the way an address forward’s is, so the copy goes to exactly what you typed.
  • A rule can be tried before it is turned on: point it at the last thirty days (up to a year, up to 200 messages) and it reports which of your own messages it would have caught and what it would have done to them, without touching one of them. The same matcher answers that as runs on the delivery path, but a stored message is not the message SMTP handed over. The envelope sender, the header map, the List-Id, the address it was delivered to and the size on the wire are gone by then, so eleven of the twenty-one fields answer differently in a dry run or cannot answer at all, and the dialog names them rather than quietly scoring them as misses. The sharpest case is a rule that refuses at the door: it is required to carry an envelope-sender condition, and nothing in storage can answer one, so a preview reports it matching nothing however much it would refuse in practice.
  • Nothing is retroactive, and there is deliberately no button that makes it so. Applying a rule across a mailbox you already have is unbounded, has no undo, and would drag every message it touched back to the top of the inbox. Rules decide what happens to mail arriving next.
  • What each rule has done is recorded per message (the actions that were applied and, separately, the ones that were refused and why), so “why did this end up here” and “why did my out-of-office not answer that” are both answerable. The log keeps the rule’s name, so it still reads correctly after the rule is renamed or deleted.
  • It applies to every address on your own domains, so a rule reaches everything that arrives rather than being offered somewhere it would quietly do nothing.
  • If the engine cannot answer (a condition from a newer client, a database that will not respond), the message is delivered as it would have been and the failure is logged. A rule that throws is a message that never arrives.