Mailboxes

A mailbox is a sender account you connect to SendSets. Every warmup message and campaign email goes out through one you own.

Connecting an account

Open Accounts and choose Add account, or connect from the terminal (see From the terminal).

OAuth sends you to your provider's consent screen and returns a token instead of a password. Both OAuth providers use the provider's native API, never IMAP or SMTP, so consent asks to send mail and to read and organize your mailbox. Google additionally asks to read your mail settings, which is what lets SendSets offer the addresses Google has verified you to send as and import the signature you already wrote there. It needs no app passwords or server settings. Note that Google revokes Gmail tokens when the account's password changes, so a password change there means re-authorizing the mailbox once.

IMAP / SMTP needs host, port, username, and password for each direction:

SMTP   host: smtp.yourprovider.com   port: 465   username: you@yourdomain.com
IMAP   host: imap.yourprovider.com   port: 993   username: you@yourdomain.com

Each side also has a security setting, which is what decides how the connection is encrypted:

The form picks TLS or STARTTLS from the port as you type, so standard setups need no thought. It never picks None, on any port: dropping encryption is always something you ask for. Change the mode yourself when your server is unusual: any port from 1 to 65535 works, so a submission relay on 2525 or IMAP on a custom port is fine as long as the security setting matches what the server actually speaks.

Encryption is not optional over a network. SendSets will not send credentials over an unencrypted connection to anything but this machine, which is why None only appears once the host is localhost, an address in 127.0.0.0/8, or ::1, and only on a self-hosted instance. See local mail relays below.

If a mailbox fails to connect with a server-unreachable error and the host and port are definitely right, the security setting is the first thing to check. A server expecting STARTTLS looks unreachable to a client attempting implicit TLS, and vice versa.

When a mail server goes down or stops answering, the mailbox is not deactivated. SendSets says so once in the drawer, retries on a widening interval, and picks up where it left off when the server comes back. Nothing that arrived meanwhile is skipped, and the error clears itself on the first pass that reaches the server again.

The same holds for a server that answers but refuses what SendSets asked. The drawer shows one row carrying the server's own wording, not one row per retry, and it clears on the first pass that completes.

With two-factor authentication on, generate an app password in your provider's security settings and use that.

SendSets signs in with whichever method your server offers, preferring CRAM-MD5, then LOGIN, then PLAIN. Servers that accept only one of these, which includes Microsoft 365 relays and most appliance relays, work without any setting to change.

Local mail relays (Proton Bridge)

Some mail is only reachable through a program running on your own machine. Proton Bridge is the common one: it signs in to Proton Mail for you and re-serves the account as ordinary IMAP on 127.0.0.1:1143 and SMTP on 127.0.0.1:1025. It speaks no TLS a client can verify, because it never listens on a network interface in the first place.

SendSets connects to one of these with the None security mode, under two conditions that are checked when you save the mailbox and again every time the worker dials it:

• the host is a loopback literal: localhost, an address in 127.0.0.0/8, or ::1. A hostname that merely resolves to one is refused, because what a name resolves to can change after it is checked
• the instance is self-hosted, and the worker runs on the same machine as the relay

Both are about the same thing: the credentials never leave the machine, so there is no wire to intercept them on. On hosted SendSets the worker is in our infrastructure, never on your computer, so a local relay is not reachable from it and the mode is not offered. Run a self-hosted instance on the machine the Bridge is on if you need it.

Set the Bridge's own username and password, which it shows in its interface, not your Proton account password. The same applies to any relay on the machine: a Dovecot sharing a host with its worker, or a local sink used for testing.

From the terminal

The sendsets CLI connects a mailbox without the dashboard:

sendsets mailbox add --provider smtp_imap --email hello@acme.com --name Acme \
  --smtp-host smtp.acme.com --smtp-port 587 --smtp-pass "$APP_PASSWORD" \
  --imap-host imap.acme.com --imap-port 993 --daily-limit 20
sendsets mailbox add --provider gmail

