Comparisons · September 29, 2026

Gmail Blocked My Bot From Sending Email: 4 Causes

Gmail blocked my bot from sending email: four different Google enforcement paths, the exact error strings for each, and which ones configuration can fix.

Your agent was sending mail through a Gmail account and then it stopped. Maybe the API started returning 429s, maybe the account owner got a “You have reached a limit for sending mail” banner, maybe the whole Google Account now redirects to a page that says it is disabled. People describe all of these the same way: Gmail blocked my bot from sending email. They are not the same event, they are enforced by different Google systems, and only some of them can be fixed by changing configuration.

This article separates the four paths, gives the exact strings Google publishes for each, and says which you can fix, which you wait out, and which end the account. Every Google figure was read on Google’s pages on 29 September 2026, and Google says limits “can change without notice”. For the structural choice between the two models, read AI agent inbox vs connecting Gmail.

Gmail blocked my bot from sending email: which of four things happened?

Each path produces a different symptom, and the fastest diagnosis is to ask what still works. If the human can still read mail and open Drive, it is not an account suspension. If every account connected through your app fails at once, suspect the app, not a mailbox.

Paths 1 and 2 are about the account the bot sends as. Path 3 is about the software you registered with Google. Path 4 has nothing to do with the bot having a Gmail account at all, which is why it survives every migration.

Path 1: the per-user sending limit, shared with the human

The per-user sending limit is a daily cap on messages and recipients for one account, and it is the most common cause. It bites agents because the counter belongs to the account, not to your integration.

Google’s Gmail API error guide says it plainly: the daily sending limits “are per-user and are shared by all of the user’s clients, whether API clients, built-in or web clients, or SMTP MSA.” An agent sending through a person’s account spends the allowance that person uses from the web and their phone. When the agent exhausts it, the person cannot send either.

The numbers differ between consumer Gmail and Google Workspace, and they are not close:

Sources: Limits for sending & getting mail for consumer accounts, and Gmail sending limits in Google Workspace for Workspace, both read 29 September 2026. The Workspace page adds that limits “are applied over a rolling 24-hour period, not a set time of day”, so there is no midnight reset to wait for. It also says that after a trial converts to paid, limits rise only once the domain has cumulatively paid at least $100 USD, and the increase can take up to 75 days after that.

The error you see depends on the client. The consumer page names “You have reached a limit for sending mail”. The Workspace page lists “You have reached a limit for sending email.”, “You reached a Gmail sending limit.” and “You exceeded the maximum recipients.” Over SMTP, Workspace’s SMTP error reference lists 550 5.4.5 Daily user sending limit exceeded. Over the Gmail API, you get HTTP 429 with “Too many requests: User-rate limit exceeded (Mail sending)” and a retry time.

Two details in Google’s API guide matter for an agent’s retry logic. First, “once the user exceeds their quota, there can be a delay of several minutes before the API begins returning 429 error responses.” Second: “You can’t assume that a 200 response means the email was successfully sent.” An agent that treats a 200 as proof of delivery will report sends that the limit swallowed. That is the same gap covered in accepted vs delivered, arriving from Google’s side.

The fix is not configuration: “You can’t increase per-user limits,” says the API guide. The only structural lever is account type, since a paid Workspace user has a higher ceiling than a consumer or trial account. Otherwise you wait, reduce volume, and stop the agent retrying into a limit that has already tripped.

Path 2: the account itself is suspended or disabled

Account enforcement is a different system with a different blast radius. The sending limit stops sending. Enforcement can stop Gmail, or the whole Google Account.

On Workspace, crossing the sending limit can escalate. The limits page says: “If a user exceeds their sending limits, their account might be suspended.” Google’s Restore a suspended Gmail account page (read 29 September 2026) has an administrator read the reason on the user’s page in the Admin console and click Reactivate, after which “the user’s Gmail account will be enabled within 15 minutes.” The same page lists an account “automatically suspended by Google for abuse” among the ones an admin cannot restore. And there is a ceiling that catches automated senders in particular: “You can only restore the same Gmail account 5 times each calendar year. If an account gets suspended more often than that, no one can reset it, including Google Support.” After that you wait 24 hours for automatic re-enablement. By our arithmetic, a bot that gets the account suspended once a week from 1 January has used all five reactivations before February.

Workspace’s spam and abuse policy goes further: for a user violating the Gmail agreements it covers, Google reserves “the right to immediately suspend the user,” and for a domain-wide problem, “the right to suspend the entire account.”

On consumer accounts the severe outcome is the one on Your account is disabled: “your entire Google Account has been disabled,” and you “can’t sign in to Google services or use Sign in with Google.” You can appeal. For some violations Google “will review up to 2 appeals,” and if an appeal fails and no further action is taken, the account is “permanently disabled and considered for deletion.”

