10.23. Route and Filter Incoming Messages with Inbound Email Rules

Monitoring alerts often name the affected customer inside the message instead of sending from that customer's address. Inbound email rules help an MSP assign those messages to the right client and keep routine noise out of the ticket queue. For example, an alert mentioning GreenLeaf Dental Group can reach its service record without manual reassignment.

Before you begin

Connect an inbound mailbox and configure its ticket defaults first. Reading and managing rules requires the corresponding system_settings read, create, update, or delete permission. Changing a client's inbound domain or contact-creation option requires client:update. Classify with AI additionally requires Enterprise Edition and an active AI Assistant add-on; the ordinary matching actions do not require that add-on.

Create and order a rule

1. Open Settings > General, select Email under Communication, and open Inbound Email > Inbound Rules.
2. Select Add Rule. Enter a Rule name and choose whether it is Active.
3. In Apply to mailboxes, select the relevant mailboxes. Leaving every mailbox unchecked applies the rule to all mailboxes.
4. Set Conditions (all must match). Choose From address, From domain, To/CC address, Subject, or Body text, an operator, and a value. Use Add condition for additional requirements.
5. Choose an Action, configure it, then use Test this rule before selecting Create rule. An existing rule uses Update rule.
6. Use the arrow controls beside the saved rules to arrange their order. Put narrow exceptions before broad routing rules, and use the active switch to disable a rule temporarily.

Rules evaluate new inbound email from top to bottom. A resolving match determines the outcome; an extraction rule configured to continue when it cannot find a client allows later rules or normal processing to run. Replies already matched to a ticket follow reply handling rather than these new-ticket routing rules, subject to the security checks below.

Match names, devices, and contact addresses

For Assign client from extracted text, choose Extract from and an Extraction method: Text between delimiters, Text after marker, Text before marker, or Regular expression (advanced). Select the appropriate First or Last occurrence where offered.

Under Match extracted value against, select Client name or alias, Device (asset) name, Contact email, or a combination. For a subject such as Customer: GreenLeaf Dental Group, extract the text after Customer: and match the client name. For a body containing a device name or contact address, select Body text and the corresponding target. Contact matching accepts an address in display-name format.

Choose If no client matches deliberately: Continue with later rules / normal processing, Route to a fallback destination, or Skip the email. An ambiguous device or contact match across clients does not assign a client automatically.

For AI classification, write an Instruction and select May assign clients, May skip emails, or both. Review the no-match behavior here too.

Test before enabling

1. In Test this rule, enter representative From, To, Subject, and Body text values.
2. Select Run test and inspect the extracted value, matched client, and predicted outcome. This evaluates the draft rule without creating a ticket.
3. If the extracted client name is an alternate name, select the intended client and use Add alias, then rerun the test. Adding an alias saves that alias; it is not merely a simulated change. Aliases are also managed under Matching aliases on the client record.

Create contacts for trusted new senders

On the client's Inbound email domains settings, add its domain and enable Create contacts for new senders for that domain. Domains must be unique across clients. This creates a contact for an eligible unknown sender whose mapped domain resolves to that client; it is not a general contact-creation action for every rule match.

Automated senders, the provider mailbox itself, and senders that fail the applicable authentication checks are excluded. A rule-assigned client also bypasses this domain-based creation path. If no contact appears, check these conditions and whether the option is enabled.

Understand protected or suppressed messages

Automated replies, vacation messages, bounces, and bulk/list messages are detected for loop prevention. An accepted automated reply can remain a comment without reopening a closed ticket; repeated inbound reopening is also limited. Recognized notification loops can be skipped entirely.

Sender-authentication failures can reject attribution to a known contact or internal user. A thread-header reply from an unauthorized participant is quarantined instead of appended to the ticket or turned into a new ticket. Investigate processing diagnostics and sender membership; a matching subject alone does not establish authorization.

Related

• Connect inbound email
• Configure ticket reply email
• Edit client information