An SMTP/IMAP credential is validated by a worker before it is stored, exactly as the form does. A Google or Microsoft mailbox still needs a person to approve the provider's consent screen: the command prints the link, and the mailbox appears once the consent lands, with the code never leaving the API. Afterwards sendsets mailbox test <id> dials the stored credential again and reports the mailbox as one checklist (SMTP, IMAP, authentication, sending status, limits, warmup, campaigns, recent errors), and sendsets mailbox get <id> shows the same facts without dialling. enable and disable switch it in and out of service. The agent quickstart runs the whole setup in order.

Managed mailboxes

On SendSets Cloud you can have mailboxes provisioned for you instead of bringing your own: Google or Microsoft inboxes on a fresh domain SendSets registers, connected to the workspace and warmed the moment they exist. The mailbox provider behind them is SendSets infrastructure; you never see or manage it.

sendsets mailbox provision providers
sendsets mailbox provision quote --provider google --count 5 --domain acme-outreach.com --warmup
sendsets mailbox provision --provider google --count 5 --domain acme-outreach.com --warmup --wait
sendsets mailbox provision --provider google --count 25 --domains a.com,b.com,c.com --warmup
sendsets mailbox provision status <provisioning_id>

providers lists what can be ordered and what each platform costs per mailbox, read live from the upstream provider rather than a fixed list. An order can span several domains with --domains, and the mailboxes are spread across them as evenly as possible, which keeps per-domain blast radius small. The quote is priced before anything is bought, at the upstream provider's live cost plus card processing and no margin (see billing); it holds for fifteen minutes, after which the prices are no longer guaranteed and you quote again. The order opens a checkout link for a person to complete (an API key whose agent policy does not cover the spend gets an approval link first), then walks through order accepted, domain configured, mailboxes created, added to SendSets and warmup enabled, which --wait renders as it happens. Delivered mailboxes start at 20 campaign emails a day with 600 seconds between sends, warm in the shared pools like any other, and show the provider's own warmup beside SendSets' under sendsets mailbox warmup status. Domains renew automatically about a month before they lapse, charged at the provider's current renewal price plus processing; sendsets mailbox provision renewals shows what renews when and anything that needs a person. Cancelling the order retires them at the provider and stops future renewals. See billing for what is charged, and the mailbox reference for the API. Self-hosted instances do not offer this.

Mailbox allowance

Mailboxes are unlimited on every paid plan. What keeps that honest is a fair-use allowance derived from the plan's sending volume: one mailbox for every send a day the plan includes.

That is deliberately far more than safe sending ever needs: at the recommended 30 to 50 sends a day per mailbox, a Mothership workspace fills its volume with a few hundred mailboxes and still has room for many more. The allowance exists so that it is never the reason to run a mailbox hotter. A self-hosted instance without billing never counts.

A free workspace. Two ways past the 10: upgrade to Mothership for $49 a month, or self-host SendSets and link that instance so its mailboxes warm in the same pool. Both are offered on the Accounts page while the workspace is free.

The connect dialog shows the allowance up front: a quiet count while there is room, a warning near the cap, and a clear full state that leads to the request flow instead of letting you type credentials that would be refused. When a connect is refused the answer is the same dialog, not an error toast.

Getting more. Two paths, both in the dialog:

• Move to a bigger plan. The dialog names the next plan and how many mailboxes it holds; the change is prorated and takes effect immediately.
• Request an increase. Keep your plan and ask for a higher allowance with a sentence on what you are sending. An operator reviews it, usually within a business day, and the new allowance applies to the workspace straight away. The dialog shows the open request while it is pending and lets you withdraw it. History lives under Settings > Limits.

Nothing is ever removed for being over the allowance. A workspace that moves to a smaller plan keeps every mailbox sending and warming; it simply cannot add more until it is back under, or the allowance is raised.

There is no daily cap on how many mailboxes you connect: a Mothership workspace can connect thousands in one afternoon, and the bulk import exists for exactly that.

Connecting many mailboxes at once

Pick Bulk import from CSV in the connect dialog to connect any number of SMTP and IMAP mailboxes from one file. Gmail and Outlook mailboxes sign in one at a time, because each needs its own consent.

