Most of the Router module's rule conditions — subject phrases, content phrases, sender or sending IP, attachment type, MIME headers, message size, day/time — were originally built to decide where an email goes. The same conditions are just as useful for deciding what an email is, without necessarily moving it anywhere: adding a category tag or a custom header based on the same rules, and leaving the message in a single queue for a human or downstream system to triage using that tag.
This matters once a team has grown past "read everything in order" and needs a queue that can be filtered, prioritised, or reported on by category — a helpdesk, a shared support inbox, or a CRM lead queue.
A few tagging patterns that pay off quickly for a small support or sales team:
- Topic/category — billing, technical, sales enquiry, complaint — matched on subject or content phrases, so a helpdesk or CRM can filter or auto-assign by category without a human reading every message first.
- Priority — content phrases like "urgent," "down," "cannot access" bumped to a higher priority tag; useful as a first-pass triage signal, not a replacement for a human decision on genuinely critical issues.
- Source/channel — tag mail arriving via a specific alias (orders@, careers@, press@) even if it all lands in one inbox, so downstream systems know which public address it came in on.
- Attachment presence/type — tag messages containing invoices, CVs, or specific document types differently from plain text enquiries, since those often need a different handling path.
- Language — see routing multilingual support email into your CRM for the language-specific version of this pattern.
A tag that only exists as an internal rule match inside the mail server is not useful to a CRM or helpdesk until it leaves the mail server in a form those systems can read. Two practical ways to do that:
- Custom header on the message. The rule adds a header (something like
X-Category: billing) that the message carries with it into the destination mailbox or system, readable by any downstream tool that parses headers. - Webhook payload field. If the message also triggers a webhook (see event-driven email workflows), include the matched category directly in the JSON payload sent to your application, which is usually the more reliable path if your CRM or ticketing system is receiving mail data via API rather than parsing raw email.
Tagging rules degrade the same way inbox filing rules do if nobody revisits them:
- Review phrase-matching rules periodically — customer language shifts, and a rule tuned for last year's common complaint phrasing quietly stops matching.
- Keep a "none of the above" fallback tag rather than letting untagged mail disappear into an undifferentiated pile — an explicit "uncategorised" tag is easier to notice and fix than silence.
- Where two rules could both match the same message, decide deliberately which should win (usually the more specific rule), rather than relying on whichever rule happens to be evaluated first.
The Router module in Hexamail Guard and Hexamail Nexus can match on subject, content, sender, sending IP, attachment type, MIME headers, size, and date/time, and apply that match either as a routing decision or as a tag/header on the message, without necessarily moving it anywhere. Paired with the Developer module's webhooks, the same match can also be delivered directly into a CRM, helpdesk, or analytics pipeline as structured data rather than a header buried in the raw email.