Email routing software: who owns each message, and what breaks

Your support address takes 80 messages a day and three people answer them. That means somebody decides, 80 times, which of the three owns each message. If nobody decides on purpose, the queue decides by default: whoever's looking takes the easy ones, the awkward ones sink, and the customer who needed the awkward one waits two days for a reply that starts with an apology.

That decision is the whole job of email routing software. Not how urgent the message is, not what kind of record it becomes. Just: whose name goes on it.

Two quick disambiguations, because the phrase does triple duty. If you're looking for how a message travels between mail servers, MX records and SMTP hops, that's the transport meaning and this isn't that page. If you're looking for an API that parses inbound mail into JSON and posts it to a webhook for an app you're building, that's developer intake, and that isn't this page either. This is about a shared address and a team of humans.

The short version:

• Three of the four layers that can route mail can only route it to a place. Only the layer that sits on top of the mailbox can route it to a person, because it's the only one that knows who's on shift.
• Round robin counts messages, not work. Equal counts can mean triple the workload, and the arithmetic below shows how fast that happens.
• Your platform already routes. What it can't do is name an owner, and its limits fail silently: a redirect rule pointed at too many people isn't applied at all.
• Measure your misroute rate by hand before you buy anything. No vendor can tell you what it is, and it's the only number that says whether routing software paid for itself.

What email routing software actually decides

Email routing software decides which person or queue owns an incoming message, and then makes that ownership visible to everyone who can see the mailbox. It's the assignment layer. The decision it makes is "who", and it makes that decision either from rules you wrote or from a model reading the message.

That's worth separating from the two jobs it gets confused with, because the three get sold together and bought together, and knowing which one you're short of saves you a purchase.

You can run triage without routing: one person sorts the queue every morning and shouts, and for a small team that's a legitimate answer. You can run routing without tickets: a shared inbox with an owner field and no states on it. Most teams end up wanting all three.

Four places a routing decision can be made, and only one of them knows who's free

Mail can be pointed at a destination in four different layers, and they have wildly different amounts of information to work with. This is the table to hold in your head, because almost every "why didn't that get to me" conversation is really a question about which layer made the call.

The domain layer is the one most teams have never looked at. Cloudflare's Email Routing, for example, routes "incoming emails sent to your domain to existing mailboxes, Workers for processing, or other destinations", with every destination address verified by clicking a link in a confirmation mail. It's genuinely useful for getting support@ and billing@ off a hosting plan and into a real mailbox, and it's capped at 200 routing rules per domain and 200 verified destination addresses per account. But it ends at the mailbox door. It answers "where does this land", never "who answers it".

The provider layer is where most of the real routing already happens, and it's also the layer people most often mistake for an ownership tool. If you want the deeper read on what it can and can't decide, what the provider layer can and cannot decide covers the sorting side of the same question, and it slices the same stack a different way, by where a sorting decision gets written, not by who can see availability. Here the point is narrower: a mail flow rule can put a message in front of your whole team, but it has no field for one person's name.

What belongs in a rule, and what needs a model

A routing engine picks an owner from facts. The useful question isn't "rules or AI", it's which facts are stable enough to write down.

Rules are best for facts that can't be wrong. The alias the message was sent to. The sender's domain. Group membership. Whether there's an attachment. The hour it arrived. Account tier, when that tier comes from your billing system and not from a guess. These are deterministic: write the rule once and it keeps being right, because the fact doesn't change shape.

A model is best for intent, which is the thing rules are worst at. "My order hasn't turned up" and "where is my stuff" and "still waiting on #4471" are one routing decision and three unrelated keyword sets. You can approximate it with a keyword list, and you'll be editing that list forever.

The trap in the middle is content-based rules: routing on words in the body. They're the brittle kind. Every one you write is a small ongoing tax, and they fail in the direction that hurts, which is silently sending a cancellation to the order-status queue because it happened to contain the word "order". If you want the honest account of where a classifier fails, and why it fails that way, that's a separate page, because classification quality is its own subject.