The file. One mailbox per row. email, smtp_host and imap_host are required, plus a password; everything else has a default.

The dialog offers a template with these headers, and accepts the common spellings (smtp_server, app_password, login, and so on).

What happens. The file is read in your browser and checked before anything is sent: rows missing something the connect needs are listed with the reason and left out of the run. The preview also says how many rows fit your allowance; if the file is larger, the first rows that fit are connected and the rest are reported as failed so you can request more and re-upload only those.

The run then streams the rows to the server in small batches. Every credential is verified against its own server before it is saved, the same as a single connect, so a large file takes a few seconds per mailbox; the dialog shows live progress and the mailbox list behind it fills in as they land, for everyone in the workspace. You can stop after the batch in flight. Closing the tab loses nothing that was already connected.

When it is done you see how many connected, how many were already here, and how many did not connect, with a reason per row. Retry failed runs those rows again without leaving the dialog, passwords still in memory. Download failed rows gives you those rows as you uploaded them plus an error column, with the password columns left out so no credential lands in a Downloads folder; add them back before uploading the fixed file. Re-uploading is always safe: a mailbox that is already connected is skipped, never doubled.

The same endpoint is available to the API as POST /emails/onboarding/smtp-imap/bulk, up to 50 rows per call, answered per row.

Reconnecting an account

When the provider stops accepting a mailbox's stored credential (a password change, a revoked grant, an expired app password), the mailbox is taken out of sending and syncing and its drawer shows the reason under Needs attention, with the fix right on the error:

• Gmail and Outlook: a Re-authorize button re-runs the provider consent in a popup, preselecting the mailbox's own address. The consent must be for that same address; signing in with a different account is refused instead of quietly connecting the wrong mailbox.
• SMTP / IMAP: an Update credentials button opens a form for the new password (or new host and port). The replacement is validated against your server before it is saved, the same as at connect time.

A successful reconnect stores the new credential, clears the authentication error, reactivates the mailbox on its existing worker, and it resumes syncing from where it stopped. Nothing else changes: settings, history, warmup progress, and campaign membership all stay.

Reconnecting never counts against the mailbox allowance, so a workspace at its cap can still fix a broken mailbox. A mailbox whose sign-in is held by SendSets Cloud is reconnected from your cloud workspace instead; the button says so if you try locally.

What gets synced

Connecting a mailbox does two things: it imports the mailbox's recent history, and from then on it follows new mail as it arrives. Both are the same on every provider.

The import brings in the last 90 days, newest first, up to 5,000 messages per mailbox (the defaults; a self-hosted instance can change both under Instance settings). It reads the inbox, sent mail and archive (plus your own folders on Gmail and IMAP), and skips trash, drafts, spam and Gmail's "All Mail". You can watch it in the mailbox drawer's Sync card: a progress bar with a running count while it works, then "Up to date" with what was imported. Because it runs newest first, the mail you would look for is there within the first minute; a large mailbox finishes over the next while at a steady pace.

Live sync then follows every folder the provider exposes, including junk (so placement problems are visible) and sent mail (so a conversation shows both sides). Read state, flags, deletions and moves are mirrored too.

Nested folders are followed as well, so mail in a subfolder of the inbox or under a label group arrives like anything else. Up to 100 folders per mailbox are synced. Past that the inbox, sent, drafts, spam, trash and archive are always kept and the rest are taken in the order the server lists them, with a note in the mailbox drawer's Sync card saying how many were left out. The note goes away by itself once the mailbox is back under the limit.

On IMAP, folders are identified by the standard attributes a server publishes, and by name when it publishes none. The common names are recognized in a dozen languages, so a mailbox whose Sent folder is called "Gesendete Elemente" or "Éléments envoyés" still files sent mail as sent rather than as inbox.

Only two patterns deactivate a mailbox's sync, and both mean something is wrong upstream: a flood (thousands of new messages in a single hour, more than any real inbox produces) or exceeding the daily budget on three of the last seven days. The mailbox then shows the reason under Needs attention; fix what is delivering that volume into it, or ask your administrator to raise the budget, and reactivate it.

