Email warmup

Email warmup is not a score

Email warmup is the controlled increase of sending activity for a real mailbox and domain. It isn't a score you buy, and it isn't proof that every mailbox in a vendor's network is ready to send.

Here's the situation that exposes the difference.

An 18-person recruiting firm adds six mailboxes to a new outbound domain before a hiring conference. The vendor's dashboard says the warmup pool is healthy. Two days later, one mailbox starts sending campaign email and gets poor placement. The other mailboxes in the pool don't help much. They have different sending histories, different limits, and possibly different domain settings.

That's the part teams get wrong. They treat activity somewhere in a vendor's network as if it were reputation for the mailbox they own.

A useful warmup setup controls the actual mailbox that will send production mail. It also watches the domain, DNS configuration, delivery failures and sending limits around that mailbox. If it only gives you a number, you have a reporting screen, not much operational control.

The pool isn't your mailbox

A shared warmup pool groups mailboxes together and counts activity across them. It makes for an easy dashboard. One pool can be labelled active, healthy or ready, even when the mailbox you just connected has barely sent anything.

That activity doesn't automatically transfer. Mailbox providers can evaluate signals tied to the sender, the domain and the message stream. A mailbox that has never sent meaningful volume doesn't inherit a clean history just because another mailbox exchanged messages in the same pool.

There are other ways for the pool to hide the problem. One mailbox might send too quickly. Another might have malformed SPF. A third could be using a domain whose MX record was changed during a migration. The pool can continue producing activity while one of its members is taking the hit.

Per-mailbox warmup starts with a less convenient assumption: each sender needs its own controls and observations. Volume should be limited for that mailbox. Warmup intensity should be adjustable for that mailbox. A domain failure should be able to pause the campaigns connected to it.

This doesn't mean the mailbox has a reputation completely separate from its domain. It means the system isn't pretending that collective activity answers a sender-specific question.

A shared pool measures activity across a group. Per-mailbox warmup controls the sender that will actually run the campaign. Those are different jobs.

Start with the assets that will send

Warmup shouldn't begin with a generic pool. It should begin with the domain, DNS records and mailboxes that will carry the campaign.

For example, a 40-person software company might create four domains and 20 mailboxes before a new outbound push. The trigger could be a domain migration or a new sales team, not some abstract desire to improve a dashboard score. The sensible order is to set up each domain, write and verify its DNS zone, provision its mailboxes, then start activity against those specific mailboxes.

Workloom provisions and watches the domains, DNS, mailboxes, warmup and deliverability as one setup. The point isn't that every step happens in one screen. The point is that warmup remains connected to the configuration production mail will use.

DNS is provider-abstracted across two clouds and chosen per domain. That matters when domains need to be handled independently. If one live domain has a DNS problem, operators can work on that domain without moving every other domain through the same provider path.

The cloud count isn't the useful part. Per-domain placement is.

Mail access is part of the setup too. Mail runs through domain-wide delegation, with one service account acting for each mailbox. That avoids an OAuth consent screen for every individual mailbox. For a company provisioning 20 mailboxes, removing 20 separate manual approvals is more than a minor convenience. It removes a step that tends to break during setup.

None of this creates a clean reputation by itself. It does something more basic and more important: it makes the warmup process correspond to the mailboxes and domains that will send live campaigns.

The controls need to be boring and specific

A warmup system should limit sending at the mailbox level. A domain-wide setting is too blunt when several senders share a domain and have different histories.

The per-mailbox limiter matches the provider's 250 quota units per second ceiling. That's an operational boundary, not a warmup score. It controls how mail is issued for each mailbox, so one sender doesn't simply copy the pace of another.

Warmup intensity uses a five-step dial, from paused to maximum. That gives an operator a direct way to hold or change activity. Paused means no warmup activity. Maximum means the strongest configured intensity. The middle settings matter when a mailbox needs to advance gradually, hold its current pace or back off after a delivery problem.

This is where many systems become oddly vague. They advertise an automated schedule but don't explain what an operator can do when a mailbox starts behaving differently from the rest. A dial isn't sophisticated, but it is clear. Clear controls are easier to operate at 9:00 a.m. when a campaign is about to launch.

Warmup mail is tagged at ingest so it doesn't pollute the inbox or the numbers used to evaluate campaign mail. Keep that traffic separate from production reporting. Otherwise, reply counts, inbox review and campaign performance become difficult to interpret.

If the warmup system uses its own traffic to make the campaign look healthier, the measurement is compromised. That's not a minor reporting issue. It can lead a team to increase production volume based on numbers that include messages unrelated to the campaign.

DNS failures should stop sending

Warmup is not permission to keep sending through a broken domain configuration.

Every live domain is re-checked every six hours. If MX or SPF regresses, campaigns pause automatically. The pause is the important part. Detecting a bad record without stopping live mail just gives operators a notification while the system continues creating delivery problems.

Picture a company moving DNS from one provider to another on a Friday afternoon. The records look correct in the control panel, but the MX change hasn't propagated as expected, or an SPF include was dropped during the move. If the campaign keeps running until somebody notices, the warmup process has made the incident worse.

A per-mailbox view helps here because it connects the sender to its domain, limiter, warmup intensity and configuration checks. Operators can see which mailboxes are affected and pause the right campaigns. A pooled score doesn't create that relationship.

So when evaluating email warmup, ask practical questions. Which mailbox generated the activity? Which domain carried it? What limits apply to that mailbox? What happens when SPF or MX fails? Can the system pause live campaigns without waiting for someone to inspect a dashboard?

If the answers are vague, the score is doing more work than the system behind it.