Classifying a message and handing it to a named person are closer to one job than two, and some tools do both in a single pass. TriageFlow assigns incoming mail to a person based on your team's structure, and its Smart Rules hand a thread off to a teammate or archive it outright. Whatever you use, check whether the label and the owner get set by the same pass or by two systems that can disagree.

Round robin and its three honest upgrades

Round robin is the default answer to "who gets this", and it's the feature most likely to be named on a pricing page. Here's what it actually does: it hands the next message to the next person in a rotation. It counts turns.

Counting turns isn't counting work, and the gap opens up faster than people expect. Say 30 messages come in and you've got three people, so everyone gets 10. One of them happens to catch three billing disputes at roughly 18 minutes each plus seven order-status questions at 2 minutes: that's 68 minutes. Another catches ten order-status questions: 20 minutes. Same count, more than three times the work, and the dashboard says the distribution was perfectly even. By Thursday one person is behind and nobody can point at why.

So there are three upgrades on plain rotation, and it helps to know them by name, because vendors use the words loosely.

Load-aware is the upgrade worth asking about most carefully, because there are two versions of it and only one helps. Counting a person's open threads includes everything they're waiting on a customer to answer, which isn't work. Counting the threads that are open and waiting on a reply from you is the number that reflects the actual queue in front of them. Ask which one a tool uses. The answer is often "open threads", and the people who answer carefully are the people whose customers reply slowly.

In practice most small teams want these stacked, not chosen between: continuity first so returning customers keep their person, availability as a hard filter so nothing lands on someone who's off, load to break the tie, and rotation underneath as the last resort. And if your tool only does plain rotation, you can fake most of availability-awareness by pulling people out of the rotation by hand when they're off. That's fine at three people and absurd at eight, which is roughly where teams start paying for this.

Skill, language and tier routing: when it earns the configuration

Skill-based routing sends a message to someone who can answer it rather than someone who's merely free. It's the feature that sounds obviously correct and is often a net loss, so it's worth being blunt about the threshold.

It earns its keep when two things are true at once: you've got at least two people who genuinely can't do each other's work, and enough monthly volume in the specialist category that misrouting it costs real time. Below that, you're maintaining a matrix to prevent a handful of forwards. Six skills across eight people is 48 cells that somebody has to keep current as people learn things and leave, and nobody ever does. The team that's honest about this writes down two skills, not six.

Best for a small team: tier routing, not skill routing. Account tier is the strongest routing fact most teams have, because it lives in your billing system rather than in the message, it's never ambiguous, and it maps cleanly onto who should answer. One rule, no matrix.

Language is the other one worth doing, because it's the rare content fact that's stable: a message is in German or it isn't, and most tools detect it without a keyword list. If you've got one person who handles German and five who don't, that single rule removes a whole category of misroute.

Skip for now: sentiment routing and priority-based assignment, if the price is a matrix. Urgency is better handled in triage, where it sorts the queue everyone can see, than in routing, where it picks one person.

The second message: replies, reopens and handovers

Routing products get demoed on first contact and lived on follow-ups, which is why this section exists. Every one of these is a question to ask out loud during a trial.

Does a reply stay with its owner, or go back through routing? Both answers are defensible. Sticking with the owner is right for continuity and wrong when that person is off for a week. Re-routing is right for availability and wrong when a customer gets a third stranger in one thread. What's not defensible is not knowing which your tool does.

What happens to a thread that's reopened after being closed? If it's treated as a brand new message, your customer's follow-up to a resolved refund lands on whoever's next in the rotation, with no memory of the conversation. Ask specifically.

Does a handover carry anything with it? Reassigning a thread moves a row in a database. Moving the context is a human act, and the tools that help are the ones with an internal note that travels with the thread. The agreement about what a handover has to include is a team-process question, covered in the team email management playbook.

Then there's the out-of-office hole. An automatic reply is something the mailbox sends after delivery, so a rule that routed the message in transit never sees it: at the provider layer, out-of-office genuinely isn't a routing input. A tool sitting on top of the mailbox is in a different position, because the out-of-office state is a mailbox setting it can read, alongside a shift schedule or a calendar. Ask which of the three yours uses. If the answer is none of them, routing will keep assigning to someone who's in Croatia, and the only sign is that their queue grows and nothing in it moves.