Sending controls

Set these on the mailbox's Settings tab. They apply to the next scheduled send, not retroactively.

The default of 50 is deliberately conservative. 30 to 50/day is the normal safe band; a fresh mailbox should start at 10 to 20 and ramp. Raise the cap only for a mailbox with proven reputation and low complaint and bounce rates.

The range goes up to 5000 so a high-capacity mailbox (a warmed Google Workspace account allows 2000/day, Microsoft 365 more) is not artificially blocked, and the dashboard shows a warning on anything above 100. A high cap only raises the ceiling: the campaign's own daily limit, the ramp, sending behaviour, and your workspace's daily send limit all still apply, and the smallest one wins. The minimum gap is a throughput bound of its own: at the default 600s a mailbox tops out around 144 sends in a 24-hour window, so a cap above that only takes effect together with a shorter gap.

Keeping a copy of sent mail

SMTP mailboxes get a Keep a copy of sent mail toggle, on by default. SMTP submission puts nothing in your own account, so without it a message SendSets sends exists only in the recipient's inbox: it shows up in neither your mail client nor the unibox thread. With it on, SendSets files each message in the mailbox's Sent folder as it goes out, flagged read and dated when it was sent.

Turn it off when your provider already saves its own copy of anything submitted over SMTP, which Gmail, Fastmail and Zoho do, or the folder ends up with two of every message. Gmail and Outlook mailboxes connected with OAuth never show the toggle: their APIs file the copy themselves. Warmup mail is never filed, since it would bury your real sent mail.

The same tab sets the display name, reply-to (empty uses the mailbox address), signature in plain text and HTML, and tags for grouping. Tags belong to the workspace: one anybody creates is there for every teammate, on every mailbox. A new display name is on the From header of the next message the mailbox sends, campaign, reply or warmup alike; nothing needs to be reconnected.

The HTML signature is placed in a block of its own one line below the body, so it arrives without the stack of blank lines above it that Apple Mail and Outlook used to show. Put any extra spacing you want inside the signature itself. On a body laid out in HTML it goes inside the container the email was built in, so it lines up with the copy it signs off rather than sitting under it at the left edge of the window (the same placement as the opt-out line). The plain-text signature follows the body after a single blank line.

The signature editor has four views. HTML is the visual surface with bold, italic, underline, links and images. The </> button next to it swaps that for the raw markup, which is sent exactly as written, so a table-based signature from another tool can be pasted in whole. Preview renders it the way a mail client will, in its own frame. Plain holds the plain-text version, generated from the HTML while Sync is on.

A signature carrying a <style> block, a whole HTML document, or an event handler is always edited as markup and the visual toggle is greyed out. The visual surface works by putting the markup into the page, and a signature is workspace data your teammates also see, so that markup is never given a live element to run in. Preview is how you look at it. Any <style> block in a signature is inlined onto the elements it matches when the email sends, the same as a campaign body.

Sending identity

A Gmail mailbox can send as more than one address. Anything you have added under "Send mail as" in Gmail and finished verifying, a role address like hello@ or an address on a second domain you own, is an address SendSets can put on the From header.

Pick it under Sending identity on the mailbox's Settings tab. The list is read from Google, so it holds exactly what Google will accept: an alias still waiting on its verification email is shown but cannot be chosen, because Google would refuse the send. Press Refresh addresses after adding one in Gmail. Leaving the selection on the mailbox address, which is where every mailbox starts, changes nothing.

The choice applies to campaign mail and to replies you send from the unibox. It never applies to warmup, which always uses the mailbox's own address: warmup pairs mailboxes by that address and verifies its own token against it, so an alias there would break the pairing it exists to prove.

Two things worth knowing before you use one:

• the alias is a From header, not a mailbox. Replies come back to the alias, which Google delivers into the same inbox, and SendSets syncs them as usual
• authentication follows the alias's domain, not the mailbox's. An alias on a domain with no SPF or DMARC record sends from a domain SendSets has not checked, so set those up first and watch the mailbox's domain authentication after the change

