454 4.7.0 Cannot Authenticate Due to Temporary System Problem

What’s actually happening

Your mail client or sending script logs in fine sometimes, then suddenly gets a 454 on AUTH and the send fails. Retry a minute later and it often works. The 4 in 454 means temporary, so the message hasn't bounced yet and the server expects you to try again. You'll see it most on Gmail/Workspace when a script opens many parallel connections or after a few wrong-password attempts in a row.

Common causes

• Too many simultaneous IMAP/SMTP connections to Gmail (the cap is roughly 10-15 per account); the 16th login gets throttled with 454
• A burst of failed logins with a stale or wrong password triggers a short anti-abuse lockout
• Sending the raw account password instead of an app password while 2-Step Verification is on
• Several devices or scripts reusing the same account and re-authenticating constantly
• Provider-side rate limiting on the AUTH command after rapid reconnect loops

How to fix it

1. Back off and retry with exponential delayTreat 454 as transient. Wait 30-60s, then retry, doubling the wait each time (60s, 120s, 240s) up to a cap. Don't hammer AUTH in a tight loop — that extends the lockout.
2. Cut concurrent connectionsPool and reuse one authenticated SMTP/IMAP connection instead of opening a new one per message. Keep concurrent Gmail connections under ~10. In a mail client, close duplicate accounts configured on other devices.
3. Switch to an app passwordIf the account has 2-Step Verification, generate a 16-character app password at myaccount.google.com/apppasswords and use that for SMTP/IMAP. The normal password will keep failing AUTH.
4. Confirm the credentials are currentA recent password change leaves old sessions sending the wrong password, which looks like 454 churn. Update every client and stored credential, then let the lockout window clear.
5. Enable OAuth2 (XOAUTH2) for scriptsFor automated senders, OAuth2 tokens avoid password-based lockouts entirely and are the supported path for Gmail. Token refresh failures fail more cleanly than repeated bad-password AUTH.