What triggers it is where some pages on this topic go wrong. One lists “Gmail’s terms prohibit automated access” as its first key takeaway. Google’s general Terms of Service bar automated access only “in violation of the machine-readable instructions on our web pages,” meaning robots.txt, not the Gmail API. The Gmail Program Policies (last updated 13 November 2025, read 29 September 2026) say: “You are not allowed to automate the Gmail interface, whether to send, delete, or filter emails, in a manner that misleads or deceives users.” The same section prohibits spam and warns that when recipients mark your mail as spam, future messages are more likely to be classified as spam too. The disabled-accounts page lists “Automatic calls or messages” among common reasons, worded as “Don’t use Google services to make phone calls or send messages automatically (robodialing),” and separately prohibits using “programs (called bots) to create fake accounts.”

On the face of Google’s own text, automation is not the offence. Deceptive automation, unsolicited volume and bot-created accounts are. An agent doing outbound to strangers from a personal account sits close to all three, and you do not get to argue the distinction first. None of the Google pages cited here publishes a detection threshold, so a page naming the sends-per-minute that triggers a ban is guessing.

Nothing about this path is fixable by configuration. It is fixed by an administrator, by an appeal, or not at all.

Path 3: the OAuth app, not the mailbox

Some blocks are your integration’s Google registration failing while the mailbox is fine. These are the ones configuration can fix, and the easiest to misread as account trouble.

Consent-screen status. A Google Cloud project whose OAuth consent screen is external and in “Testing” status “is issued a refresh token expiring in 7 days,” per Google’s OAuth 2.0 overview (read 29 September 2026). The agent works for a week, then token refresh fails, typically with invalid_grant. Why a Gmail refresh token expires every 7 days covers that rule and the other causes on the same page. The one worth knowing here: a token also dies when “The user changed passwords and the refresh token contains Gmail scopes,” so the human’s routine password rotation disconnects the agent.

Verification and scope class. An app requesting sensitive or restricted scopes without completing verification shows an “unverified app” screen, and Google’s unverified apps page says a remaining-unverified app is “limited to 100 new users until it is verified.” The scope class matters more than most builders expect. On Google’s Gmail scopes page, gmail.send is sensitive, but gmail.readonly, gmail.compose, gmail.modify and gmail.metadata are all restricted. An agent that only sends can stay on a sensitive scope. An agent that reads replies cannot. And per Google’s restricted scope verification page, apps that access restricted-scope data from or through a server must complete a security assessment “at least every 12 months,” with verification that “can potentially take several weeks.” The unverified apps page exempts internal apps, meaning apps for users in the same Workspace domain whose project belongs to a Cloud Organization all those users are in.

API quota. The Gmail API meters calls in quota units, separately from the mailbox’s sending limit. Per the usage limits page (last updated 10 September 2026), the per-user limit is 6,000 quota units per minute per project and messages.send costs 100 units. Dividing one by the other (our arithmetic, not a figure Google publishes) gives a ceiling of 60 send calls per user per minute. Google states these figures for Cloud projects created on or after 1 May 2026; projects that made any use of the API between November 2025 and April 2026 keep their previously set quotas, so an older project may see different numbers.

When a rate limit trips, read the status code, because the limits come back differently. Google’s error guide documents userRateLimitExceeded, rateLimitExceeded and dailyLimitExceeded as HTTP 403 with domain: "usageLimits", while the mail sending limit, the bandwidth limit and the per-user concurrent request limit come back as HTTP 429. A 403 domainPolicy (“The domain administrators have disabled Gmail apps.”) means a Workspace admin blocked your app, which no retry fixes. A classifier the agent can act on:

// Map a Gmail API error to the path it belongs to. Statuses, reasons and messages as
// documented in Google's Gmail API "Resolve errors" guide, read 2026-09-29.
function classifyGmailError(status, body) {
  const reason = body?.error?.errors?.[0]?.reason;
  const message = body?.error?.message ?? "";
  if (status === 429 && /\(Mail sending\)/.test(message)) {
    return "sending limit: stop sending, it can keep failing for hours";
  }
  if (status === 429) return "bandwidth or concurrency: fewer parallel calls, back off";
  if (status === 401) return "token invalid: refresh it, else ask a human to reconnect";
  if (status !== 403) return "unclassified";
  if (reason === "domainPolicy") return "admin blocked the app: ask a human";
  if (reason === "userRateLimitExceeded" || reason === "rateLimitExceeded") {
    return "API rate: exponential backoff";
  }
  if (reason === "dailyLimitExceeded") return "project quota cap: raise it in Cloud";
  return "unclassified";
}

The same guide says 429 limits can be resolved “by splitting processing across multiple Gmail accounts.” Read that beside the disabled-accounts page, which prohibits using multiple accounts “to break Google’s policies.” Spreading real load across real accounts is fine. Creating accounts so a bot can send past a limit is the pattern that page describes.

Path 4: Gmail is the recipient, not the sender

The fourth path is Gmail refusing mail sent to Gmail users, and it has nothing to do with the bot’s own account. If your agent sends from any provider to an @gmail.com address, Gmail’s inbound filtering judges the message. The SMTP reference lists several 421 4.7.28 deferrals, such as “Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited,” with variants naming your IP, DKIM domain, SPF domain or a URL domain in the body. Neighbouring entries rate-limit unauthenticated mail, mail failing SPF or DKIM, and mail whose From header is not aligned with either.

