Managing deliverability for multiple clients without losing the thread

An agency's deliverability problem is not technically different from a founder's. The mailboxes warm the same way, the DNS is checked the same way, the placement is measured the same way. What is different is attribution: which of these numbers belongs to which client, who on your team is allowed to touch them, and what you can put in front of the client on Friday.

Most teams hit this in the same order. First you run everything from one login. Then the dashboard average stops meaning anything, because it is averaging a client whose domains are eight months old against one who onboarded last week. Then someone pauses the wrong warmup. Then a client asks for their numbers and you are filtering a CSV by domain suffix at 6pm.

The blended-average problem

A single account-wide reputation score across clients is not a slightly worse number. It is a number that can move in the opposite direction to every client it contains.

Take eleven clients. Ten are healthy and static. One onboards 40 new mailboxes, all starting from zero reputation as they should. Your account average drops, so the dashboard says deliverability is getting worse. It is not. Nine clients are unchanged and the tenth is doing exactly what warmup is supposed to do. The average is reporting a composition change as a performance change.

The reverse is worse, because it is quiet. One client's domain gets listed and their placement collapses. Spread across 300 mailboxes, that is a two-point move in the account average — inside the noise you have learned to ignore. You find out when the client tells you.

The fix is not a better average. It is not averaging across clients at all.

Separate the mailboxes, not the accounts

The obvious workaround is one login per client. It works, and it costs you: separate billing, separate logins to hand around, no view across the book of business, and a new account to provision every time you sign someone.

The better shape is one account where every mailbox belongs to exactly one client, and every view is scoped to one client at a time. Switch to Acme and the dashboard, the mailbox list, the placement report, domain health and the exports are all Acme — not Acme highlighted inside everything else.

Two properties matter more than they sound:

A mailbox must always belong to somewhere. If "unassigned" is a state a mailbox can sit in, you will eventually have mailboxes nobody is looking at — still sending, still consuming your plan, appearing in no client's view. An orphan is not an unfiled record, it is an invisible one.

Switching has to actually switch. If the sidebar says Acme while the page still shows Beta's mailboxes, the separation is cosmetic and worse than none, because now you trust it. This is the part that is easy to half-build: the filter applies to the list you were looking at when it was written, and not to the four screens added since.

Access is per client, not per account

The second half of the problem is people. An agency account is not one person's account. It has a strategist who should see everything, a junior running warmup schedules on two clients, and a contractor who needs numbers for a report and should change nothing.

"Share the login" fails on the day someone leaves. It also fails quietly before that: everyone with the login can change billing, mint API keys, and pause any client's warmup.

What works is access granted to one client, in two strengths:

• Editor — can see that client's mailboxes and run their warmup: start, pause, tune the schedule, edit the content, connect new mailboxes to that client. This is the person doing the work.
• Viewer — sees exactly the same data and can change nothing. For the person writing the report, or the account manager who should never accidentally pause a sequence.

Both must be real accounts with their own login, not a shared password. And both must be unable to reach the things that belong to the agency rather than the client: billing, API keys, the other clients, and the list of who has access.

That last one is worth stating as a rule, because it is the one teams get wrong: only the account owner manages people. If an editor can invite another editor, your access list grows without your knowing, and if an editor can remove people, the owner can be removed from their own account.

What this does not solve

Three things, because an agency evaluating this should know where the line is.

It is not a client portal. Giving your own staff scoped access is a different feature from giving the client a login to a branded dashboard of their own. If reselling a white-labelled view is the requirement, per-client teammate access does not deliver it. A CSV export of that client's placement and reputation data is what you hand over instead.

It does not change the plan limits. Separating clients is organisation, not capacity. The daily warmup volume your plan allows is still the account's, shared across every client in it. Signing a client with 60 mailboxes does not become cheaper because they are in their own workspace.

It does not warm faster. A new client's domains take the same time they would in any other arrangement. The benefit is that you can now *see* that they are on track, instead of watching their ramp disappear into an account-wide average.

A structure that holds up

If you are setting this up from scratch, the order that causes the least rework:

1. One workspace per client, named as the client is named in your CRM. Not by domain — clients change domains and run several.
2. Assign every mailbox on day one, including your own agency mailboxes. Your own sending is a client too; it is the one you will otherwise neglect.
3. Invite staff per client, at the lowest strength that lets them work. Viewer is the default for anyone whose job is reporting. Editor for whoever owns the warmup.
4. Report per client, never per account. The account-wide number is for your own capacity planning. It should never appear in a client-facing document, because it is not about them.
5. Re-check the scope after you add a screen. The most common way this breaks is a new page that forgets the filter and quietly shows everything.

The test of whether you have got it right is simple: open the client, and be able to answer "how is this client doing" without filtering, exporting, or explaining which numbers to ignore.

MailPilot's client workspaces are built exactly this way — mailboxes grouped by client, every view scoped to one, and per-client editor or viewer access for your team, on every paid plan rather than an agency tier.