Every mailbox in InboxKit carries a status badge, and most support conversations about mailboxes start with one question: what does this status actually mean, and do I need to do something about it? This guide walks through every status you'll see, what's happening behind the scenes, and the exact steps to take (if any). It also covers login and access problems, warmup health badges, and daily send limits, since these usually come up in the same conversation as a status question.
If you take away one thing from this guide, take away this: three statuses get confused with each other constantly, and mixing them up is the single biggest cause of multi-day back and forth with support. Scheduled for Cancellation, Renewal Failed, and Permanently Suspended sound similar but mean very different things, and only one of them is time sensitive. Section 2 below breaks each one down individually so you can identify yours in under a minute.
Status | What it means | Is it urgent? | What to do |
Active | Mailbox is live, sending and receiving normally. | No | Nothing. |
Configuring / Processing / Scheduled | Mailbox is being provisioned right now. | Not unless it exceeds 6 to 8 hours. | Wait, or see Section 2. |
Disconnected | OAuth token expired, usually after a password or policy change. | Yes, but low effort | Reconnect from the dashboard (Section 4). |
Scheduled for Cancellation | You (or support) chose to remove this mailbox. It's still fully active until just before its next renewal. | No | Nothing, it deletes itself automatically. |
Renewal Failed | Wallet didn't have enough credits at renewal time. | Yes, within a limited window | Add credits and recover it (Section 3). |
Suspended (permanent) | The recovery window has closed. Google or Microsoft has permanently disabled it. | Already past the point of urgency, this one can't be reversed | Migrate to the other platform or delete and recreate (Section 3). |
Suspended (insufficient slots) | A subscription downgrade shrank your slot limit below your mailbox count. | Yes | Upgrade the plan back (Section 3.4). |
When you buy new mailboxes, they don't go live instantly. You'll see a status like Configuring, Processing, or Scheduled while InboxKit sets up the Google Workspace or Microsoft 365 account, applies DNS records, and activates the mailbox.
Normal wait time: 30 minutes up to 6 hours. Larger batches (dozens of mailboxes across many domains) sit toward the longer end of that range.
If it's been longer than 6 to 8 hours: the most common cause by far is that the domain is already tied to a previous Google Workspace, usually from before you connected it to InboxKit, or from a prior InboxKit account on the same domain. This blocks activation entirely until the domain is freed. Check the domain's status in the Domains tab. If you see a message about the domain already being in use in another workspace, that's your answer, and provisioning won't complete until it's resolved.
To free a domain that's already in use elsewhere:
If it's tied to a previous InboxKit workspace of yours, contact support and ask to have it freed from the backend. This is faster than the alternative below.
If it's tied to some other Google Workspace entirely (a prior registrar's setup, an old team's account, anything outside InboxKit), you'll need to submit Google's Domain Recovery form. Google typically clears this within 24 to 48 hours. Support can walk you through it or submit it on your behalf if the form gives you trouble.
A related message you might see: "Domain is unsupported." Some domain extensions or specific domains simply don't support Google Workspace or Microsoft 365 mailbox creation. If you hit this, the fastest path is buying a different domain rather than troubleshooting the existing one.
Escalate to support when: provisioning has been stuck for more than 8 hours and the domain does not show an "already in use" conflict. Include the domain name and how long it's been stuck.
These three statuses show up in similar places on the dashboard and can look alarming at first glance, but they're not the same situation, and treating one as the other wastes real time. Here's how to tell them apart.
What it means: Someone (you, a teammate, or support on your request) chose to remove this mailbox. It is not broken and nothing has gone wrong.
What actually happens: The mailbox stays fully active and fully usable through the end of its current paid period. You will not be billed again for it. A few hours before its next renewal date, it's automatically and permanently deleted. No manual action is required at any point.
Is it recoverable? There's nothing to recover, it's still working right now. If you change your mind and want to keep it, contact support before the renewal date, since after that point it's gone.
One thing worth knowing: the renewal date attached to a scheduled-for-cancellation mailbox can be far in the future (sometimes a year or more out, depending on when it was originally purchased), which understandably confuses people into thinking it'll keep renewing indefinitely. It won't. "Scheduled for cancellation" always overrides the renewal date. It will be removed at that date, not renewed past it.
What it means: The mailbox tried to renew and couldn't, almost always because your wallet didn't have enough credits at the moment of renewal. This is a billing problem, not a platform-side or Google/Microsoft-side problem, at least not yet.
Is it recoverable? Yes, but only within a window. You typically have around 10 days from the failed renewal date to recover it before the provider (Google or Microsoft) suspends it permanently. This window is the single most important fact in this whole guide: the moment a mailbox shows Renewal Failed, treat it as time sensitive.
How to recover it:
Add enough credits to your wallet: Settings > Billing > Add Credits, enter an amount, and complete checkout through Stripe. Credits land instantly.
Go to the Mailboxes section and click Review & Recover (sometimes labeled Reactivate) on the affected mailbox, or select all affected mailboxes and use Actions > Reactivate for a bulk recovery.
Once recovered, re-export the mailbox to your sequencer so login credentials stay in sync. Skipping this step is a common reason people think a recovered mailbox is "still broken" when it's actually just out of sync with the sequencer.
A domain-level catch: if the mailbox's domain has also expired, reactivating the mailbox alone won't restore it. The domain needs to be renewed first.
To stop this from happening again: turn on Auto Top-Up (Settings > Billing > Add Credits > Auto Top-Up tab). Set a trigger balance and a top-up amount, and renewals will never run out of credits again. This is worth doing proactively even if you haven't had a renewal failure yet.
Escalate to support when: you're not sure whether you're still inside the 10-day recovery window, since that window is what determines whether Section 3.2 or Section 3.3 applies to your mailbox.
What it means: The recovery window described above has closed, and Google or Microsoft has permanently disabled the mailbox on their end. This is no longer an InboxKit billing state, it's a provider-level suspension, and it cannot be undone. Adding credits, clicking Reactivate, or contacting support will not bring it back. There is genuinely nothing to recover here, which is why it's worth confirming which of these three states you're actually in before spending time trying to fix something that isn't fixable.
Your two options:
Option A: Migrate to the other platform. Move the mailbox from Google to Microsoft, or Microsoft to Google. The username and display name stay exactly the same. Under the hood, though, this is a brand new mailbox on the new platform, so it needs to complete warmup again: 1 week minimum, 2 to 3 weeks recommended before resuming campaign sending. Cost is the same across both platforms, so this isn't a cheaper or more expensive path, just a different one. Migration itself typically takes a few minutes to set up and the mailbox is active again within 3 to 6 hours.
Option B: Delete and recreate. Delete the suspended mailbox (and its now-defunct admin workspace) and set up an entirely new mailbox on the same domain. This requires clearing out the old Google Workspace first, which can take up to 24 hours, and the new mailbox starts warmup completely from zero, same as any brand-new mailbox.
Neither option is automatic. If you have many mailboxes suspended at once, tell support how many and which option you want so the batch can be handled together rather than one at a time.
Escalate to support when: you want ESP migration done for many mailboxes at once, since this requires backend action support has to perform for you. Also escalate if you're unsure whether your mailbox has actually crossed into permanent suspension versus still being inside the Renewal Failed recovery window, support can confirm the exact status from the backend.
This one gets lumped in with the three above but has a different root cause and a different fix. If you downgrade your subscription plan, your mailbox slot limit shrinks immediately. Any mailboxes beyond the new, smaller limit get suspended for insufficient slots, even if those mailboxes were perfectly healthy the day before.
To fix it: go to Sidebar > Subscription and upgrade back to a plan with enough slots. Slot limits adjust instantly, and mailboxes that were suspended purely for lack of slots come back right away.
The catch: if a slot-suspended mailbox sits unrenewed for an extended stretch while you're deciding what to do, it can cross into the same Renewal Failed and eventually Permanently Suspended timeline described above, at which point upgrading your plan back no longer restores it, and you're into the migrate-or-recreate options in Section 3.3 instead. If you've downgraded recently and see suspended mailboxes, act on it within a few days rather than letting it sit.
Escalate to support when: upgrading the plan back doesn't automatically restore mailboxes that were suspended for more than a few days, since that likely means they've already slipped into the renewal-failure timeline.
Every InboxKit mailbox has two-factor authentication enabled automatically for security, so a fresh one-time code is required at every login, you can't reuse an old one or skip this step.
To find your credentials and current code: go to Mailboxes, click More on the mailbox, then Credentials. You'll see the email, password, and a live OTP code there. The code refreshes every 30 seconds, so paste it into Google within that window. If it expires before you use it, just grab the next refreshed code rather than reusing the old one.
Important: do not manually enable 2FA a second time inside the Gmail account itself. InboxKit already manages this centrally, and adding a second layer on top of it can cause sync issues that are harder to untangle than the original login problem.
Need credentials for many mailboxes at once? Mailboxes > select all > Bulk Action > Export CSV gives you a spreadsheet of every login.
Escalate to support when: login still fails using a freshly copied OTP within the 30-second window. That points to something beyond a stale code.
Azure and Microsoft 365 mailboxes work differently from Google ones. They don't support logging directly into the individual inbox the way Google mailboxes do. Instead, you access them as an admin through the Microsoft Admin Portal, using the admin mailbox's credentials (also available under Mailboxes > More > Credentials).
Escalate to support when: you need the admin credentials looked up, or the admin portal login itself is failing.
This is different from a suspension or renewal issue. A disconnected mailbox is typically caused by an expired OAuth token, most commonly triggered by a password change, a 2FA change, or an admin policy update on the mailbox itself.
To fix it: go to Inboxes (or Mailboxes) > Disconnected, and click Reconnect on the affected mailbox. This redoes the OAuth authorization and should resolve it within moments.
Escalate to support when: Reconnect fails, or the mailbox keeps showing disconnected after multiple attempts.
If mailboxes were purchased together but one shows a different display name, contact-sharing setting, or profile picture, it's usually because that individual mailbox's settings were changed after purchase, or it was affected by a one-off backend hiccup. Check that specific mailbox's own Settings tab (Mailboxes > More > Settings), and confirm the field there. Changes to name and profile picture fields can take up to 24 hours to fully reflect across Gmail or Outlook.
Escalate to support when: the setting is confirmed correct in the dashboard but still isn't reflecting after 24 hours.
Worth flagging here since it comes up in access-related conversations: cancelling or deleting the admin mailbox for a domain cancels every other mailbox on that domain automatically, along with the domain's DNS configuration, warmup history, and sequencer connections. This isn't limited to the admin mailbox alone, and it cannot be undone once those mailboxes pass their renewal date. Always confirm this is what you actually want before proceeding, and if you only want to remove the admin while keeping other mailboxes on the domain active, that isn't possible, talk to support about alternatives first.
If your Warmup page shows a day count or email count that looks frozen at an old number, or doesn't match how long you believe a mailbox has actually been warming up, this is a known display issue with the Warmup page UI. It does not reflect what's actually happening in the background. Your mailboxes continue warming up correctly even when the counter on screen looks stuck or inconsistent.
Don't rely on the counter to judge real health. Instead, run an Inbox Placement Test: Addons > Inbox Placement > Start New Test, $0.05 per mailbox. This gives you concrete, current data on where your emails are actually landing (inbox, promotions, spam), which is a far more reliable signal than the day-count display.
One legitimate reason a day count can look lower than expected: if warmup was paused at any point, the day count and sending activity pause right along with it. When you resume, it picks up from where it left off rather than restarting from zero. So a mailbox showing fewer days than you'd expect based on the calendar may simply have had a pause in between, not a bug.
Escalate to support when: an Inbox Placement Test also comes back poor. That points to a genuine deliverability issue worth investigating, rather than a display glitch you can safely ignore.
A closely related note: if a third-party deliverability tool reports a lower placement score than InboxKit's own Inbox Placement Test, that's often expected rather than a red flag. Some third-party testers blend in personal consumer inboxes, which tend to score lower, while InboxKit's test is weighted toward B2B business inboxes. If your outreach targets businesses, the B2B-specific number is the one to trust. Only escalate if the B2B score itself is also poor.
Exceeding your platform's daily sending limit is the most common cause of sending errors, mailbox disconnects, and reputation drops, and it's easy to mistake for a broken mailbox when it's really a volume problem.
Google Workspace mailboxes: start around 15 emails per day per mailbox, gradually ramping to 25 to 30 per day after a few weeks of consistent sending. Always check the current InboxKit Warmup Guide for the exact numbers for your situation, since recommendations are periodically refined.
Azure/Microsoft mailboxes: the guidance is per mailbox, about 2 cold emails plus 5 warmup emails per mailbox per day (7 total). For example, 50 mailboxes on one domain supports about 350 emails per day. These are recommended volumes, not hard caps. If you see errors like "450 4.7.26" or "554 5.2.0" on Azure or Microsoft mailboxes, exceeding this guidance is almost always the cause, not a DNS or InboxKit configuration issue. Reduce per-mailbox volume if you're running hotter than recommended.
If your sequencer keeps auto-pausing warmup and asking for a reactivation code: exceeding these limits is one of the three most common causes (the others are a domain's nameserver status showing "Moved," which breaks connectivity silently, and outdated SMTP/OAuth credentials). Check volume first, since it's the easiest to fix and the most common culprit.
Never run two warmup tools on the same mailbox at once. This effectively doubles your sending volume against the same daily limit and can trigger the exact throttling or blocking described above, actively damaging the mailbox's reputation rather than helping it.
Most status and access questions above are self-serve. Contact support when you hit one of the specific escalation points called out in each section, or more generally when:
You're not sure which of the three commonly confused states (Scheduled for Cancellation, Renewal Failed, Permanently Suspended) your mailbox is actually in.
You need to confirm the exact recovery deadline for a Renewal Failed mailbox.
Provisioning has been stuck longer than 6 to 8 hours with no domain conflict visible.
You need ESP migration (Google to Microsoft or vice versa) done across many mailboxes at once.
A domain is flagged as already in use in another workspace and you need it freed from InboxKit's side.
Login, reconnect, or settings changes still aren't resolved after following the self-serve steps and waiting the stated propagation window (usually 24 to 48 hours).
To get the fastest resolution, include:
The exact mailbox email address(es) or domain(s) affected, not just "some of my mailboxes."
A screenshot of the status badge or error message you're seeing.
When the issue started, or when the status first changed.
What you've already tried (added credits, clicked Reconnect, checked the domain status, and so on).
If it's a volume-related question, the platform (Google or Microsoft) and your current sending setup per mailbox and per domain.
Having this ready up front is usually the difference between a same-conversation resolution and a multi-day back and forth, especially for the three-way status confusion in Section 3, which is the single most time-sensitive issue covered in this guide.