This is the path people misattribute after migrating: they leave a suspended Gmail account, see Gmail deferring mail from the new sender, and conclude Gmail “blocked the bot” again. It is a different system judging volume, authentication and how recipients have reacted to that sending domain. For the permanent-failure version and what the agent should do with it, see agent email bounced 550 5.7.1.

Nothing in this article removes path 4, including the product described next.

What an agent-owned inbox removes, and what it does not

Paths 1 and 2 hurt because the agent borrows a human’s account: the shared counter, suspension and identity all come from that. An agent-owned inbox removes those failure modes by removing the shared human account, not by being more lenient.

What changes, stated from the implementation here:

• The agent’s address is its own. Live mail is sent and received on agents.emailforagents.ai. No human’s Gmail allowance, Drive or Sign in with Google is attached to it, so exhausting or losing it cannot lock a person out of anything.
• There is no Google consent screen in the path. The agent connects to https://mcp.emailforagents.ai/mcp with an OAuth connection grant issued by this service, or calls the REST API at https://api.emailforagents.ai/v1 with a scoped key. Google’s verification tiers, Testing-status token expiry and password-rotation revocation do not apply, because no Google account is involved. Connections here still expire 30 days after consent, so reconnecting is planned work, not a surprise.
• The daily cap is one you set, per inbox. An inbox policy can set daily_recipient_limit, which meters live recipients only and resets at midnight UTC rather than on a rolling window. Hitting it returns HTTP 403 policy_denied with “The daily recipient limit has been reached.” (packages/domain/src/daily-limits.ts:25), and test sends never consume it.

What does not change, and should weigh as heavily:

• The allowance is small. The free tier is one live inbox and 100 email units a month per verified owner identity. A unit is one message received or one recipient sent to. That is far below a consumer Gmail account’s daily ceiling. If your problem in path 1 was volume, moving here today makes it worse, not better. Paid plans are not purchasable yet.
• When the allowance runs out, sending stops. The send returns HTTP 402 quota_exceeded; mail already received stays readable. What happens when an agent’s email allowance runs out covers exactly what keeps working.
• This platform can pause sending too. A workspace whose sending is disabled or which is under abuse suspension has sends refused with permission_denied and “Sending is paused for this workspace.” (packages/domain/src/billing.ts:687). The difference from path 2 is scope: it pauses the agent’s workspace, not a person’s whole identity.
• Path 4 is untouched. Recipient-side filtering at Gmail, Outlook or anyone else still judges every message, and a 421 4.7.28 deferral can arrive for mail sent from here. A provider accepting a send is not proof it was delivered, and nothing here can promise inbox placement.

If you are weighing providers rather than fixing a block, the comparisons hub sets out where alternatives, including the Gmail API itself, beat this service.

When staying on Gmail is correct

Staying on Gmail is right whenever the agent genuinely acts for one person inside that person’s mail. Moving would break something real, and the risks above shrink when the agent behaves like the human it assists.

The agent works in the human’s existing threads. Drafting replies to people who wrote to that person, triaging their inbox, following up on their conversations. The replies should come from their address and land in their mailbox, because that is where the relationship lives. A new address would split every thread.

Volume is low and recipients expect the mail. A handful of replies a day to known correspondents is nowhere near a 500 or 2,000 message limit and does not look like unsolicited bulk mail.

The agent drafts and the human sends. If the agent only creates drafts and a person reviews and sends them, there is no automated sending pattern at all. Drafting still needs gmail.compose or a broader scope, all restricted, so verification still applies if you ship this to other people’s accounts.

It is internal to one Workspace organisation. An internal app for users in your own Workspace domain is exempt from Google’s OAuth verification, the admin can reactivate a suspended user, and your IT team already governs those accounts. That removes most of path 3 and softens path 2.

Move the agent off the human’s account when it sends to strangers, runs unattended at volume, would take down a team’s workflow with one person’s suspension, or shares one account with other agents. Once an agent has its own address, connecting an agent client over MCP explains the OAuth grant, the six tools and how to revoke it.

What to do in the next hour

Match the symptom to the triage table, then act on the path, not the word “blocked”:

1. Sending limit. Stop the send loop so it is not retrying into the lockout, wait out the rolling 24 hours, and cut volume.
2. Suspended or disabled. On Workspace, an admin reads the reason and reactivates; count the five annual reactivations. On a consumer account, appeal and stop all automated sending.
3. OAuth app. Move the consent screen out of Testing, request only the scopes you use, and treat invalid_grant as “ask the human to reconnect”, not a transient error.
4. Recipient-side. Check SPF, DKIM and From alignment, slow down, and treat 4.7.28 as a deferral to respect, not a reason to resend.

Then decide whether the agent should keep borrowing a person’s account. If it acts for that person in their own mail, it should. If it is its own actor, give it its own address, knowing the allowance here today is small and recipient filtering follows you wherever you send from.

deliverability reliability inboxes comparison

Keep reading

All guides · Documentation · Comparisons