Inbound email routing should be predictable, not clever. We resolve every message with an ordered ladder of explicit rules and a guaranteed human triage queue at the bottom, so routing stays something a recruiter can reason about and nothing is ever silently dropped.
The ambiguity problem
Once the system is reading a shared inbox, it faces a question on every message that a human answers instinctively but software has to be told how to answer: what is this? A CV for the backend role, a reply from a candidate already in the pipeline, a recruiter's cold pitch, an invoice, a newsletter; they all arrive at the same address in the same stream.
Before an email can become an application on the right board, three things have to be decided: is this hiring-related at all, is it a new application or a reply to an existing one, and if it is new, which job does it belong to? Get any of those wrong and you either lose a candidate or clutter a pipeline with noise.
Why we didn't reach for a classifier
The fashionable answer would be to train a model to classify inbound mail. We deliberately did not. A learned classifier is opaque, needs labelled data we did not have, and fails in ways that are hard to predict and harder to explain to a recruiter who just wants to know why a CV ended up in the wrong place.
Routing is a domain where predictability matters more than cleverness. A recruiter should be able to hold a simple mental model of how mail flows and trust it completely. So we built the routing engine as an ordered ladder of explicit rules, each tried in priority order, with a guaranteed fallback at the bottom.
The rungs, in order
The ladder resolves each message by asking increasingly general questions and stopping at the first confident answer. First, is this a reply from someone we already know? If the sender and thread match an existing application, the message is threaded into that candidate's conversation rather than creating a new record, because continuing a conversation is the most specific thing an email can be. Second, was it sent to a per-job address? Each role can have its own address on a catch-all apply domain, which belongs to exactly one job by construction.
Third, does the subject carry a job code? A short bracketed code in the subject line maps the message to a specific role, the lightweight option for teams that do not want per-job addresses. Fourth, is there a designated default job? An organisation can nominate a fallback role for unrouted hiring mail, so a single-opening company never sees a triage queue at all. Finally, if nothing matched, the message goes to triage, a human review queue, not the void.
Catch-all addressing and apply-only mode
One design question took real thought: if every job can have its own address, must the customer buy an email address per opening? That would be absurd. So we use a catch-all subdomain, something like apply.company.com, where any address resolves, and we encode the job in the local part of the address. One domain routes every role and every candidate, the same model the large ATS platforms use, at zero per-job cost. We also learned the hard way not to lean on plus-addressing, the info+code@ trick, because it simply does not work on some common providers; subject codes and a real catch-all subdomain are the robust primitives.
Many customers point the system at an inbox that also receives ordinary business mail, where turning every message into an application would be worse than useless. So we built apply-only mode: when it is on, the engine ingests a message only if it carries a genuine hiring signal, a job code, a per-job address or a reply from a known applicant, and quietly ignores everything else. It turns a general-purpose inbox into a hiring channel without asking the customer to create a dedicated one.
The safety net is the whole point
The most important rung is the last one. Triage means the routing engine is never forced to guess wrong. When no rule matches confidently, the message is not misfiled and it does not vanish; it lands in a review queue where a human assigns it to the right job in one click. That single design choice changed how confidently we could build everything above it.
Because the failure mode of the ladder is a person taking a quick look, not a candidate being lost, we could ship a deliberately simple set of rules and add sophistication over time without ever risking the outcome that matters. The result is a routing system a recruiter can reason about and a company can grow into: predictable behaviour, no lock-in to a proprietary address, and a smooth path from just watching an inbox to full per-job addressing. The inbox stays ambiguous, as inboxes always will; the pipeline downstream of the ladder is certain.