Gmail OAuth failures in WordPress should be diagnosed as authorization-state problems, not as password failures. The important objects are the Google Cloud project, OAuth client, consent configuration, redirect URI, granted scopes and the refresh token held by the plugin.
Match the redirect URI exactly
Scheme, host, path and plugin callback must match the OAuth client. A domain migration can invalidate an otherwise correct integration.
Read the consent error code
redirect_uri_mismatch, access_denied, invalid_grant and insufficient_scope point to different stages. Preserve the code, not the token.
Confirm publishing/test-user state
A consent screen in testing can limit authorized users and token lifetime/availability depending on configuration.
Use the minimum required scopes
Grant only the Gmail/send identity access the plugin documents. If scopes change, re-authorize instead of assuming the old refresh token expanded automatically.
Check refresh-token health
A working initial authorization can fail later after revocation, client-secret rotation or account-security changes. Reconnect deliberately and invalidate abandoned credentials.
Send through the same WordPress path
Test from the actual plugin/form, not only Google OAuth playground or a provider console, then inspect message/provider logs.
After authorization, verify transport with safe mail logs and end-to-end delivery with the mailbox trace.
Record OAuth state without recording secrets
For the incident keep project/client identifier, redirect URI, account, consent-screen mode, requested scopes, authorization timestamp and the provider error code. Do not copy access or refresh tokens. This state record is enough to compare staging and production and to see whether a domain change, scope change or revocation invalidated the authorization.