How Conditional Email Routing Rules Work

By Ahsan

A conditional email routing rule is a server-side predicate that a mail forwarding service evaluates against each inbound message before delivery. The rule pairs a set of conditions on the message with a set of actions, and the service applies the actions when the conditions match. In AliasFleet, the rules engine intercepts an inbound transaction immediately after address resolution and evaluates the message against the account rule chain in priority order, as described in the Rules API reference.

Evaluation model

Rules run in sequence starting from priority 1, and each rule specifies a match type of ALL or ANY across one to five conditions. ALL requires every condition to hold, while ANY requires at least one. A rule carries one to five actions, and all of the actions run when the rule matches. Each rule also carries an optional stop_processing flag, and when a matched rule sets the flag, evaluation of lower-priority rules ends for that message. The flag gives the chain the same short-circuit behaviour found in other rule systems, where an early match makes later rules unreachable for that message.

Condition fields

The reference lists nineteen condition fields in five groups. Sender attributes cover the full sender address, the sender domain, the display name and the Reply-To address. Recipient attributes cover the alias address and domain, the lifetime forwarded count for the alias, whether the message arrived through a domain catch-all, and whether the spam classifier flagged the message. Content attributes cover the subject line, any named MIME header and the total message size in kilobytes. Attachment attributes cover the presence of attachments, file names and MIME types. Authentication attributes cover the SPF, DKIM and DMARC verdicts and the numeric Rspamd spam score. The score thresholds in the reference are below 5.0 for clean mail, 5.0 and above for suspected mail, and 10.0 and above for blocked mail.

Comparison operators

Thirteen comparison operators apply across the fields. String fields use is, is_not, contains, does_not_contain, starts_with, ends_with and matches_regex, with matching case-insensitive. Header fields also use exists and not_exists for presence tests. Numeric fields use greater_than, less_than, greater_than_or_equal, less_than_or_equal and is. A condition on the sender domain therefore reads as a comparison between a field and a value, and a condition on the spam score reads as a numeric comparison against a threshold, with the same operator set serving both kinds of field.

Actions

The reference lists sixteen action types in four groups. Transformation actions prepend or append text to the subject, replace the subject or the sender display name, and inject a custom header. Security actions strip tracking pixels and attachments, disable PGP encryption for the matched delivery, and set the position of the disclosure banner. Routing actions forward the message to a different verified destination, send an automatic reply, add the sender to the blocklist, and dispatch a JSON payload to a registered webhook endpoint. Terminal actions drop the message silently, with no forwarding and no bounce, or place it in quarantine for administrative review. The engine specification describes quarantine as AES-256-GCM encryption of the raw message into a vault for seven days, with inspection, release and discard handled in the application. The automatic reply follows RFC 3834, with loop protection and a recipient cooldown that defaults to 24 hours and ranges from 1 to 168 hours.

Plan limits

Rule counts depend on the subscription tier. The Free tier allows no rules, and an attempt to create one returns HTTP 403 with the code LIMIT_REACHED. The Pro tier allows 20 rules, and the Business tier allows an unlimited number. The limit is enforced at creation time, and deleting a rule releases its quota allocation.

Relation to other filtering systems

The condition-action shape is shared with older filtering systems. Sieve, the IETF mail filtering language defined in RFC 5228, expresses a rule as a set of tests on headers, envelope and size, combined with allof, anyof or not, followed by actions such as fileinto, redirect, discard and reject. Microsoft Exchange transport rules use the same three-part structure of conditions, actions and exceptions, and include a stop-processing option that ends evaluation of later rules, as described in the CodeTwo guide to Exchange transport rules. The difference between these systems and an alias forwarding service is the point of evaluation: mailbox filters run at delivery into a mailbox, while forwarding rules run at the forwarding service before the message reaches the destination inbox, so the actions available are forwarding, transformation and dropping rather than filing into folders.

Rules API

The rules are managed through the AliasFleet API under /v1/rules, with rules:read scope for listing and rules:write scope for creation, update, deletion and reordering. Endpoints accept a name of 1 to 120 characters, an optional description, a priority, a match type, the stop_processing flag, and arrays of one to five conditions and one to five actions. A separate reorder endpoint accepts an ordered array of rule identifiers and assigns priority from the array position. Requests are limited to 60 per minute.