One more trap specific to the provider layer. Google draws the line between forwarding and redirecting precisely: with a redirect, "Messages aren't delivered to the original recipient", and there's a detail in the headers worth knowing, because "The To: address in redirected messages includes the original recipient address only". The customer's address is still in From, so a plain reply reaches them normally. What the header affects is everything built on To: a reply-all pulls in the address you routed away from, and whoever answers has to pick a send-as identity by hand, because the message in front of them was never addressed to them. Redirect support@ to an individual and their replies go out under their own name unless somebody sets that up deliberately.

What happens when two rules match the same message?

Both platforms document what happens when two of your rules match one message, and the models differ enough that administering both will catch you out. The short version: Google has no way to stop at the first match, and Microsoft has one but you have to ask for it.

The row to read twice is the first one. Out of the box the two platforms are closer than people assume: every matching rule applies, in priority order. The difference is the escape hatch. Exchange offers a per-rule "stop processing more rules" setting, and Microsoft frames the choice as a real question, "which rule do you want applied to the message? All? Just one?". Turn it on and you've built a waterfall, where a broad rule sitting above a narrow one will swallow it. Leave it off and a single message can be acted on by three rules that each thought they were in charge. Google has no equivalent, so on Workspace you're always designing a set rather than a sequence, and two settings firing together is the normal case to plan for.

Two small Exchange details worth knowing before you debug anything: a mail flow rule created in the admin center is disabled on creation ("By default, the status of mail flow rule is disabled when you create them using EAC"), which is a mercy, and the report you'd use to check whether rules fired carries the caveat that "while most data is in the report within 24 hours, some data may take as long as 5 days to appear". Plan your test window around that, not around your patience. The propagation delay and the missing rule history are covered where the provider layer gets taken apart properly.

Escalation is routing with a clock on it

Escalation is usually filed under SLAs, and the clock half genuinely belongs there: what starts it, what stops it, business hours or calendar hours, and what you promise per tier all live with the response targets your team can actually hit. But the thing that happens when the clock runs out is a routing decision, and it's the one most teams have never specified.

Four questions, and the fourth is the one that bites:

1. Does it land on a person or on a role? A named senior person is a single point of failure with a holiday calendar.
2. What happens to the current owner? Removed, or kept on the thread as a watcher? Removing them loses the context; keeping them means two people think it's handled.
3. Does the customer see anything? Usually they shouldn't, but if your escalation changes the sending identity, they will.
4. What if the escalation target is also off? This is the real failure mode. An escalation path that reassigns to one named person is a rule that stops working the week they take leave, and nothing alerts you, because from the system's point of view the escalation succeeded.

Escalate to a role with at least two people in it. If you can't name two, you don't have an escalation path, you have a favor you're asking of someone.

What breaks in production: the published limits

This is the part vendor pages can't write, because the numbers belong to Microsoft and Google and most of them describe a failure you won't notice. Everything here is from the platforms' own documentation.

Microsoft publishes a limits table for transport and inbox rules that's identical from Business Basic up to Enterprise E5. The numbers matter less than the consequences:

The forwardee limit is the one to write on a sticky note. In Microsoft's words: "If a rule is configured to redirect a message to more than this number of recipients, the rule can't be applied and any message that satisfies the rule condition can't be redirected to any of the recipients listed in the rule." Point a redirect rule at eleven people and it doesn't partially work. It doesn't work at all, and every message that matches it goes unrouted.

The single-redirection ceiling breaks a chain silently, and the exact scope of the damage matters here. Microsoft's example: User A's inbox rule redirects to User B, User B's rule forwards to User C, and "the message is only sent to User B; it's not forwarded to User C because only one redirection is allowed. In this case, the message is dropped without sending a non-delivery report (NDR) to User B indicating that the message wasn't delivered to User C."

