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 (Outlook and Microsoft 365) sends you to Microsoft's consent screen and returns a token instead of a password. It runs on Microsoft Graph, never IMAP or SMTP, so consent asks to send mail and to read and organize your mailbox (User.Read, Mail.Send, Mail.ReadWrite, offline_access). It needs no app passwords or server settings.

You may see Unverified on Microsoft's sign-in screen. That label means Microsoft has not yet verified the SendSets publisher identity through its partner verification program. It does not mean the connection is unsafe or that Microsoft has flagged SendSets, and the consent screen still lists every permission requested before you approve.

Gmail with an app password

Picking Gmail / Google Workspace opens a two-step form. SendSets never needs your normal Google password, only a 16-character app password Google creates for it.

1. Turn on 2-Step Verification for the Google account if it is not already on.
2. Open your Google Account, then Security & sign-in, then App passwords (the dialog links straight to it).
3. Create an app password called Sendsets and copy the 16 characters Google shows. Google shows it only once.
4. Back in the dialog, enter your name, the Gmail address and the app password, then choose Connect Gmail.

The server settings are filled in for you and stay folded under Advanced settings unless the connection fails:

IMAP   host: imap.gmail.com   port: 993   security: SSL / TLS
SMTP   host: smtp.gmail.com   port: 465   security: SSL / TLS
username: the Gmail address

Changing the Google account's main password revokes its app passwords, so a password change there means creating a new app password and reconnecting the mailbox.

If App passwords is missing from your Google Account, 2-Step Verification is usually off. App passwords can also be unavailable on some work or school accounts, on Advanced Protection accounts, and on accounts set to sign in with security keys only; a Workspace admin may need to allow them.

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 --email you@gmail.com --smtp-pass "$APP_PASSWORD"

An SMTP/IMAP credential is validated by a worker before it is stored, exactly as the form does. --provider gmail is the same app-password connect with Gmail's IMAP and SMTP settings filled in, so the address and the app password are all it needs. A Microsoft mailbox (--provider outlook) still needs a person to approve the 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 buy managed Google, Microsoft, or Azure mailboxes on a new domain or one you have already connected in Infra > Domains. SendSets adds each mailbox to the workspace after the provider reports it active and supplies credentials. Native warmup can then start in the same pools used by connected mailboxes.

In the dashboard, Mailboxes has separate Domains and Mailboxes tabs. Add domain verifies a domain you own, Provision domain registers one without a mailbox, Connect mailbox adds an existing account, and Buy managed mailboxes opens a managed order. The quote shows the exact Stripe lines and due-today amount before applicable tax. Stripe calculates tax after collecting the billing address. Open paid orders remain visible while provisioning continues.

Ordered mailboxes count toward the mailbox allowance like connected ones, so an order can only be as large as the room the workspace has left, minus mailboxes still arriving from earlier orders. A larger order is refused with provision_over_allowance before anything is charged.

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 --provider azure --count 20 --domain tenant.example.com
sendsets mailbox provision --provider google --count 2 --domain connected.example.com --existing-domain
sendsets domain provision new-domain.example --wait
sendsets mailbox provision status <provisioning_id>

providers lists the live Google and Microsoft mailbox prices and the Azure tenant price. A zero or missing Google or Microsoft price field uses $3 per mailbox per month; a pricing request failure never produces a zero-price quote. Google and Microsoft allow five mailboxes per domain, and Azure allows 100 per tenant. Azure's base price is $30 per tenant per month, charged once for that tenant; the quote includes card processing. An order can span several new Google or Microsoft domains with --domains; mailboxes are spread evenly across them. Quotes last fifteen minutes. An order opens a checkout link for a person to complete, then shows each planned address and its progress. Delivered mailboxes start at 20 campaign emails a day with 600 seconds between sends. Native warmup is available on free and paid workspaces, subject to pool safety limits. Domains renew automatically about a month before they lapse; sendsets mailbox provision renewals shows what needs attention. See billing for charges and the mailbox reference for the API. Self-hosted instances can add external domains but cannot buy managed infrastructure.

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 dashboard also shows a free workspace's usage (for example 7/10 mailboxes) in its bottom-right corner; clicking it opens the Mothership upgrade, and it can be hidden for the session.

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:

• Outlook, and Gmail mailboxes connected with OAuth before app passwords became the only way to add one: 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, including Gmail with an app password: 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, 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 Ready (finished warmup or not using it), Warming (ramping through warmup), or Needs attention (paused, failing, or not sending), each row showing a live health state and score. A drop between refreshes notifies you rather than waiting to be noticed.

Each row also shows Sent today: campaign emails sent today against the mailbox's daily cap, such as 12/50, counted on the mailbox's own day, the same count the cap enforces. Warmup mail is not in it; the Warmup column shows today's warmup volume against its target. Both update live as sends land. Hover or tap the ⓘ beside any column or count for what it measures.

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.

Mailbox scorecard

With the View analytics permission, the Mailboxes tab also scores every mailbox over a window you pick (the last 7, 14, 30, 60, or 90 days). The stat row adds Disconnected, Daily capacity (the sum of connected mailboxes' daily campaign caps), Sent, and Utilization, followed by a daily disconnect trend and provider and domain roll-ups, because a climbing disconnect rate is usually the first sign that something is wrong.

On wide screens the mailbox table carries the scorecard columns after its own: Status, Volume band, Sent, Human %, Positive, Bounce %, Utilization (sends against the daily cap times the window), and Disconnects. Human reply rate is ranked as a percentile against mailboxes that sent a similar volume (1–49, 50–199, 200–499, 500–999, 1K–2K, 2K+), so a 50-send mailbox is never compared with a 2,000-send one. vs workspace ranks it among your own mailboxes and needs three peers in the band; vs instance ranks it among every mailbox on this SendSets instance, needs 20, refreshes every 15 minutes, and is built from bare counts that name no mailbox or workspace. It all refreshes live when a mailbox connects, errors, or recovers.

Related guides