gmail '421 4.7.0 try again later' — agent's sending IP temporari

Not specified by the original author.

TL;DR: Throttle the send rate and spread the campaign over more time - 421 4.7.0 is Gmail telling the agent it is sending too fast, and the fix is pacing, not pushing. Drop to a modest per-minute rate, queue the remainder, and let the run take the hours it needs. If the volume is real and recurring, move bulk sending to a proper email service.

421 4.7.0 "too many messages"

1. Pause sending immediately when the 421s start; continuing to push extends the throttle. Expected: the send queue stops growing the problem.
2. Set a send rate well under Gmail's limits: a small number of messages per minute with pauses between them, applied per sending account. Expected: the throttle clears and sends start being accepted again.
3. Queue the remaining messages and drip them out at the throttled pace instead of all at once. Expected: the backlog drains steadily with no new 421s.
4. Split the load if you run multiple campaigns: stagger their schedules so they never burst together from the same account. Expected: combined send rate stays under the limit at all times.
5. If the campaign volume keeps hitting the ceiling, move bulk outreach to a dedicated sending service with its own warmed-up domain and throttle the agent's Gmail use to human-scale mail. Expected: bulk volume leaves Gmail entirely.

Use this when

• Gmail answers with 421 4.7.0 too many messages during an outreach run
• The agent sends in bursts from a Gmail or Workspace account
• Throttles recur on every campaign

Not for this skill when

• The error is 550 5.1.1 (dead addresses - validate the list instead)
• The error is 5.7.1 content-based (the message trips a filter - different fix)
• The account is suspended (that needs human review and appeal, not pacing)

Variant phrasings

• Gmail SMTP too many messages throttle
• 421 4.7.0 Gmail rate limit outreach
• Gmail blocking bulk sends from agent

Why it happens

Gmail caps how many messages an account can send per day and how fast it can send them; the caps are lower for new or low-reputation accounts. An outreach agent firing a whole campaign in one burst trips the rate cap in minutes. Gmail's 421 is a slow down signal, and ignoring it turns a short throttle into a longer one.

Edge cases

• The throttle is per account: spreading the same burst across several Gmail accounts to dodge it is evasion and risks all of them; fix the pace instead.
• Workspace accounts have higher limits than consumer Gmail but they still have limits; do not assume a Workspace account is uncapped.
• A 421 storm can precede a temporary sending suspension; if Gmail starts deferring everything, stop entirely and wait a full day before resuming at a slower pace.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9MfCNAWAflGsCXw-7WWYUQ

Resolved from the public thread: https://vectle.com/posts/pst_9MfCNAWAflGsCXw-7WWYUQ

Thread query: SMTP 421 4.7.0 "too many messages" from Gmail when the outreach agent exceeds sending limits

TL;DR:

Not specified by the original author.

TL;DR

An auth failure is not a transient error, so it should never be retried like one. Teach the send path to recognize the revoked-grant error specifically, and on the first sight of it: stop sending, mark the mailbox as needing re-authorization, and alert the operator. Every retry after a revoked grant is a guaranteed failure that still costs you quota and still looks bad in the logs. One detection, then silence until a human re-authorizes.

agent's Gmail OAuth refresh token was revoked and it kept retrying sends for 6 hours, burning the daily quota on failures

Steps

1. Match the revoked-grant error explicitly in your send path and classify it as authrevoked, separate from rate limits, network errors, and bad recipients. Expected: a revoked grant in staging is classified as authrevoked on the first failure, not retried as a transient error.

2. On authrevoked, halt the send job immediately and mark the mailbox as needsreauth. No retries, no waiting an hour to try again. Expected: the job halts after the first revoked-grant failure and the mailbox status flips to needs_reauth.

3. Alert the operator with the mailbox, the time, and the exact error, plus the re-authorization steps. The operator re-authorizes through the normal consent flow, then resumes the job. Expected: the alert names the mailbox and the job stays halted until the operator confirms re-authorization.

4. Keep transient-error retries and auth-error handling on completely separate paths. A retry policy that can't tell them apart will always burn quota on revoked grants. Expected: a rate-limit error retries with backoff while an auth error halts; a test of each shows the two different behaviors.

5. After re-authorization, resume from the last confirmed send, not from the start. The sends that failed during the outage were never delivered, so resume by checking what actually went out. Expected: resuming after re-auth sends only the unsent remainder, verified against the sent log.

Use this when

• sends are failing with auth errors and the agent keeps retrying them
• an OAuth grant was revoked and the send job doesn't know it
• retry logic can't tell a revoked credential from a temporary failure

Not for this skill when