Read whole, that says the mail isn't lost. It's in User B's mailbox, where the first rule put it. What fails is the second hop, and the failure is invisible from both ends: User B is never told the onward copy didn't arrive, and User C has no idea anything was addressed to them. So when a queue mysteriously stops receiving things after a couple of reorganizations, the mail is usually findable, one hop upstream, in the mailbox the first rule pointed at. The transport-rule version of the same loop is kinder, because somebody does get told: it returns 550 5.7.128 TRANSPORT.RULES.RejectMessage; Transport rules loop count exceeded and message rejected, and in Microsoft's example that lands on the original recipient whose mail was being redirected, not on the outside sender.

And if a rule can't finish evaluating, the default is that it's skipped: "By default, the rule will be ignored, but you can choose to resubmit the message for processing." Worth changing deliberately rather than discovering.

On the Google side, the caps are about volume rather than complexity. Forwarding is limited to 30 million operations per organization in a 24-hour period and 600k per 1-minute window, and the same page notes that "forwarding also includes redirects", so the two share one budget. Recipient addresses across all address maps top out at 5,000. Both figures come with the same warning attached, which is the part to plan around: "depending on your email sending practices, we might reduce forwarding limits for your Google Workspace account", and Google says the same about the recipient address limit for a domain. Treat them as ceilings you might not get, not as an allowance. There's an audit detail in the routing settings that's genuinely useful: the X-Gm-Original-To header, which adds "a header tag if the recipient is changed, so the receiving server knows the original envelope recipient". Turn it on. It's the difference between debugging a misroute in ten minutes and arguing about it.

One more Google number, because it's a routing outage disguised as a mail problem: a Gmail account can receive 60 messages per minute, 3,600 per hour and 86,400 per day, and when a limit is hit "the restriction on getting new mail typically lasts for about 24 hours". A bounce storm or one bad marketing blast aimed at a single shared address can take that address out for a day, which no amount of clever assignment logic will help with.

The pattern across all of these: platform routing fails quietly. There's no dashboard that says "47 messages went unrouted this week".

Three classes of routing software, and what each costs you

Worth saying plainly before this section recommends anything: we sell a shared inbox, which is the second of the three classes below. That's a reason to read this with your guard up, and also the reason class one is listed first and honestly, because for a lot of teams it's genuinely enough and it's already paid for.

Platform built-ins. Workspace routing settings, Exchange mail flow rules, groups, shared mailboxes. Best for: getting mail to the right mailbox or the right group, reliably, for nothing extra. What it costs you: no owner concept at all, no visibility into who's free, and every limit in the section above. You'll know you've outgrown it when the question stops being "where does this land" and becomes "who's answering it".

A dedicated shared inbox layer. Sits on top of the mailbox you already have and adds assignment, states, internal notes. Best for: teams of roughly 2 to 15 whose actual problem is ownership. What it costs you: a per-seat bill, and routing capability that varies a lot between products at the same price.

A full helpdesk suite. Best for: multiple channels, many queues, formal SLA reporting. What it costs you: weight. The routing is usually the deepest of the three, and you're buying a ticketing model and a configuration project along with it.

Routing capability is only one of the criteria you'd actually buy on, and it sits at a different pricing tier in every product. The full buying decision for a shared inbox covers the rest of it, including what to put in a trial and the questions that get you out of a bad fit.

Questions to ask, and a two-week test on your own mail

Phrase these so a demo can't answer them with a feature name:

1. When two of my rules match one message, which one wins, and can I see that decision afterwards?
2. Does load balancing count open threads, or open threads waiting on a reply from us?
3. Where does availability come from: the mailbox's own out-of-office setting, a shift schedule, a calendar, or whether someone's logged in?
4. Does a customer's reply stay with the owner, or get re-routed?
5. What happens to a thread reopened a month after it closed?
6. Can escalation target a role rather than a named person?
7. What's logged when something is reassigned, and can I report on reassignments?
8. Show me a message that was routed wrongly last week in your own demo data, and show me how I'd find it.

Then the test, which matters more than the answers. Get a baseline by hand first, because no trial will give you one and no vendor can tell you what yours is.

Take last week's real mail from your shared address. For each message, note who ended up answering it and whether it got reassigned before the first reply went out. Two numbers come out of that:

