Email warmup is not a score
Email warmup is the controlled increase of sending activity for a mailbox while its reputation is watched. If a dashboard gives you a warmup score but can't tell you which mailbox is struggling, that score isn't doing much.
Here's the situation I see fairly often. A 12-person SaaS company adds eight new sales mailboxes before hiring three SDRs. The team starts warmup across all eight accounts, watches the pool score move into the "healthy" range, then launches a campaign. Two mailboxes begin bouncing because their domain records are wrong. The other six look fine, so the shared score stays reassuring. The team keeps sending from the broken accounts for another day.
That isn't a warmup problem in the abstract. It's a mailbox-level monitoring failure.
Providers evaluate sending behavior at the mailbox and domain level. A shared pool can show that activity is happening. It can't reliably tell you whether a particular account can handle its next campaign.
Why shared pools hide the useful warning
A shared warmup pool groups mailboxes together and treats their activity as a collective signal. That makes setup look tidy. It also lets healthy accounts dilute a problem.
Say seven mailboxes are behaving normally and one has weak sender authentication. The pool may still look active and stable. Nothing about that average tells you where the failure is, when it started, or whether the affected mailbox should be paused.
The same issue shows up when sending volume changes. One mailbox may have a month of consistent activity behind it. Another may have been created yesterday. Putting both on the same ramp because they belong to the same team is lazy operations, not risk management.
Per-mailbox reputation means tracking the account that actually sent the message. That includes its sending history, volume ramp, provider response, domain routing and authentication state. The mailbox beside it is not a useful comparison unless the underlying conditions are similar.
My view is blunt: teams get this wrong when they treat warmup as a score to improve instead of a set of controls to operate. A number can be useful for spotting a trend. It should never be the reason you keep sending.
If one account regresses, the first response should usually be local. Pause that mailbox, inspect its domain and authentication, and check what changed. Pausing every account may waste healthy capacity. Continuing every account because the pool still looks good is worse.
Email warmup should start before the campaign
Warmup is often handed to the campaign operator as the final step after somebody else buys the domain, edits DNS and provisions the mailboxes. That handoff is where the gaps appear.
A small B2B software company might buy three domains on Monday, add 15 Google Workspace mailboxes on Tuesday and ask an SDR to start warmup on Wednesday. By Thursday, the SDR discovers that one domain is missing the right sender policy and another has a routing problem. The warmup schedule wasn't the issue. Nobody had a complete view of the sending setup.
Domain ownership, DNS, mailbox access and warmup aren't separate jobs. They affect whether the mailbox is ready to send in the first place.
Workloom provisions and watches domains, mailboxes, warmup and deliverability as one setup. Buying the domain, writing the DNS zone, provisioning the mailboxes and starting warmup happen together. That gives operators one place to see the conditions behind mailbox health instead of making them reconstruct the setup from tickets and browser tabs.
DNS is abstracted across two backends and chosen per domain. Live domains can move one at a time without a sending gap. The useful part isn't having another settings screen. It's reducing the chance that a DNS change becomes a hidden reason for a mailbox to fail.
Mailbox access needs the same treatment. Workloom acts for each mailbox directly, so a team member doesn't have to click through an OAuth consent screen for every account or discover an expired token when a campaign is supposed to start. Access isn't a one-time prerequisite. It can break the sending process later.
Ramp volume for the mailbox that will send
A warmup control is only useful if it changes activity for the account that will eventually carry campaign volume.
Workloom's warmup intensity has five steps, from paused to maximum. That gives an operator a direct way to slow down one mailbox without slowing down the rest. A newly provisioned Microsoft mailbox shouldn't necessarily move at the same pace as an older Google mailbox with a stable sending history.
The dial still needs observation behind it. If a mailbox starts returning more failures after a volume increase, reducing the intensity is a reasonable first move. If the domain's authentication breaks, lowering the dial isn't enough. Fix the domain and stop sending until it is healthy.
Rate control is another separate concern. Each mailbox has its own limiter, keeping the account inside its provider ceiling of 250 operations per second. That ceiling is a capacity guardrail, not a reputation score. It prevents the sending process from acting as though every mailbox has unlimited throughput.
Warmup traffic also needs to stay out of campaign reporting. Workloom tags warmup mail when it arrives, so those messages don't inflate inbox activity, reply rates or campaign results. This sounds minor until a team starts making decisions from contaminated data. If test replies are counted as prospect replies, the campaign looks better than it is. Then the team increases volume based on a false signal.
A warning is only useful if it changes behavior
Deliverability shouldn't be a panel someone checks when they remember. If a domain has a routing or authentication problem, the system needs to catch it and stop the relevant sending before the next campaign continues.
Workloom re-checks every live domain every six hours. When mail routing or sender authentication regresses, campaigns pause automatically. That trigger matters more than a warning sitting in a dashboard, because it changes the sending state while the problem is still current.
The response still needs to distinguish between different failures. A mailbox limit, a routing failure and a sender authentication failure are not interchangeable. One may call for a lower ramp. Another may require fixing DNS. Another may affect several mailboxes on the same domain.
That is why domain and mailbox state should stay connected. A domain-level problem can affect multiple accounts, but the operator still needs to know which mailboxes sent recently, which ones are paused and whether the failure is local or shared.
The practical test for an email warmup system is straightforward: can it show you which mailbox is healthy, which one isn't, what changed, and whether sending stopped because of that change?
If all you get is a pool score, you have a dashboard metric. You don't have much control over reputation.