Warmup
How email warmup builds sender reputation, pools, and ramp.
Warmup sends small amounts of low-risk, natural-looking mail between participating mailboxes to build sender reputation, so your cold outreach lands in the inbox. You turn it on per mailbox and pick how fast it ramps; SendSets handles partners, spacing, replies, and safety.
Warmup is a paid feature
Free organizations can connect mailboxes, but no warmup traffic is scheduled for them; pending warmup activity is skipped rather than sent.
Why it works
Providers watch how an address behaves over time. A new address that suddenly bursts out cold email looks suspicious. One that sends a steady, modest, conversational stream and gets replies looks like a person. Warmup manufactures that history: low volume instead of spikes, natural spacing across the day, replies so threads look real, and slow growth. Reputation builds slowly and is lost quickly, so warmup favors patience over throughput.
How it works
With warmup enabled, SendSets repeatedly picks a partner mailbox (avoiding recent ones), decides whether to start a thread or reply to one, sends a short plaintext message through that mailbox's worker, then records stats and schedules the next send.
Every warmup send carries a hidden verification token so the receiver can confirm it is genuine warmup traffic. Warmup mail is plaintext and never carries open or click pixels, because it needs to look like ordinary personal email.
The token travels in a message header, and some providers do not pass custom headers on to the recipient. Microsoft in particular strips them in transit and replaces the message identifier, so a warmup email sent from an Outlook or Microsoft 365 mailbox arrives carrying no header at all. SendSets therefore also records what each send was addressed to, and the message identifier the provider assigned to it, and matches an incoming warmup email on those when the header is gone. Verification does not depend on any one provider behaving well, so warmup from every mailbox type counts, stays out of your unibox, and gets the same engagement.
Enabling warmup controls outbound scheduling only. An active mailbox with warmup off stays available as a recipient-only participant, and never starts sending just because it received something.
Warmup is the same for every mailbox, however it was connected: one you brought yourself and one SendSets provisioned for you both warm in the shared pools under the same ramp. A provisioned mailbox also keeps the provider's own warmup running beside it, reported as external_warmup for information; nothing routes on it. sendsets mailbox warmup enable <id> starts it from the terminal and sendsets mailbox warmup status <id> (or GET /emails/:id/warmup) reports its status, today's target and its pool standing.
Where the content comes from
Message generation stays off the live sending path. When an AI provider is configured, a background batch builds complete conversation plans (a subject, an opening, and five alternating reply turns), each validated against a strict schema, checked for robotic language, and passed through a safety lint before entering the active bank.
At send time a message draws from the least-used suitable thread and accounts for usage atomically, spreading content evenly across thousands of mailboxes. The opening is personalized with the mailbox's stable persona, greeting, sign-off, and signature; reply turns stay unused until the recipient actually replies. If generation is unavailable or the bank is empty, a built-in reviewed library takes over, so warmup never waits on an AI provider.
The controller runs every six hours against the last seven days of demand: at least 200 active threads, up to 5,000, refreshing the most-used content, at most 250 threads per batch and 1,000 per day. Threads are retired automatically when at least 3 of 20 or more sampled deliveries land in spam and the rate is 15% or higher. Admins monitor it but never refill it by hand.
Pools
A pool is the set of mailboxes that warm each other. Your mailbox exchanges warmup mail within its own pool, with one documented exception below. Every instance has both pools from install, so a self-hosted instance warms within its own pools from the first mailbox; SendSets Cloud is how it joins the hosted one instead.
| Pool | Who is in it |
|---|---|
premium | Paid organizations' mailboxes. The default for paid accounts, isolated from lower-trust traffic. |
free | Lower-trust or trial mailboxes, kept separate so free traffic does not mix into premium reputation. |
A mailbox belongs to exactly one pool at a time. When its plan changes the mailbox moves between pools rather than joining a second one, and it takes its warmup standing with it, so a quarantine or block is not cleared by changing tier.
The separation is crossed in exactly one direction, and never silently: when the premium tier runs thin (fewer than 25 other eligible recipients), it borrows up to 25 free-tier mailboxes that have been pool members for at least three days, are healthy now, and belong to a workspace in good standing. It prefers a fresh partner from its own tier before a borrowed one, and checks each borrowed mailbox against its own pool's standing before using it. The free tier never draws premium partners. The one piece of free-to-paid warmup mail that exists is a borrowed mailbox answering the thread the paid mailbox started, which is what makes the exchange read as a conversation; a restricted workspace may not send even that.
SendSets spreads sends across many partners and recipient domains rather than looping the same two mailboxes, since tight reciprocal pairs are easy for providers to spot. Pool quality matters more than pool size.
Self-hosted instances warm only among their own mailboxes unless they are linked to SendSets Cloud, which puts their enrolled mailboxes into these same pools. See SendSets Cloud for self-hosted instances.
Choosing partners
Within a pool, partners are picked by weight rather than at random. Three things move the weight:
- Domain spread. Recipient domains you have already used a lot recently are downweighted, so warmup does not loop through the same handful of inboxes.
- Where you are landing. SendSets tracks your spam-placement rate separately for each recipient provider over the last seven days, grouped by who actually runs that recipient's mail (Google, Microsoft, Yahoo and so on, the same grouping routing rules use). A mailbox landing in spam at Microsoft but not Google is sent fewer Microsoft partners until that rate falls, without waiting for an overall health band to trip.
- Your routing rules, when you have configured any. A rule's weight multiplies a partner's chance; a weight of
0is not a weight but an exclusion, so that pairing never happens.
An exclusion is honoured even when it leaves nothing: if every available partner is excluded by your rules, the mailbox sends no warmup mail that tick and tries again later, rather than mailing someone you ruled out because the pool had nobody else. The same holds when a partner writes first: your mailbox does not reply to an address your rules exclude. Rules apply to paid-tier mailboxes.
A struggling provider is downweighted, never excluded: a sender that stops mailing a provider entirely can never discover that it recovered there. A provider is only judged once you have sent it at least five warmup emails in the window, so one bad delivery out of two is treated as noise rather than a pattern. You can see the per-domain numbers this reads under Deliverability > Warmup placement by domain.
Turning off outbound warmup does not remove a healthy mailbox from the recipient pool. Disconnecting it, losing warmup-plan access, or entering a quarantined or blocked state does. Losing access removes the mailbox from its pool within minutes, whether or not it was still warming.
The ramp
| Setting | Default | Meaning |
|---|---|---|
| Start volume | 10/day | Warmup emails on day one |
| Daily increase | +1/day | How much the target grows daily |
| Ceiling | 40/day | Where the ramp stops climbing |
At defaults a mailbox sends 10 on day one, 11 the next, and levels off at 40 after roughly a month. You can change these per mailbox, but conservative defaults build the most durable reputation.
Four things shape the real daily number: sends are spread across your warmup hours with jitter, the target is capped by how many eligible partners exist, a mailbox whose health drops gets reduced volume and wider spacing until it recovers, and a recent spam placement holds the ramp where it is.
Holding the ramp on an early signal
If any warmup email lands in a recipient's spam folder, that mailbox stops climbing immediately:
- today's target is cut by about a quarter, for 48 hours
- the daily increase pauses for three days
- the paused days are subtracted rather than made up, so the ramp does not jump three steps in one morning when it resumes
Another placement during a pause extends it and does not lift the ramp: repeated spam placement can only ever slow a mailbox down.
Nothing needs to be switched on and no health band has to trip first. That matters because the bands need a sample before they can judge a mailbox at all (twenty warmup sends in seven days, a hundred delivered in thirty), which a mailbox in its first fortnight has not reached. Without this, the mailbox landing in spam on day three would keep adding an email a day until it had sent enough to be judged.
The two windows end at different times, so between 48 and 72 hours a mailbox is back at full volume while the ramp is still paused. The mailbox drawer says which of the two is happening, how many emails were affected, and when the ramp resumes. Restarting warmup resets the ramp and clears any hold with it.
Warmup and campaigns coexist
Keep warmup on after campaigns start. A mailbox backing a live campaign drops to at most five warmup messages per day, leaving the campaign as primary traffic. Warmup does not make repetitive or unwanted copy safe: you still need real targeting, personalization, suppression, and unsubscribe support.
Replies
Real inboxes reply, so a configurable share of the time a mailbox answers an existing warmup thread instead of starting one. For AI content SendSets reloads the original conversation plan and sends its next unused turn, with the conversation ID and turn number traveling on every verified send, so a reply continues the same exchange. A parent message is answered only once, and an exhausted or retired thread ends rather than repeating.
Replies thread properly with a real Re: subject and In-Reply-To header, and candidates must be between 45 minutes and seven days old, so nothing is answered instantly or revived indefinitely.
Receiving warmup mail can also prompt an answer directly. When a verified warmup email arrives, the recipient sometimes points its next scheduled send back at whoever wrote, 25 minutes to 5 hours later and inside its own warmup hours. That is a re-pointing, not extra work: each mailbox has one warmup send queued at a time, so a reply-back moves that send earlier and aims it, and can never push a send the mailbox had already planned sooner. The chance is the recipient's own reply rate, drawn once when the reply is scheduled rather than again when it sends, and it stops before a thread reaches its message cap so replies cannot answer replies indefinitely.
Timing imitates people throughout: sends come in bursts and lulls rather than a fixed rhythm, never land on round clock marks, and opens happen on a natural delay during the recipient's waking hours. No mailbox in the pool reads mail at 3am or reacts within seconds.
Keeping warmup out of your inbox
SendSets recognizes inbound warmup by its token and files it automatically, including for recipient-only mailboxes. The message moves to a dedicated SendSets folder and is usually marked read; anything that landed in spam is rescued first so the provider records a positive placement signal. This works across Gmail, Outlook via Microsoft Graph, and generic IMAP, and warmup mail never appears in your unified inbox.
The sender's Sent copy is also excluded from Unibox. A consumed or expired token still identifies warmup for inbox filtering, but cannot trigger engagement again. When the header is missing, a recorded message identifier can identify older warmup during history sync; the sender-and-subject fallback stays limited to recent inbound sends so an ordinary conversation is not hidden just because it shares a subject. Existing verified warmup entries are removed from Unibox automatically in background batches, without deleting mail at the provider or changing warmup standing.
If a provider syncs a headerless Sent copy before reporting its final message identifier, SendSets holds a possible match for verification. The send confirmation then identifies which message was warmup, and ordinary mail sharing its subject can enter Unibox. A matching subject alone never permanently hides a sent message.
Pool safety
Shared pools only work if participants behave, so every mailbox is judged on rates rather than raw counts: complaints, spam-folder placement, bounces, and tampering with warmup mail it received, such as deleting it or flagging it as spam. Each band needs a minimum sample before it acts, so a slow week cannot convict a mailbox and a busy one is not punished for its volume.
| State | Meaning | Effect |
|---|---|---|
healthy | Normal | Full volume |
watch | Mild concern | Spacing stretched modestly |
throttled | Probation | Volume cut, spacing widened until recovery |
quarantined | Clear problem | Out of the shared pool for a cooldown |
blocked | Serious or repeated abuse | Out for longer, review required |
Quarantined and blocked mailboxes are selected as neither sender nor recipient. Mail arriving in a mailbox is never held against it: every warmup message carries a single-use token bound to its recipient, so a token cannot be replayed or redirected, and one that lands where it does not belong is simply filed as ordinary mail.
Acting early protects everyone
SendSets intervenes well before providers would penalize a mailbox. One landing in spam a large share of the time is already dangerous to the pool, so it is throttled or removed rather than left collecting negative signals.
Getting back in requires requalifying, not just waiting: healthy authentication, no recent complaints or hard-bounce spikes, and spam placement back to a low level. Return is gradual, not a jump back to the old ceiling.
A quarantine or a block also holds for its full term. The signals behind it age out of their windows long before it ends, and that does not release it early; a more serious finding can still replace it. A throttle is different and lifts as soon as the mailbox recovers, as the table says.
The standing follows the address, not the connection. Removing a mailbox from the workspace and adding it back, or dropping out of the pool and rejoining, does not clear its score or its block: the same address in the same workspace rejoins with the standing it left with. That standing is kept for 90 days after the block ends or after the mailbox was removed, whichever is later; a block that requires review never lapses. A mailbox in good standing leaves nothing behind.
Graduating to cold sending
Warmup ending does not mean full cold volume the next day. A mailbox joining a campaign starts at a cold volume set by how long it warmed and adds 5 a day from there. See Easing out of warmup for the bands.
Recommended posture
- Start new mailboxes around
10/day and let the ramp climb slowly. - Do not raise the ceiling above
40casually. - Keep warmup running alongside campaigns, not only before them.
- Prefer more healthy mailboxes over pushing a few too hard.
- Watch complaints and spam placement, not open-rate vanity metrics.