SMTP error 535 5.7.8 means your email server rejected your login credentials during authentication. The most common triggers are a wrong password, missing App Password when 2FA is active, or Google’s removal of basic authentication — which now requires OAuth 2.0 or an App Password. Fix it by verifying credentials, generating an App Password, or switching your email client to OAuth. This guide covers all causes and fixes for Gmail, Outlook, and beyond.
When you see the 535-5.7.8 Username and Password not accepted message, your SMTP server is telling you one thing clearly: it cannot verify your identity. The fix depends on which of the seven causes below applies to your setup — and one of them is now almost universal for Gmail users. In May 2025, Google permanently ended basic password authentication for all accounts (personal and Workspace). If you haven’t switched to OAuth 2.0 or App Passwords yet, that alone is likely the cause of your error.
Defined in IETF RFC 4954, the 535 5.7.8 code applies across all email providers — Gmail, Outlook, Yahoo, and any private SMTP server. Email clients like Outlook, Thunderbird, and Apple Mail all return it when the auth handshake fails. This guide covers every cause and every fix, from the simplest credential check to App Password generation and OAuth migration.
Quick Cause-and-Fix Reference
| Cause | Fastest Fix |
|---|---|
| Wrong username/password | Double-check credentials; reset if needed |
| 2FA enabled — no App Password | Generate a 16-char App Password in Google Account > Security |
| Basic auth (Gmail/Workspace) | Switch to OAuth 2.0 or use an App Password |
| Wrong SMTP settings | smtp.gmail.com │ Port 587 (TLS) or 465 (SSL) |
| IP blacklisted | Check with Warmy’s free deliverability test; contact ISP |
| Firewall/antivirus blocking port | Whitelist ports 465, 587 in firewall rules |
| Wrong encryption method | Switch to TLS (STARTTLS) or SSL/TLS as required |
Common Causes of “535-5.7.8 Username and Password Not Accepted”
1. Invalid Username or Password
A typo or outdated password is still the most frequent cause. Remember that Gmail usernames and passwords are case-sensitive, and you must use your full email address as the username — not just the handle before the @ symbol.
2. Two-Factor Authentication Without an App Password
When 2FA (two-step verification) is enabled on your Google account, your regular account password no longer works for third-party email clients. Google requires you to generate a dedicated App Password — a 16-character code that authenticates the specific app or device without exposing your main password.
3. Google’s Removal of Basic Authentication (Critical 2025 Update)
This is now the primary cause of SMTP Error 535 5.7.8 for Gmail and Google Workspace users. Google permanently ended “Less Secure Apps” access — personal Gmail accounts lost it in May 2022, and all Google Workspace accounts lost it in May 2025. Google’s own documentation confirms: “Starting March 14, 2025, you and your users must use OAuth with third-party apps to access Gmail.” Any email client still using a plain username and password will receive the SMTP error 535 5.7.8 — regardless of whether the credentials are correct.
4. Incorrect SMTP Server Settings
Using the wrong SMTP server address, port, or encryption method causes the connection to fail before authentication even begins. Google requires smtp.gmail.com on Port 587 (TLS/STARTTLS) or Port 465 (SSL). If your client is connecting on Port 25 or without encryption, it will be rejected.
5. IP Blacklisting
If your sending IP address has been flagged for suspicious activity or spam, Google’s SMTP server may reject your login — even with correct credentials. This is less obvious because the error message looks identical to a password failure.
6. Firewall or Antivirus Blocking SMTP Traffic
Security software sometimes flags outbound SMTP traffic on ports 465 or 587 as suspicious. This interrupts the authentication handshake and results in a 535 error.
7. Encryption Mismatch
If your email client is configured to use SSL when the server requires TLS (STARTTLS), or vice versa, the connection will fail at the encryption negotiation stage — before credentials are even checked.
How to Fix Error 535-5.7.8: Step-by-Step
1. Verify Your Username and Password
Start by confirming you’re using the correct credentials. For Gmail, the username is always your full email address (including @gmail.com or your Workspace domain). If you are uncertain whether your password is correct, reset it directly from your Google Account before attempting any other fix. A typo or outdated password is still the most frequent cause. Before troubleshooting further, use a password checker to verify your saved credentials if needed. Remember that Gmail usernames and passwords are case-sensitive, and you must use your full email address as the username — not just the handle before the @ symbol.
2. Generate an App Password (If 2FA Is Active)
If two-step verification is enabled, you need an App Password for your email client:
- Go to your Google Account and click Security.
- Under “Signing in to Google,” click App Passwords.
- Select the application (Mail) and device you are using.
- Copy the generated 16-character password and paste it into your email client in place of your regular password.
- Note: App Passwords are only available when 2-Step Verification is active. If you don’t have 2FA enabled, enable it first, then generate the App Password.
3. Switch to OAuth 2.0 (The Correct Long-Term Fix for Gmail)
Since Google removed basic authentication in 2025, OAuth 2.0 is now the required authentication method for all third-party clients connecting to Gmail or Google Workspace. Most modern email clients (Outlook 2016+, Thunderbird 78+, Apple Mail on macOS Monterey+) support OAuth. To enable it: remove your existing Gmail account from the client, then re-add it and choose “Sign in with Google” when prompted. The client will open a browser window to complete OAuth authorization without requiring your password.
4. Check SMTP Server Settings
Verify your email client’s SMTP configuration matches Google’s requirements:
- SMTP Server: smtp.gmail.com
- Port: 587 for TLS (STARTTLS) — recommended; or 465 for SSL
- Encryption: TLS/SSL (never use plain/unencrypted)
- Authentication: Yes
- Username: Your full Gmail address
- Password: Your App Password or OAuth token (not your regular account password)
5. Check Server Status
Visit Google’s Workspace Status Dashboard to confirm SMTP services are operating normally. Temporary outages can cause 535 errors even when your credentials are correct.
6. Check Your Network Connection
An unstable network can interrupt the SMTP authentication handshake and produce SMTP Error 535 5.7.8. Try sending from a different network or device to rule this out.
7. Disable Firewall or Antivirus Temporarily
Temporarily disable your firewall or security software and attempt to send. If the error clears, add an exception for your email client or whitelist ports 465 and 587 for SMTP traffic, then re-enable protection.
Pro Tip: Never reuse your main account password in third-party email clients — not even temporarily. App Passwords are scoped to a single app and can be revoked individually, so if a device is lost or compromised, you can revoke just that password without changing your main login. Always generate a separate App Password for every client (Outlook, Thunderbird, your CRM, your mail server, etc.).
Advanced Technical Fixes for 535-5.7.8
1. Check for IP Blacklisting
If your IP is blacklisted, Google’s SMTP server may reject authentication even with correct credentials. Use Warmy’s free Email Deliverability Test to check whether your domain or IP appears on major spam blacklists. If your IP is listed, contact your ISP or switch to a different sending IP. Understanding the full range of SMTP error codes and messages can also help you diagnose what else might be affecting your sending.
2. Adjust Firewall and Antivirus Configuration
If disabling your firewall resolves the error, configure your security software to allow outbound SMTP connections:
- Open your firewall or antivirus settings.
- Look for rules filtering outbound traffic on ports 465, 587, or 25.
- Add Google’s SMTP server (smtp.gmail.com) to the allowed list.
- Restart your computer and try sending the email again.
3. Review Email Client Logs
Most email clients maintain connection logs that show the exact SMTP exchange, including what credentials were sent and what the server rejected. In Thunderbird, go to Help > Troubleshooting Information > Open Profile Folder and check the log files. In Outlook, enable logging under File > Options > Advanced > Other > Enable troubleshooting logging. The log will show you whether the failure is at the credential level, the encryption handshake, or the IP reputation check — which tells you exactly which fix to apply.
4. Update or Reinstall Your Email Client
Outdated email clients may not support modern authentication methods like OAuth 2.0. Check for software updates, or reinstall the client and reconfigure your account from scratch using OAuth during setup. Thunderbird 78+, Outlook 2016+, and Apple Mail on macOS Monterey and later all support OAuth natively.
5. Configure SPF and DMARC Records
Even when you fix the 535 error and restore SMTP authentication, misconfigured DNS records can cause your emails to be flagged or blocked downstream. Use Warmy’s free SPF Generator to build a correct SPF record for your domain, and the DMARC Generator to set a DMARC policy. According to Landbase’s 2025 email deliverability analysis, only 33.4% of the top 1 million domains have valid DMARC records — and 85.7% don’t enforce a quarantine or reject policy. Without these records, your emails are more likely to be filtered even after authentication is restored.
Pro Tip: Before you send a campaign after fixing the 535 error, run your email template through Warmy’s free Template Checker. It scans your content for spam trigger words and structural issues that cause filtering — completely separate from the authentication problem. Fixing auth gets your emails accepted by the server; fixing content gets them accepted by the inbox.
SMTP authentication errors are just one category of delivery failures. If you also encounter temporary rejection messages like the 451 Temporary Local Problem error, that signals a server-side queue issue rather than a credential problem — and requires a different set of fixes.
Not sure if your emails are reaching the inbox after fixing auth? Warmy’s free Email Deliverability Test checks inbox placement across Gmail, Outlook, and Yahoo, scans your domain against major blacklists, and validates your SPF, DKIM, and DMARC records — for free.
Improve Email Deliverability with Warmy
Fixing a 535 error restores SMTP access — but authentication and inbox placement are separate problems. Your sender reputation determines whether messages reach the inbox after the server accepts them. Validity’s 2025 Email Deliverability Benchmark Report found that the global average inbox placement rate sits at 83.5%, meaning roughly one in six emails never reaches the inbox even when accepted by the server.
Warmy is an AI-driven email warmup and deliverability platform that automatically builds your sender reputation, improves inbox placement, and keeps your emails out of spam — no technical expertise required. Warmy’s network of 1M+ real mailboxes sends and receives warmup emails that generate authentic engagement signals, telling ISPs that your domain is trusted. Adeline AI, Warmy’s proprietary warmup engine, builds a personalized warmup schedule for each mailbox and adjusts in real time based on hundreds of parameters.
If you’re dealing with deliverability issues beyond the SMTP error 535 5.7.8 — for example, the 550 Permanent Failure error that occurs when a recipient server permanently rejects your messages — Warmy’s platform addresses those upstream reputation problems before they compound.
Free Tools to Enhance Your Email Strategy
Beyond email warmup, Warmy provides a suite of free tools for diagnosing and fixing deliverability problems:
- Email Deliverability Test — Warmy’s free test checks inbox placement across Gmail, Outlook, and Yahoo, monitors blacklist status, and validates SPF, DKIM, and DMARC records in one pass.
- SPF and DMARC Record Generators — Warmy’s SPF Generator and DMARC Generator walk you through creating and implementing these records without needing to understand the DNS syntax.
- Template Checker — Before you send a campaign, use Warmy’s Template Checker to scan your content for spam trigger words and formatting issues. Also available as a Chrome Extension for real-time checks from your Gmail compose window. Learning how to use a free spam checker to improve email deliverability is one of the fastest ways to lift inbox placement after authentication is fixed.
Pro Tip: If you’ve just fixed a 535 error after a long period of failed sends, your domain may have accumulated a poor sender reputation from the failed attempts. Run a deliverability test to check current inbox placement, then start a Warmy warmup cycle to rebuild trust with Gmail and Outlook before launching your next campaign. Reputation recovery typically takes 2–4 weeks of consistent warmup.
Conclusion
The 535-5.7.8 error always means the same thing: your SMTP server could not authenticate your identity. In 2025 and beyond, the most important fix for Gmail users is switching away from basic password authentication — Google requires OAuth 2.0 or an App Password for all third-party email clients. Once you’ve resolved the auth issue, verify your SMTP settings, check for IP blacklisting, and make sure your SPF and DMARC records are correctly configured.
Deliverability doesn’t end with authentication. If you want to ensure emails consistently reach the inbox — not just get accepted by the server — Warmy’s warmup platform and free tools address every layer of the problem.
Ready to protect your sender reputation and keep emails out of spam? Start your 7-day free Warmy trial — no credit card required. Or book a demo to see Warmy in action.
