Multi Tenancy Email Routing

Multi-tenancy: email routing & mailboxes

Part of the Multi-tenancy section. Built — live on the multi-tenancy branch. See the progress tracker.

When a multi-tenant install receives an email, it has to decide which company the ticket belongs to. This page explains how — and how it bends to very different ways of working. Everything below is now implemented (the only routing piece still to come is outbound reply identity).

Domains belong to the company, not the mailbox

Each company registers the email domains it owns — acme.com, and maybe also acme.co.uk. A company can own several domains. Mailboxes do not own domains; companies do.

Every mailbox is one of two types

This is the heart of it — and a perfect example of flexibility living in the entity rather than a global switch. Each mailbox is set up as one of:

1. Pinned mailbox — "this inbox belongs to one company"

• You assign the mailbox to a specific company (and optionally a department).
• The mailbox decides the company. The sender's address is irrelevant — everything arriving here belongs to that company.
• It's also the reply identity: replies to its tickets go back out from this mailbox, so the client sees their own helpdesk end to end.
• Great for: a single company's own helpdesk, or an MSP that dedicates a separate inbox to each client.

2. Shared intake mailbox — "one inbox, sorted by sender"

• The mailbox is not pinned to a company.
• An arriving email is filed by matching the sender's domain against the companies' registered domains (someone@acme.com → Acme).
• An unmatched sender drops into the triage queue (below) — never lost.
• Great for: an MSP running a single professional address like support@themsp.com for all clients. This is the recommended default for MSPs.

A ticket remembers which mailbox it came in on, and replies always go back out from that same mailbox — the mailbox is the company's email identity, both inbound and outbound.

A company can use both at once

A company isn't locked into "one mode". Acme might receive most mail via the shared support@themsp.com and have a dedicated helpdesk-acme@themsp.com for VIPs. Both feed Acme. That's exactly why the pinned-vs-shared choice lives on the mailbox, not on the company.

How an incoming email finds its company (in order)

1. Is it a reply to an existing ticket? → it joins that ticket and inherits its company. (A thread stays glued to one company even if someone replies from a different address.)
2. Did it arrive in a pinned mailbox? → that mailbox's company. Sender ignored.
3. It arrived in a shared intake → match the sender's domain to a company. No match → triage.

In a single-company install only step 2 ever fires, which is why none of this is visible until you add a second company.

The triage queue (the safety net)

When a shared-intake email matches no company domain, it lands in a Triage / Unassigned queue rather than vanishing. From there an analyst can, in one click:

• Create a new company from this domain — and the queued email (plus any others from that domain) is filed under it, with all future mail auto-routing from then on.
• Assign it to an existing company — e.g. a client that just started using a new domain.

Free-email senders

Addresses like gmail.com or outlook.com also land in triage — but you should never map a free-email domain to a company (two different clients will both have users on Gmail). In the queue these are tagged Public email and the "route this domain" option is disabled, so they can only be filed by hand, one at a time. See Pitfalls.

The triage queue is reached from the company switcher in the header, which shows a count badge when mail is waiting.