Fix: “535 5.7.8” (Authentication Failed)

The error “535 5.7.8: Username and Password not accepted” or “535 5.7.8 Authentication Failed” is an SMTP status code returned by Google’s outbound mail servers (smtp.gmail.com). It indicates that the credentials supplied during the SMTP AUTH phase were rejected.

Diagnostic Code: 535 5.7.8 Username and Password not accepted. Learn more at
<https://support.google.com/mail/?p=BadCredentials>

Quick Answer

Google returns 535 5.7.8 when an SMTP client or script attempts to authenticate using a standard account password while 2-Step Verification is active, or after Google disabled basic authentication for third-party apps. To fix this, generate and authenticate with a 16-character App Password or transition your client to OAuth2.

---

Root Causes of Error 535 5.7.8

Google permanently deprecated basic authentication (“Less Secure Apps”) across consumer and Workspace accounts. Supplying a standard username and primary account password directly to an SMTP server using basic authentication triggers an immediate 535 rejection.

The error appears in three primary scenarios:

535 5.7.8 Encountered
│
├── Are you using a raw account password?
│   ├── YES ──► 2-SV or Basic Auth block. Generate a 16-character App Password.
│   └── NO  ──► Continue below.
│
├── Is the password an App Password?
│   ├── YES ──► Space formatting error, credential revocation, or 2-SV disabled.
│   └── NO  ──► Modern Auth / OAuth2 configuration mismatch.

1. Less Secure Apps Deprecation

Legacy hardware devices (network scanners, copiers, PBX systems) and custom scripts (Python, PHP, bash relays) that submit an account password in plain text or Base64 encoding over TLS are permanently blocked by Google’s modern identity stack.

2. 2-Step Verification Conflicts

If 2-Step Verification (2-SV) is enabled on a Google account, the primary password can no longer be used for SMTP, POP, or IMAP authentication under any circumstances. Attempting to use the account’s web login password causes the SMTP listener to drop the connection with 535 5.7.8.

3. Password Changes and Token Revocation

Whenever an account’s master password is changed, all previously generated App Passwords are automatically deleted by Google security systems. Any background task, automated alert service, or mail client configured with an App Password prior to the change will fail with code 535.

---

Step-by-Step Fix: Generating an App Password

If your device or application cannot authenticate via modern OAuth2 (browser-based sign-in prompt), you must generate an application-specific password.

Step 1: Confirm 2-Step Verification Status

App Passwords require active 2-Step Verification:

1. Navigate to your Google Account Security Settings.
2. Under “How you sign in to Google,” verify that 2-Step Verification is turned On.
3. (Google Workspace Users) If 2-SV is grayed out or unavailable, your domain administrator must enable 2-SV enforcement in the Google Admin Console under Security > Authentication > 2-Step Verification.

Step 2: Create the App Password

1. In the search bar at the top of your Google Account page, search for App passwords.
2. Alternatively, navigate to: https://myaccount.google.com/apppasswords
3. Enter an identifying name for the application or device (for example: Office-Copier or Python-Relay-Script).
4. Click Create.
5. Google will display a 16-character passcode in a yellow box (e.g., abcd efgh ijkl mnop).

!Google App Password Generation Modal

Step 3: Implement the Password Correctly

• When entering the 16-character password into your SMTP client or code configuration, omit the spaces. Spaces are displayed purely for human legibility.
• Ensure your SMTP server configuration matches Google’s operational transport requirements:
  • SMTP Server: smtp.gmail.com
  • Port: 587 (requires explicit STARTTLS) or 465 (requires implicit SSL/TLS)
  • Authentication: Required (Password / Basic)
  • Username: Your complete email address (user@example.com), not just the prefix.

If you encounter recurring authentication errors even when using a newly generated App Password, consult Resolving “App Passwords” Not Working for advanced debugging procedures.

---

Workspace Admin Escalation: Domain-Level Relays

If you manage an internal network device (such as a mass invoice processor, ERP platform, or ticketing engine) that cannot manage dynamic credentials or store App Passwords, stop using authenticated SMTP endpoints.

Instead, route outbound traffic through the Google Workspace SMTP Relay Service:

1. Log in to the Google Admin Console.
2. Go to Menu > Apps > Google Workspace > Gmail > Routing.
3. Scroll to SMTP relay service and click Configure.
4. Configure the policy:
   • Allowed senders: Only addresses in my domains (or Only registered Workspace users).
   • Authentication: Check Only accept mail from the specified IP addresses and add your gateway’s public static IP.
   • Encryption: Require TLS encryption.
5. In your internal application, point the SMTP host to smtp-relay.gmail.com on Port 587 with no credentials entered.

Using the IP-whitelisted relay bypasses the user-level credentials layer entirely, preventing 535 5.7.8 errors while keeping outbound deliverability within Google’s authenticated routing infrastructure. If you use this approach and encounter relay errors, see Troubleshooting SMTP Relay: “550 5.7.1 Relaying Denied”.