• Misroute rate: threads reassigned before the first reply, divided by total threads. This is your current cost of not routing.
• Time to first owner: how long a message sat before anyone's name was on it. Usually much worse than time to first reply, and usually the one nobody's measuring.

Run a trial for two weeks on the same address and recompute both. If the misroute rate doesn't move, the tool is selling you assignment you were already doing correctly by hand, and you can stop.

If you want a rough sense of what the status quo costs in hours before you start, our shared inbox ROI calculator takes three steps of input: team size and hourly cost, then emails per day and average handling time, then what you use today. It returns hours per week, and savings per month and per year. Be clear about what it is: it folds routing into handling time and it knows nothing about your misroute rate, so it estimates the cost of your current setup rather than comparing routing options.

Verdict on your own two numbers: a misroute rate in the low single digits means your team already routes well by hand, and a tool will mostly formalize what you're doing. Double digits, or a time to first owner measured in hours rather than minutes, is the case for buying. The numbers also tell you which variant you need: misroutes concentrated in specialist topics point at tier or language rules, misroutes spread evenly across the queue point at availability.

When you don't need routing software

Some thresholds, stated plainly.

You don't need it if two people share an address and sit in the same room. You're a sentence away from a decision at all times, and the overhead of a tool exceeds the cost of asking.

You don't need it if every message that arrives can be answered by anyone. Plain rotation solves a problem you don't have, and your real bottleneck is probably reply templates.

You don't need it yet if your volume is low enough that one person can sort the whole queue in ten minutes each morning. What you need then is for that pass to be written down and actually happen, not software.

You do need it when any of these is true: somebody is regularly surprised by a thread that was theirs, a reassignment happens more than a few times a day, or a message has sat unowned long enough that the customer followed up to ask if anyone's there. That last one is the real signal, and it's the one that shows up in your inbox rather than in a report.

Frequently asked questions

What is email routing?

The word covers three different things, which is why searching for it returns such a mess. In transport terms, routing is how a message finds the right server. For developers, it's an API that catches inbound mail and hands it to an application. For a team with a shared address, which is what people mean when they go shopping for software, it's how a message finds the person who should answer it. This page is about the third.

What's the difference between email forwarding and email routing?

Forwarding sends a copy on and leaves the original where it was, so the first recipient keeps getting their mail. Redirecting moves the delivery, and Google states it plainly: "Messages aren't delivered to the original recipient." Routing in the team sense is broader than either, because it also decides who owns the thread once it has landed somewhere.

Can you route emails automatically in Outlook or Microsoft 365?

Yes, at two layers. Mail flow rules work tenant-wide while the message is in transit, and inbox rules work inside one mailbox after delivery. Both can move a message somewhere; neither can put a person's name on it or notice that the person is on leave.

Is email routing software free?

The delivery kind usually is, because it's a setting in a plan you already pay for, and domain-level forwarding is free on free plans. The ownership kind generally isn't, because it's sold per seat. That's the honest split: moving mail is free, knowing who owns it is the thing you pay for.

How do I route emails to different people based on content?

Write rules only for facts that can't be wrong, like the alias, sender domain, detected language or account tier, and use a model for intent. Keyword rules on the message body are the brittle middle: they work the day you write them and fail quietly as customers phrase things differently.

What is intelligent email routing?

"Intelligent" is a sales word rather than a technical one, and it usually covers one of two different things: the owner gets picked by a model reading the message instead of by a rule you wrote, or the pick takes account of who's actually available and how loaded they are. Those are separate features with separate price tags, so the useful follow-up is which of the two is on offer.

Does Gmail have email routing?

Google Workspace does, at the admin level: routing settings and default routing can change where an inbound message is delivered, add recipients or reject it outright, and they apply across the organization rather than to one person. Gmail itself has filters, which work inside a single mailbox after delivery. Neither records an owner, so nothing in either one can tell you that a message belongs to one named person who hasn't replied yet.

What is round robin email routing?

A rotation: the next message goes to the next person in the list. Its flaw is that it counts messages rather than work, so three hard tickets and seven easy ones look identical to ten easy ones. Load-aware, availability-aware and continuity-aware assignment are the three upgrades on it, and most teams want them stacked rather than picked between.