Import signature from Gmail on the same card replaces the mailbox's signature with the one configured in Gmail, for whichever address the mailbox sends as. It writes straight away rather than waiting for the save bar, and the editor below updates to show what was stored. An empty signature in Gmail changes nothing, and one larger than SendSets stores is refused rather than cut in half. Editing the signature here afterwards makes it yours again: nothing re-imports on its own, so a signature you have since adjusted is never overwritten behind your back.

Outlook and SMTP/IMAP mailboxes have no equivalent list to read, so the card is absent for them. Their signature is written in SendSets.

Custom tracking domain

Open pixels and click links go out on a shared tracking host by default, which means their reputation is the sum of everyone else using it. Pointing a subdomain of the domain you send from at that host puts them on your own name instead.

Type the subdomain into Custom tracking domain in the mailbox's Settings tab. SendSets shows the exact CNAME to add, with the value taken from the host this SendSets install serves tracking on (on a self-hosted install, that is whatever the operator set TRACKING_DOMAIN to). Add the record at your DNS provider, then press Save & verify.

Verification resolves the record live and reports what it finds:

A provider that flattens CNAME records (ALIAS records, apex flattening, proxied records) still verifies: SendSets compares the addresses when there is no CNAME to read.

Press Check again any time to re-resolve without changing the value. SendSets also re-checks every custom tracking domain on its own, hourly, so a record that finishes propagating after you saved starts being used without you doing anything, and one that later stops pointing at the tracking host stops being used instead of quietly breaking every link.

Until it verifies, tracking falls back to the shared host, so an unverified domain never breaks sending: links keep working, they just are not on your name yet. Links already sent keep working after a change; new sends pick up the new domain.

A verified domain also serves the unsubscribe link in that mailbox's campaign mail, so the opt-out a recipient reads sits on your name like every other link in the message. An unverified one changes nothing: the opt-out stays on the instance's API address, which always serves it.

Verification proves DNS, not HTTPS, and the two are separate steps. That matters more now that the opt-out rides the same host: a certificate the recipient's browser rejects costs a spam complaint, not just a click. On SendSets Cloud the certificate is handled for you. On a self-hosted instance installed with the bundled Caddy it is handled too: Caddy obtains one for your domain the first time a recipient loads a link on it. Behind an operator's own proxy it depends on that proxy, so a domain that verifies here but serves a certificate warning is something to raise with the operator.

Tracking direct mail

Campaign mail carries an open pixel and tracked links. Mail you write by hand in the unified inbox does not, unless you ask for it.

Turn on Track opens and clicks on direct mail in the mailbox's Settings tab to opt that mailbox in. From then on, HTML replies and new messages you send from that mailbox get the same open pixel and tracked links as campaign sends. Plain-text-only messages remain untracked. The results appear under Direct mail in Analytics.

It is off by default on purpose. A pixel in a one-to-one reply is a different proposition from one in a cold sequence: it costs a little deliverability, and it tracks mail to colleagues and customers who are not campaign contacts. Leave it off for a mailbox you use as a personal inbox.

Two limits worth knowing before you read the numbers:

• It applies to mail sent from now on. Messages already delivered carry whatever they carried when they left, so the figures start from the moment you switch it on rather than covering your history.
• It covers mail sent through SendSets. A reply you write in Gmail or on your phone still counts towards the sent and reply figures, because those are read from the mailbox itself, but it cannot be opened-tracked.
• It needs an HTML part. A plain-text-only message has nowhere to place a pixel or wrapped link, so it is sent without tracking.

Clicks are counted per message, not per link: Direct mail reports how many messages were clicked and when, without the per-link breakdown campaigns get.

Tracking uses the same host as everything else, so a custom tracking domain on this mailbox applies here too. On an install with no tracking host configured, direct mail goes out untracked rather than carrying a pixel that points nowhere.

Warmup

New mailboxes should warm up before carrying campaign volume. Defaults are 10/day starting volume, +1/day ramp, and a 40/day ceiling.

Start, pause, resume, or stop from the mailbox's Warmup tab, or for several mailboxes at once from the Accounts selection bar. Pausing keeps your ramp progress; stopping resets it, so a restart begins at the base volume again.

