The usual story goes like this. An agent reads and sends mail through a personal Gmail account. It works with five test accounts, so it gets pointed at a real workload, and a day later sends are failing, the app password is rejected, or the account itself redirects to a page saying it has been disabled.

This post covers what to do in the first hour, what Google actually publishes about its limits, and how to move the agent's mail somewhere it cannot take your personal account down with it. The Google details come from Gmail Help, Google Account Help and the Gmail API docs as of September 2026.

First, work out which block you hit

"Gmail banned my agent" covers several different responses, and they need different handling. The exact error text tells you which one you have.

  • "You have reached a limit for sending mail." A standard Gmail account can send to 500 recipients in one email or 500 emails in a day; work, school and Workspace Individual accounts get 2,000 a day. Gmail Help says sending should work again within 1 to 24 hours.
  • "Messages you sent couldn't be delivered." This follows a large number of sends to invalid addresses or bounces. Google's help page says you may be able to send again after 24 hours.
  • "The user you are trying to contact is receiving mail at a rate that prevents additional messages from being delivered." This one is about the recipient, and Google's advice is to contact them another way.
  • Your account is disabled. The whole Google Account is unavailable. You cannot sign in to Google services or use Sign in with Google on other sites until it is restored.
  • API errors, not account errors. The Gmail API has a quota of 6,000 units per minute per user and a separate per-user limit on concurrent requests. Hitting these returns errors your code should retry with exponential backoff; they are not a ban.
  • The app password stopped working. Google revokes all app passwords when the account password changes, and app passwords only exist on accounts with 2-Step Verification turned on. Someone rotating the password, or turning 2-Step Verification off, looks exactly like a ban from the agent's side.

Triage: the first hour

  1. Stop the agent. A loop that keeps retrying sends or logins adds to whatever the account is already flagged for.
  2. Sign in on a normal browser and read the message. For a disabled account, Google shows the explanation there. That tells you which of the cases above you are in.
  3. For sending limits and bounce blocks, wait. Both lift on their own. Use the time to find the cause: a scraped or stale recipient list is the usual source of a bounce block.
  4. For a disabled account, appeal once and carefully. Google's help page says that for some policy violations it reviews at most two appeals, and an account whose appeal is not approved is eventually disabled permanently and considered for deletion. Explain what the automation was doing and what you have changed.
  5. List what else lived on that account. Drive files, calendars, and every third-party site where you used Sign in with Google are all behind the same login.

Do not open a second Gmail account to carry on while the first is under review. Gmail's program policies list "creating or using multiple accounts or other methods intended to engage in a behavior that was previously prohibited" as circumvention, and Google's account help says bot-created accounts are detected and disabled automatically.

What Google publishes, and what it does not

Google does not publish the signals its abuse systems use, so any list of "triggers" you find online is somebody's guess. What Google does publish are the rules an agent most often runs into: the daily sending limits above; the program policy that you may not "automate the Gmail interface, whether to send, delete, or filter emails, in a manner that misleads or deceives users"; the account policy against bot-created accounts; and the general spam guidance not to send content to people you do not know or to many people at the same time.

Several things agents do by design sit close to those rules: a burst of first-contact emails, a batch of bounces from a list nobody cleaned, or a set of accounts created to spread load. Each of those maps onto a published rule above: the daily cap, the bounce block, or the multiple-accounts policy.

The options after a block

Stay on Gmail, inside the published limits. Use the API with OAuth rather than driving the web interface, keep sending under the daily cap, and only mail people who expect it. This works well for an assistant acting for one person on that person's own inbox.

Add more Gmail accounts. This runs straight into the circumvention and bot-account policies quoted above.

Use a transactional provider for outbound. A sending service handles volume and bounce processing far better than a personal mailbox. The agent still needs somewhere to receive verification codes and replies, and building that inbox, its parsing and its threading is a separate project.

Give the agent its own inboxes. This is what Lumbox is for. Each agent or task gets an address created by API, mail arrives with codes and links already parsed, and nothing about it is tied to your Google account.

What a dedicated inbox does not fix

Moving to Lumbox does not make sending rules go away. Every plan has a per-minute and monthly send cap (3 a minute and 100 a month on free), a new free account without a verified domain is limited to 5 sends in its first hour and 25 in its first day, recipients who hard-bounce, complain or unsubscribe go on a suppression list and are skipped, and accounts suspended for abuse get a 403 on every call. An agent that was blocked by Gmail for sending unwanted mail will be blocked here too.

What changes is the blast radius. A problem with the agent's mail stays with the agent's inboxes and does not lock you out of your own Gmail, Drive or Sign in with Google.

Migration

The code that touches email is usually two functions: one that fetches the latest code and one that replies. Here they are against the Lumbox REST API in TypeScript:

const BASE = "https://api.lumbox.co/v1";
const headers = {
  "X-API-Key": process.env.LUMBOX_API_KEY!,
  "Content-Type": "application/json",
};

// create once per task: POST /inboxes {"name": "..."} returns {id, address, ...}

export async function getLatestOtp(inboxId: string, from?: string): Promise<string | null> {
  const qs = new URLSearchParams({ timeout: "90" });
  if (from) qs.set("from", from);
  const r = await fetch(`${BASE}/inboxes/${inboxId}/otp?${qs}`, { headers });
  if (r.status === 408) return null; // nothing arrived in 90 seconds
  if (!r.ok) throw new Error(`otp failed: ${r.status} ${await r.text()}`);
  return (await r.json()).code;
}

export async function sendReply(inboxId: string, emailId: string, text: string) {
  const r = await fetch(`${BASE}/inboxes/${inboxId}/reply`, {
    method: "POST",
    headers: { ...headers, "Idempotency-Key": `reply-${emailId}` },
    body: JSON.stringify({ email_id: emailId, text }),
  });
  if (!r.ok) throw new Error(`reply failed: ${r.status} ${await r.text()}`);
  return r.json(); // { ok, email_id, thread_id, message_id }
}

The Idempotency-Key means a retried request replays the stored response for 24 hours instead of sending twice; reusing the key with a different body returns 409. The reply goes to the original sender with Re: on the subject and the threading headers set.

The Gmail side of the same comparison, with quotas and push notifications, is in Lumbox vs Gmail API. The quickstart covers creating the first inbox, and send limits per plan are on the pricing page.