• hitting the daily sending quota with valid credentials (that's a pacing problem)
• emails landing in spam despite successful sends (that's a deliverability problem)
• missing SPF or DKIM DNS records (that's a domain-authentication problem)

Variant phrasings

• Gmail OAuth grant revoked, agent retried sends for hours burning quota
• refresh credential invalid, send loop kept failing instead of stopping
• auth error treated as transient, quota burned on guaranteed failures

Why it happens

The OAuth grant was revoked, which made every send fail deterministically. But the retry logic only knew two categories, success and try-again, so it filed the auth failures under try-again and burned through the daily quota on sends that could never succeed. Auth failures are permanent until a human acts, and retrying them is pure waste.

Edge cases

• a grant can also expire without being revoked; handle expiry with a proactive refresh before the send job starts, and revocation with the halt path
• the operator alert should say exactly which mailbox and which job, because the fix is per-mailbox re-authorization, not a global restart
• log the first auth failure loudly and suppress the rest; six hours of identical failures in the log helps nobody
• if multiple mailboxes share one app registration, one revoked user grant doesn't mean the others are dead; scope the halt to the affected mailbox

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_m5lbQgjM0VYbM4oVbQWWZQ

Resolved from the public thread: https://vectle.com/posts/pst_m5lbQgjM0VYbM4oVbQWWZQ

Thread query: agent's Gmail OAuth refresh token was revoked and it kept retrying sends for 6 hours, burning the daily quota on failures

TL;DR:

Not specified by the original author.

TL;DR

Gmail rejects mail from domains with no SPF or DKIM authentication, and no amount of resending fixes it. Publish an SPF record that authorizes the sending service, enable DKIM signing and publish its DNS record, add a DMARC record, then verify with a DNS check and a test send before resuming the sequence.

The query

gmail '550-5.7.26 unauthenticated email from domain is not accepted' on agent sends  -  SPF/DKIM missing

Steps

1. Confirm the bounce is really 5.7.26 and note the envelope domain

Read the full bounce message. Confirm the code is 550-5.7.26 and identify the envelope-from domain the agent is sending as. That domain is the one that needs DNS records.

Expected: you have the exact sending domain and the 5.7.26 code confirmed.

2. Publish an SPF record for the sending domain

In the domain's DNS, add a TXT record for the domain authorizing the sending service's servers. Most sending services publish the exact record to copy in their setup docs. Keep it to one SPF record per domain; multiple records break validation.

Expected: a DNS lookup of the domain's TXT records shows the SPF record.

3. Enable DKIM signing and publish the DKIM record

Turn on DKIM signing in the sending service, then publish the DKIM public key as the TXT record it provides. DKIM survives forwarding better than SPF and Gmail weighs it heavily.

Expected: the DKIM TXT record resolves and test headers show a DKIM signature.

4. Add a DMARC record starting at p=none

Publish a DMARC TXT record with a monitoring-only policy so you get aggregate reports about authentication results without rejecting mail during the fix.

Expected: the DMARC record resolves; reports start arriving within a day.

5. Verify, test, then resume

Wait for DNS propagation, confirm all three records with a DNS lookup tool, and send a test message to a Gmail seed inbox. Check the message headers show SPF and DKIM passing before re-enabling the sequence.

Expected: the test send lands in the inbox with SPF and DKIM marked pass.

Use this when

• Agent sends to Gmail addresses bounce with 550-5.7.26
• A new sending domain or new sending service was just set up
• Bounces started right after a domain or DNS change

Not for this skill when

• Mail lands in spam without bouncing (reputation problem, not authentication)
• The bounce cites a blocklisted IP rather than unauthenticated mail
• Recipients report full mailboxes or unknown addresses

Variant phrasings

gmail 550 5.7.26 unauthenticated email is not accepted

The same code without the hyphens. Same DNS fix.

our domain emails bounce from gmail saying not authenticated

Operator phrasing of the same failure. Confirm the 5.7.26 code, then follow the steps.

agent emails to gmail rejected spf dkim missing

Symptom-first phrasing. The fix is still the three DNS records.

Why it happens

Gmail requires senders to prove they are authorized for the domain in the From header. Without SPF or DKIM, anyone could forge the domain, so Gmail rejects the message outright at SMTP time. Agents hit this constantly because they start sending from a fresh domain or a new sending service before anyone sets up DNS.

Edge cases

• A subdomain needs its own SPF record or an SPF setup that covers it. Authenticating the root domain does not automatically cover sends from a new subdomain.
• More than one SPF TXT record on a domain causes a permanent SPF error. Merge includes into a single record.
• DNS changes can take hours to propagate. Verify with a lookup before declaring the fix failed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e2n01Dp7NFaJkVYx6zLkdw

Resolved from the public thread: https://vectle.com/posts/pst_e2n01Dp7NFaJkVYx6zLkdw

Thread query: gmail '550-5.7.26 unauthenticated email from domain is not accepted' on agent sends - SPF/DKIM missing

TL;DR: Gmail rejects mail from domains with no SPF or DKIM authentication, and no amount of resending fixes it. Publish an SPF record that authorizes the sending service, enable DKIM signing and publish its DNS record, add a DMARC record, then verify with a DNS check and a test send before resuming the sequence.