Keep warmup running after campaigns begin rather than switching it off once a mailbox looks ready. See Warmup.

From the terminal: sendsets mailbox warmup enable <id>, disable, pause, resume, and status, which reports whether it is warming, today's target from the same ramp the scheduler acts on, the pool, and the pool health standing.

Pausing and disconnecting

A mailbox can be set inactive (PATCH /emails/{id} with status) when you want it to stop without losing its settings, its history, or its place in the fleet.

Switching it off takes effect immediately: the machine syncing it is told to drop it, so it stops importing mail and stops being picked for campaign sends and warmup within seconds rather than at that machine's next restart. Warmup pool membership is dropped, and any warmup chain it had winds down on its next step. A campaign email already handed over is answered as a failure and the step is retried later on a mailbox that is still active, so nobody receives it twice and no lead is stranded.

Leads mid-sequence on that mailbox move to another one in their campaign as they reach their next step, rather than going silent waiting for it. Each campaign's activity log records the change. See senders and rotation for how a lead's mailbox is chosen and when it changes.

It keeps its worker assignment while off, so switching it back on puts it back on the same machine, sending from the same IP, and it resumes syncing from where it stopped instead of re-importing.

Disconnecting removes the mailbox for good. It is on the mailbox's own More menu in the list, as Disconnect mailbox, and at the bottom of its Settings tab under Danger zone. To remove several at once, tick their rows and use the selection bar. The machine syncing it is told to drop it before the record is removed, because afterwards there is nothing left to tell. If that instruction cannot be delivered, the disconnect fails with a 503 and nothing is removed, so retry it in a moment rather than assuming it worked.

Everything belonging to that mailbox goes with it: its imported mail in the unibox, its warmup history and pool membership, its credentials, its sender links, and any send still scheduled for it. A campaign that was using it keeps running on its remaining senders, and the leads it had been writing to move onto them at their next step. Export the workspace first if you want a copy. Disable the mailbox instead when you only want it to stop.

What disconnecting erases

Disconnecting is a deletion, not a hiding. Two parts of it finish just after the mailbox disappears from your list, because neither can be done in the instant the record goes.

The connection to your provider is handed back. For a Gmail mailbox, SendSets calls Google's revocation endpoint with the refresh token it held, which invalidates that token and every access token issued from it, and removes SendSets from the third-party access list on your Google account. You do not have to go and remove it yourself. Deleting our copy of a token would not have done this; the grant would have stayed on your account.

Microsoft publishes no equivalent endpoint for a single application, so an Outlook or Microsoft 365 mailbox is different: the stored tokens are destroyed here and stop being usable by SendSets, but removing the app from your account is done by you, under Microsoft account privacy settings. The only Microsoft call that ends sessions signs you out of every application you use, which is not something to do because you disconnected one mailbox.

The message bodies are deleted. Mail SendSets imported is stored outside the database, and those files are removed too. The rows that index them go with the mailbox immediately; the files follow within about a minute.

If either step cannot finish, because a provider is down or storage is briefly unreachable, it is retried until it does rather than being given up on. Nothing else is left: the thread labels and snooze timers on conversations that existed only in that mailbox go as well, and a conversation that also ran through a mailbox you kept keeps its labels.

Closing the whole workspace does the same thing for every mailbox in it, for the same reasons.

Worker assignment

You never pick a worker. SendSets assigns each mailbox to a sending worker automatically and can move it later.

Workers are the machines that connect to your mailbox provider. They are not the address your recipients see: your provider delivers the mail from its own infrastructure, and it strips the connecting client's address on the way out. What the worker's address does decide is how your provider sees the sign-in, which is why SendSets optimises for keeping a mailbox on the same worker rather than spreading it around. A mailbox whose connecting address keeps changing collects security challenges and authentication throttles for nothing.

Every worker is the same kind of worker. There are no tiers to qualify for and no pools to be sorted into. Placement scores the fleet on live signals and picks the best fit:

