2026-07-15

Nodemailer: response: '535-5.7.8 Username and Password not accepted

Stefan Bogdanescu

Stefan Bogdanescu

Founder & Senior Architect

Nodemailer: response: '535-5.7.8 Username and Password not accepted

Fixing Nodemailer Errors with Gmail: Navigating Google's Security Changes

As developers relying on SMTP services for application notifications, we often find ourselves wrestling with security updates from major providers. Recently, many users attempting to use Nodemailer with Gmail have encountered a frustrating error: response: '535-5.7.8 Username and Password not accepted'. This seemingly simple error points to a significant shift in how Google handles account security, specifically the deprecation of "Less secure apps" access for standard password authentication.

This post will dive deep into why this is happening, provide the correct developer-focused solutions, and show you how to successfully configure Nodemailer with Gmail in the modern era.

The Root Cause: Less Secure Apps Deprecation

The error code 535-5.7.8 is a direct response from the Gmail SMTP server indicating that the provided credentials (username and password) are not accepted for this type of access anymore. This change was implemented by Google to enhance security, effectively shutting down the old method where simply enabling "Less secure apps" allowed applications to log in using standard account credentials without requiring complex OAuth flows.

Nodemailer, functioning as an SMTP client, is directly communicating with Gmail's server. When it attempts to use a standard password combination that relies on the deprecated LSA setting, the server rejects the request. The Nodemailer documentation, while helpful for general usage, often lags behind these rapid security changes, leaving developers in a bind.

Solution 1: The Modern Approach – Using App Passwords

The most secure and reliable way to authenticate an external application (like Nodemailer) with a Google account is by using App Passwords. Instead of relying on your main account password directly, you generate a unique, per-application password that grants the necessary SMTP access.

How to Implement App Passwords:

  1. Enable 2-Step Verification: Ensure 2-Step Verification is enabled on your Google account (this is mandatory for generating App Passwords).
  2. Generate the Password: Log into your Google Account Security settings and navigate to the App Passwords section. Generate a new password specifically for an application (e.g., "Nodemailer Sender"). This will generate a unique 16-character string.
  3. Use the Generated Password: When configuring Nodemailer, you use your standard Gmail address as the username, and the newly generated App Password as the actual password.

This method bypasses the need to rely on the outdated "Less secure app" settings and provides a token that is specifically authorized for this service, aligning with modern security protocols.

Code Example: Configuring Nodemailer Securely

When setting up your transport in a framework environment like Laravel (where configuration separation is crucial), you should store these sensitive credentials securely, typically in environment variables.

Here is an example of how you might configure the transport using App Passwords:

<?php

use PHPMailer\PHPMailer\PHPMailer;

// Load environment variables (assuming a framework context like Laravel)
$host = 'smtp.gmail.com';
$port = 587;
$username = 'your_email@gmail.com';
$password = env('MAIL_PASSWORD'); // Stored securely in .env file
$from_address = $username;

$mail = new PHPMailer(true);

try {
    $mail->isSMTP();
    $mail->Host       = $host;
    $mail->SMTPAuth   = true;
    $mail->Username   = $username;
    $mail->Password   = $password; // Use the App Password here
    $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
    $mail->Port       = $port;

    // ... rest of your email sending logic
    $mail->send();
    echo 'Message has been sent successfully using App Password.';

} catch (Exception $e) {
    echo "Message could not be sent. Mailer Error: {$mail->ErrorInfo}";
}

Alternative Strategy: Dedicated Email Services

If managing SMTP credentials and OAuth flows proves too complex for your application’s architecture, a highly recommended alternative is to stop relying on Gmail entirely for transactional emails. Services like SendGrid, Mailgun, or Amazon SES offer robust APIs, simplify delivery tracking, and handle the underlying security infrastructure for you. These services integrate seamlessly with almost any modern framework, offering superior reliability compared to self-managing SMTP setups.

Conclusion

The Nodemailer error related to Gmail credentials is a classic example of how security standards evolve. The solution isn't to force an outdated method but to adopt the current best practices. By switching from relying on deprecated "Less secure apps" settings to using securely generated App Passwords, developers can ensure their applications maintain functionality while adhering to modern security mandates. For robust, enterprise-level email delivery, exploring dedicated third-party services remains the most scalable long-term solution.

Tags:

Enhance your marketing setup with your own email marketing platform.

Join the growing number of SaaS platforms using Laravel Mail to offer email marketing solutions to their customers.