Gmail SMTP authentication failed: check the connection method first

Identify the connection you are trying to repair

Google recommends its sign-in flow when an application offers it. App passwords require 2-Step Verification and may be unavailable for certain managed or protected accounts. Changing your Google Account password revokes existing app passwords. These are different failure causes and need different remedies.

Zintara's available connection methods depend on its server configuration. Do not assume that seeing Google branding means your mailbox uses OAuth. Check the method selected during connection. If Google sign-in is unavailable, an eligible account may use the SMTP app-password path; an administrator may need to resolve account policy first.

Source: Google: Sign in with app passwords

Use the symptom to choose the next check

Keep a small incident note before trying another credential. Record the mailbox, connection method, test time and exact error category. Redact the username where necessary and never include a password or token. This table is a diagnostic starting point, not a claim that one error has only one cause.

Worked incident: a mailbox stops after a password change

In this fictional example, a team member changes their Google Account password on Monday. The mailbox had been connected with an app password. The next connection test reports an authentication failure. The operator first verifies the connection method and the timing of the account change; they do not disable 2-Step Verification or change DNS.

If the account still permits app passwords and the app-password path is appropriate, the account owner creates a replacement and updates the intended connection. If policy prevents this, they stop and ask the administrator which supported connection method to use. Account policy is part of the diagnosis, not an obstacle to bypass.

Illustrative incident note
Method: SMTP credentials
Last known success: before account password change
Current result: authentication rejected
Next check: credential revocation and account eligibility
Verification: repeat outgoing and incoming connection tests

Source: Google: Sign in with app passwords

Verify both directions before returning to campaign work

For a new SMTP connection, Zintara's connection form includes a Test connection action covering SMTP and IMAP. Review the result before saving. A connection test establishes access at that time; it does not establish campaign eligibility, recipient delivery or inbox placement.

After repairing a mailbox, use accounts you control to verify an outgoing message and an incoming response. Compare the provider mailbox with Zintara's inbox. If the provider receives the response but Zintara does not show it, continue with the inbox-sync guide rather than repeatedly replacing credentials.

1. Confirm the provider's host, port and encryption settings for the selected method.
2. Check the full account identity and whether the credential was revoked.
3. Run the available connection test and record its actual result.
4. Verify an outgoing message and an incoming response using controlled accounts.
5. Return to the campaign's state, schedule and recipients only after connection problems are resolved.

Give support the evidence that narrows the problem

A useful support message distinguishes a consent error, authentication rejection, timeout and sync failure. Include the method and when it last worked, plus any recent account-policy or credential change. Share a redacted screenshot of the error if needed, not the credential entry screen.

Keep the affected campaign paused while investigating whether replies are being missed. Repairing mailbox access does not by itself prove that every pending follow-up is still appropriate. Review the conversation state before resuming outreach.