• how much capacity a worker has left, so the fleet fills evenly
• whether the mailbox is already there, which counts for more than anything else
• whether the worker sits near where your provider expects your sign-ins
• how much of your workspace is already on that one machine, so a single failure never stops all of your sending
• how many other mailboxes on the same provider already sign in from that address

Each assigned mailbox counts as one unit against the worker's configurable planning target. Provider sending budgets remain attached to each mailbox and do not reduce the worker target.

Mailboxes move only when there is a reason. A worker going offline or running hot (above 85% of its planning target) will move yours. SendSets also corrects workspace or provider concentration across the live fleet. A settled mailbox has to have been in place for three days before an ordinary rebalance is considered, and the alternative has to be meaningfully better. A mailbox that never needs to move is the ideal, not a stuck one.

Plans that include reserved sending give your workspace a worker no other customer sends from, so your mailboxes always sign in from an address that is yours alone. It is a preference, not a lock: if that machine goes down your mailboxes keep working on the rest of the fleet and return when a replacement is ready.

Resting a tired mailbox

Cold sending used to run at full volume until a mailbox crossed a hard health band, with nothing in between. A mailbox showing early fatigue either kept going or was quarantined.

A mailbox now has a cold-rotation state, separate from its health:

A mailbox rests when its warmup health reaches throttled or worse, and returns on its own once it is healthy again and has held steady for three days. One good hour does not put it back at full cold volume.

Resting only makes sense while the mailbox is in a warmup pool, because pool health is the signal it recovers on. If a resting mailbox leaves its pool (the workspace loses warmup when a trial ends or a plan changes), there is no health signal to wait for, so the mailbox returns on its own three days after its last rest stamp rather than staying out indefinitely. Pausing warmup on the mailbox does not remove it from the pool, so its health keeps being tracked and the normal three healthy days still apply.

Putting a resting mailbox back yourself

You do not have to wait. A resting mailbox's notice in the drawer has a Put back into campaigns button. It lands in active unless its warmup health is still throttled or worse, in which case it stays resting and the drawer says so: a mailbox that warmup can see is struggling should not send cold mail, and there is no override for that short of the health recovering.

API keys get the same exit through POST /emails/:id/release, which works on a resting mailbox as well as a held one.

It does not rest on the watch band. That band is deliberately the one that changes nothing you can feel, and leaving cold rotation is very much something you feel.

Holding a mailbox yourself

To keep a mailbox out of campaigns on your own terms (a domain you are moving, an inbox you want to keep for replies only, a sender you are about to retire), open its drawer and turn on Hold from campaigns on the Overview tab. The mailbox goes into reserve: campaigns stop picking it, warmup carries on as before, and nothing automatic ever releases it. Turn the hold off to put it back; if its warmup health is still poor at that point, it rests until it recovers rather than returning straight to full volume.

The same hold is available to API keys as POST /emails/:id/hold and POST /emails/:id/release. Releasing a mailbox that is resting rather than held works the same way and is the manual exit from a rest.

Health

The Accounts list groups mailboxes as Healthy (sending normally), Warming (ramping through warmup), or Needs attention (paused, failing, or not sending), each row showing a live state and score. A drop between refreshes notifies you rather than waiting to be noticed.

The detail drawer runs a live SPF, DKIM, and DMARC check on your sending domain. Confirm it is green before sending; major providers require alignment for bulk and cold mail. A domain that stays Failing eventually stops cold sending and warmup from every mailbox on it, so fix the records and press Re-check to clear it straight away. DKIM reads Not verified rather than Missing when no key answers, because its selector is not something DNS can be asked for; that never gates sending. See Deliverability for the grace period and exactly what is stopped.

Underneath, health moves through healthy, watch, throttled, quarantined, and blocked. These feed warmup pool selection, which only picks healthy mailboxes as partners, so an unhealthy one can be lowered in volume, removed from the pool, or blocked entirely. A blocked mailbox shows the reason and any appeal option on the Warmup tab, and must requalify on a fresh probation sample rather than waiting out the clock.

Health is judged only on what happened while the mailbox was in the pool: signals recorded before it joined are never counted against it.

Related guides