SMTP 535 Error with Gmail | Emaillistchecker.io

Why does SMTP 535 error persist even with correct Gmail credentials?

You typed the right username and password. The connection still fails. The error code? SMTP 535. It’s not a typo. It’s not your password. It’s a gatekeeper closing the door based on rules you didn’t know were there.

Think of Gmail’s SMTP server like a high-security facility. Even if you’ve got the correct ID and code, they’ll turn you away if your access isn’t approved, your device isn’t recognized, or your behavior raises red flags. The 535 error isn’t about credentials—it’s about policy.

You’ll learn exactly why Gmail rejects your request despite correct login details. We’ll walk through the real culprits: app access, security restrictions, authentication methods, and reputation signals—then show how to fix each one with precise, working solutions.

Key takeaways

Gmail’s SMTP 535 error is almost never about incorrect password entry—it’s about authentication policy, not password validity.
Even with correct credentials, Gmail may block access if 2FA isn’t properly handled, less secure apps aren’t enabled, or your IP is flagged for spam activity.
Using an app-specific password instead of your primary password is a common fix, but only if you’ve enabled less secure app access or use OAuth2 properly.

What exactly does SMTP 535 mean in Gmail's context?

SMTP 535 means authentication failed — Gmail explicitly rejects your login attempt, even if your username and password are correct. The server doesn’t say why: it only confirms the attempt was denied. This is a security feature, not a mistake. Gmail uses this code to prevent attackers from probing valid credentials via response timing or error clues.

Why Gmail uses 535, even with correct credentials

Let’s be clear: the 535 error isn’t about a typo or outdated password. Gmail treats every failed authentication the same way — it returns 535 regardless of whether the user exists, the password is wrong, or two-factor authentication (2FA) is required.

That’s how it works. Even if you just typed the right password, Gmail won’t confirm it. The server stays silent on the cause. This is by design. It prevents abuse, like automated scripts testing millions of passwords by analyzing response patterns. The RFC 5321 specification defines 535 as a standardized response for authentication failure, and Gmail follows it exactly.

Common causes of 535 in Gmail SMTP scenarios

Even with perfect credentials, you might see 535 if:

2FA is enabled and you're not using an App Password. Gmail requires App Passwords for non-browser clients.
Your account has less secure app access disabled. This setting turned off by default since 2022, and even if you enable it, some older clients fail.
Your IP or network is flagged. If Gmail sees repeated login attempts from a single IP and detects suspicious activity, it blocks access temporarily.
SMTP is misconfigured. Using the wrong port (e.g., 465 instead of 587), not enabling TLS, or using the wrong hostname can trigger 535 even with correct credentials.

You can test your SMTP settings using tools like MXToolbox or Spamhaus to verify if your server is blacklisted or misbehaving. But the 535 error itself only tells you it failed — not where or why.

Fixing the issue means verifying your setup against Gmail’s official SMTP requirements. Use App Passwords if you have 2FA. Confirm TLS is enabled and the correct port is used. And if the problem persists, check your network or reach out to your email service provider.

Proactively verifying your email list can help you avoid sending to invalid or locked accounts that trigger authentication failures. Try bulk list verification to filter out dead or problematic addresses before sending.

The top 5 real reasons behind SMTP 535 with Gmail SMTP

SMTP 535 errors when connecting to Gmail SMTP aren't about wrong passwords — they're about missing security layers, outdated settings, or infrastructure flags. If you're getting this error despite entering a correct username and password, the issue is likely one of five technical or policy-based blocks: app passwords in 2FA accounts, disabled less secure app access, a flagged IP address, unencrypted data transmission, or incorrect SMTP configuration. Let’s break down the real causes behind the 535 code.

App-specific passwords for 2FA accounts

If you have two-factor authentication enabled on your Gmail account, standard passwords won’t work for SMTP — you must use an app-specific password.
Google does not allow password-based login for SMTP services when 2FA is on, even if the password is correct.
Generate an app password at Google’s app passwords page and use it in your mail client instead.

Less secure app access disabled

As of 2022, Gmail has disabled less secure app access for all accounts by default — this includes legacy SMTP apps.
Even if your password is correct, Gmail blocks connections from clients that don’t use modern authentication.
Use OAuth2 or app-specific passwords instead. Google’s security best practices guide confirms this change.

IP address flagged due to prior abuse

Gmail uses reputation-based filtering — if your mail server’s IP has sent spam before, it’s blocked regardless of credentials.
Shared hosting IPs or high-volume senders without proper DMARC/SPF records are often flagged.
Check your IP’s reputation using third-party tools like Spamhaus or MxToolbox.

Unencrypted data on port 587

Gmail requires STARTTLS when using port 587. Sending plain text over port 587 triggers a 535 error.
If your client doesn’t enforce SSL/TLS encryption, Gmail disconnects during the handshake.
Verify your client is configured to use STARTTLS — it must initiate encryption before sending credentials.

Incorrect or outdated SMTP settings

Even a single misconfigured setting — wrong host, port, security protocol — can result in a 535 error.
Common issues: using port 25 (blocked), failing to set TLS for port 587, or enabling SSL on port 587 (incompatible).
Double-check settings against Google's official SMTP configuration guide to avoid handshake failures.

Correct credentials don’t guarantee access — modern email systems prioritize security over convenience.

If you're still hitting 535 errors after fixing these, double-check your sending infrastructure. Use the same rules: verify your list first. Clean lists reduce the risk of IP flagging. Try bulk verification with tools like bulk email verification to catch invalid addresses before sending.

How to fix SMTP 535: A step-by-step process

You're getting an SMTP 535 error with a correct username and password in Gmail because modern Gmail accounts require app-specific passwords when using SMTP, not your regular password. This happens even with 2FA enabled. To fix it, enable 2FA, generate an App Password in Gmail settings, use that password in your SMTP client, ensure TLS/SSL is properly configured on the right port, and verify your mail client supports STARTTLS negotiation. Use Telnet or OpenSSL to test connectivity and isolate the root cause.

Step-by-step fix: From setup to verification

Confirm 2FA is enabled on your Google account. Gmail no longer allows password-based SMTP access if 2FA is off. If you haven’t enabled it, do so now. Google’s security policies require this for app-based access. More on 2FA setup.
Generate an App Password in Gmail Settings. Go to your Google Account settings, navigate to Security > App passwords, select "Mail" and your device. Google will generate a 16-digit password. Use this instead of your main password.
Disable Less Secure App Access — it’s obsolete. This setting was removed for most accounts in 2022. If you’re trying to use it, it won’t work. Modern Gmail enforces App Passwords or OAuth2 for all external access.
Use the correct port and encryption. For Gmail SMTP, use port 587 with TLS, or port 465 with SSL. Never use plaintext. Misconfigured encryption is a common cause of 535 errors even with valid credentials.
Ensure your client negotiates STARTTLS properly. Your email client or service must initiate TLS after connection. If it doesn’t, Gmail rejects the connection. Test this with tools like OpenSSL: openssl s_client -connect smtp.gmail.com:587 -starttls smtp.
Test your connection using Telnet or OpenSSL. These tools help diagnose whether the issue is in the SMTP configuration, network, or a server-side policy. A successful handshake confirms your client correctly negotiates encryption.

When it’s not the password: Beyond authentication

Even with correct credentials and encryption, 535 can occur due to network-level blocks or outdated client libraries. Google often blocks access from legacy or poorly configured clients. Make sure your mail system uses up-to-date libraries (e.g., PHPMailer v6+, MailKit, or equivalent).

The 6 steps described in “Step-by-step fix: From setup to verification”, in order.

For teams managing large email lists, verifying deliverability beforehand reduces SMTP failures. Use bulk verification to clean invalid or risky addresses before sending. This helps avoid sending to addresses that trigger blocks — which can indirectly contribute to SMTP errors by degrading sender reputation.

Can you send emails to Gmail without SMTP 535 errors?

You can send emails to Gmail without encountering a 535 error—provided your email setup meets Gmail’s security standards, including proper authentication (SPF, DKIM, DMARC), a clean sender reputation, and verified infrastructure. Even with correct credentials, Gmail rejects connections if your server fails these checks or is blacklisted. Using reputable transactional email services like SendGrid or Mailgun reduces the risk of IP-level blocks due to their established trust and dedicated infrastructure.

SMTP 535 errors aren’t just about wrong passwords. Gmail checks more than authentication—it evaluates your sending environment. If your domain lacks proper SPF records, or your IP address is on a blocklist, Gmail rejects the connection regardless of login accuracy. The 535 error code specifically means "Authentication failed," but often masks underlying deliverability issues like poor sender reputation, unverified infrastructure, or suspicious sending behavior.

Many self-hosted setups or low-reputation SMTP providers fail here because they don’t maintain consistent IP reputations. Gmail trusts only systems with proven compliance: they validate DKIM signatures, monitor sending volume, and track user engagement. If your sending volume spikes suddenly without engagement, Gmail may flag and block your connection—this isn’t a login issue, it’s a security one.

How to avoid SMTP 535 errors and keep Gmail accepting your emails

Let’s be clear: you can’t rely solely on username and password. You need a holistic approach. Start with verified outbound email services—not just for deliverability, but because they handle the technical layers Gmail expects. Services like SendGrid or Mailgun manage IP reputation, enforce authentication standards, and integrate with Gmail’s feedback loops.

Second, maintain clean email lists. Bounced or invalid addresses hurt your sender reputation, which indirectly increases your chances of encountering SMTP blocks. Use a tool like bulk email verification to identify and remove invalid addresses before sending. This reduces bounce rates and helps keep your IP and domain in good standing.

Finally, ensure your sending behavior aligns with Gmail’s standards. Avoid sudden spikes, maintain consistent volume, and include clear unsubscribe links. These practices support inbox placement and lower the risk of being flagged. For testing, tools like inbox placement tests can simulate real delivery conditions and reveal configuration flaws early.

Remember: Gmail’s security is layered. Correct credentials are one piece. The rest—infrastructure, reputation, hygiene—matters just as much. Check your setup with real-time email verification APIs to catch issues before they trigger a 535 error.

How email verification prevents SMTP 535 issues before they start

SMTP 535 errors occur when authentication fails, even with correct credentials. But many of these issues stem from sending to invalid, catch-all, or role-based addresses—problems that email verification catches before you attempt delivery. You don’t need to guess which emails fail. You just need to verify them first.

Before you send, verify the basics

Invalid or malformed addresses (like user@domain. or [email protected]) are rejected during the initial DNS and SMTP handshake—no authentication required. Verification catches these before they ever trigger a 535 error.
Catch-all domains accept any email during SMTP connection but often deliver to spam or drop messages silently. They don’t cause SMTP errors but harm deliverability. Verification flags them as "catch-all" so you can remove them from your list.
Role-based addresses like admin@, support@, or info@ are frequently disabled or ignored by Gmail. They’re often blocked during SMTP authentication—even with valid credentials. Verification identifies these and removes them from your send list.
Disposable and temporary domains (like tempmail.org or 10minutemail.com) can trigger spam filters or force Gmail to reject connections for security reasons. These domains don’t support real mail flow. Verification filters them out upfront.

What happens when you skip verification

Without pre-sending validation, you're sending to undeliverable or risky addresses at scale. Gmail logs authentication failures for repeated attempts—even with correct credentials—especially if those attempts come from misconfigured or high-failure-rate senders.

One 2023 industry report found that lists with no verification had 30-40% higher bounce rates and higher odds of domain reputation damage. That reputation affects every future send, not just the failed ones.

Bulk-verify your list with EmailListChecker.io to catch all these issues in minutes. You'll see exactly which emails are valid, risky, or invalid—no guessing. This prevents 535 errors caused by sending to the wrong kind of address, even if your credentials are perfect.

For ongoing use, integrate verification via our real-time API to validate every new signup before it reaches your sending platform.

The role of sender reputation in Gmail SMTP authentication

Gmail doesn’t just check your login credentials—it assesses your sender reputation based on how your past emails have behaved: bounce rates, spam complaints, and whether recipients actually open or engage with your messages. A single SMTP 535 error isn't enough to trigger filtering, but repeated failures, especially from sending to invalid or high-risk addresses, signal poor list hygiene. Gmail treats your IP and domain as a whole reputation unit, so sending to lists full of disposable, role, or outdated addresses increases your risk of being blocked, even with correct login details.

How Gmail measures sender behavior

Gmail evaluates sender reputation over time. It looks at patterns: if your emails routinely bounce, get marked as spam, or go unread, Gmail assumes you’re a poor sender—even if the SMTP 535 error was a one-off glitch. This isn’t about a single authentication failure; it’s about long-term behavior. High bounce rates from invalid or role-based emails (like admin@ or sales@) can degrade your sender reputation, especially if they come from a shared or new IP address.

Let’s be clear: your credentials are not the only gatekeeper. Gmail uses sender reputation as a threshold. If the system sees you’re consistently sending to non-existent or high-risk addresses—especially in bulk—your messages may get silently filtered, even if authentication succeeds in real time. This is why tools that verify email validity before sending matter. A list with 30% invalid addresses is more dangerous than one with 5%.

Why poor list hygiene damages deliverability

Even if you avoid SMTP 535 errors with correct username and password, sending to a high volume of role, disposable, or outdated addresses can trigger Gmail’s automated filtering. These types of addresses often lack engagement, increase bounce rates, and are commonly associated with spam campaigns. Gmail’s systems detect such patterns and may flag your sending behavior as risky, leading to inbox placement issues or IP-level filtering.

Prevention starts with clean data. Before you send, verify your list to identify invalid, role, disposable, or catch-all addresses. Tools like bulk email verification can catch these issues before they impact your reputation. This isn’t about avoiding 535 errors—it’s about preventing the long-term signals that hurt your deliverability. A well-maintained list doesn’t just reduce bounces; it protects your sender reputation.

For deeper insight into how your emails perform in real inboxes, use inbox placement testing to see how your messages land across Gmail, Outlook, and other providers. It’s not always about authentication—it’s about how Gmail sees you as a sender. And reputation isn’t built overnight. It’s maintained daily by consistent, clean sending behavior.

How to test SMTP settings without sending real emails

You can validate Gmail SMTP settings without sending emails by using command-line tools like telnet or openssl to connect directly to the server, issue SMTP commands manually, and confirm response codes and TLS handshake success. This lets you isolate whether the issue is auth, connection, or configuration. You can also check logs or use third-party testers to simulate attempts from different locations.

Run manual SMTP checks with command-line tools

Open your terminal and run telnet smtp.gmail.com 587. If the connection fails, the issue is likely network-related or your IP is blocked. If it succeeds, the server is reachable.
Once connected, type EHLO example.com and wait for a response. You should see a 250 status code and a list of supported features. This confirms the server is accepting connections.
Issue STARTTLS and wait for a 220 response. This initiates encryption. If the server rejects it, TLS isn’t supported or your client is misconfigured.
After TLS handshake completes, run AUTH LOGIN. The server should respond with a 334 code, indicating it’s ready for your username (base64-encoded). Use echo -n '[email protected]' | base64 to encode it.
Send the password (also base64-encoded) when prompted. A 235 success code means authentication passed. A 535 error means credentials are rejected—check for typos, 2FA settings, or app passwords.

Check logs and use external simulators

Let’s be honest: if you’re getting a 535 error, the server is rejecting your login. But is it during connection, TLS, or auth? Check your application or email client logs. Look for timing—was it right after the EHLO or only after AUTH LOGIN? That pinpoints the step where it fails.

The 5 steps described in “Run manual SMTP checks with command-line tools”, in order.

For broader testing, use services like MXToolbox or RFC 5321 (SMTP specification) to simulate SMTP sessions from multiple global IP ranges. This helps detect if your IP is blacklisted or if Gmail blocks certain regions.

Also, verify your Gmail account allows less secure apps (now deprecated) or uses App Passwords. If you’ve enabled 2FA, you must use an App Password, not your regular password. Misconfiguring this is the number one cause of 535 errors.

Drafting a test script? You can use tools like inbox placement testing to simulate send behavior from real ISP environments, helping you catch auth issues before they impact real campaigns.

Why your app might fail SMTP with Gmail even if others work

You're seeing a 535 error with Gmail SMTP despite correct credentials because your app likely doesn't support modern auth mechanisms like OAuth2 or App Passwords, uses outdated protocols, can't handle server challenges, or is blocked by Gmail’s IP reputation checks or rate limits—even if other providers accept the same input.

Authentication & Protocol Issues

Your app may rely on plain password authentication, which Gmail disables for most non-Google clients. Google’s security policies require App Passwords or OAuth2 for non-browser clients.
If your app doesn’t handle server challenges correctly (like responding to STARTTLS prompts or digest authentication), the handshake fails silently, often returning 535.
Some legacy libraries or frameworks still default to deprecated protocols (e.g., unencrypted SMTP or outdated TLS versions). Gmail enforces TLS 1.2+ and rejects older cipher suites.

Network, IP, and Rate Limiting Factors

Gmail checks the sending IP’s reputation. If your app routes through a shared or previously abused IP (e.g., a public cloud instance with a bad history), the connection is dropped—even with correct auth.
Firewalls or proxies may interfere with TLS negotiation, especially when using non-standard ports or when TLS handshakes are inspected. This can prevent successful encryption, leading to 535 errors.
Gmail applies rate limits to non-standard clients. Even with valid credentials, rapid or repeated connection attempts from a new or unrecognized client can trigger temporary blocks.
If your app doesn’t properly implement connection limits or retry logic, it compounds the reputation issue. Gmail may mark the source as suspicious after a few failed attempts.

Let’s be clear: a 535 error isn’t always a problem with your password. It’s often a system-level mismatch between what your app sends and what Gmail expects. Tools that don’t follow modern standards won’t work, no matter how well the credentials are entered.

For teams building or testing email workflows, verifying sender infrastructure upfront helps avoid these surprises. Bulk email list verification can catch malformed or dead addresses before they hit Gmail’s gatekeepers, saving time and reducing bounce risks.

How to use Emaillistchecker.io to avoid SMTP 535 errors

SMTP 535 errors with Gmail often happen not because of incorrect credentials, but because you’re sending to invalid, role-based, or catch-all addresses that accept auth but never deliver. Running your list through bulk verification removes these dead ends before they cause authentication failures. You’ll reduce bounces and protect your sender reputation by only sending to real, deliverable inboxes.

Prevent 535 errors with real-time list hygiene

Use bulk verification to scan your full email list and flag invalid, role-based (like admin@, sales@), or disposable email addresses before sending.
Check for catch-all domains that accept login attempts but won’t deliver emails—these often trigger SMTP 535 even with correct credentials.
Integrate the real-time verification API into your sign-up or CRM workflow to verify every new address before adding it to your SMTP send queue.
Connect Emaillistchecker.io with Mailchimp, SendGrid, HubSpot, or Klaviyo via native integrations so lists are automatically cleaned before every campaign send.
Use the in-app AI assistant to analyze patterns when certain addresses fail in other tools—sometimes it’s not the password, but domain-level issues like greylisting or IP reputation.

Understand why authentication fails beyond credentials

It’s common to assume a 535 error means a wrong password. But Gmail’s systems can return 535 for non-authentication reasons: blocked IPs, sending volume spikes, or sending to addresses that exist only for SMTP acceptance. According to RFC 5321, the 535 code applies to “authentication failure,” but delivery engines often use it broadly during envelope validation. That means the server may accept the login but still never deliver.

Let’s not assume a 535 means you messed up your credentials. Use tools to find the real root: is it a bad address? A catch-all? A temporary greylist? Emaillistchecker.io helps you sort by verdict—valid, invalid, catch-all, risky—so you know exactly what’s safe to send to.

For the final check, test inbox placement with inbox placement testing to ensure your messages reach the primary inbox, not spam. A clean list reduces the chance of hitting rate limits or trigger blocklists.

Keep your verification credits active forever—you never need to rush a cleanup when you can verify on demand. Start with 100 free checks at our pricing page to see immediate results.

Conclusion: Fix SMTP 535 by verifying data before sending

The SMTP 535 error typically isn’t caused by a wrong password. It’s triggered by account policies, improper connection setup, or sender reputation issues. Even a correct login can fail if the server flags the send as suspicious.

Preventing these errors starts long before the SMTP handshake. Validating your email list upfront removes invalid, catch-all, or role-based addresses that increase rejection risk. Never assume an address is deliverable just because it looks correct.

Email verification tools like Emaillistchecker.io catch these issues before they hit your SMTP server. With 98.9% accuracy, they test for syntax, domain validity, mailbox existence, and risk signals — all in bulk, in real time, and with no expiration on purchased credits.

Sources

Only 39.3% of email senders said they were fully aware of Gmail and Yahoo's bulk sender requirements, and 23% reported real deliverability problems after enforcement began. — Mailgun State of Email Deliverability (2024)
Deliverability experts classify a bounce rate under 1% as excellent, 1–2% as acceptable, 2–5% as concerning, and anything over 5% as dangerous for sender reputation. — Verified.email bounce rate benchmark (2025)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does SMTP 535 mean when sending via Gmail?

SMTP 535 means authentication failed. Gmail rejected the login attempt, even with correct credentials, due to security policies or configuration issues.

Can I use my regular Gmail password for SMTP?

Only if 2FA is disabled. If 2FA is on, you must use an App Password instead.

Why does Gmail block my app from using SMTP?

Gmail blocks apps that don’t meet security standards—most commonly due to disabled 2FA, outdated authentication methods, or poor sender reputation.

Can a bad email list cause SMTP 535 errors?

Indirectly. Sending to invalid or role accounts may trigger server-level security checks or IP reputation drops that increase SMTP failure rates.

How do I test if my SMTP connection is secure?

Use Telnet or OpenSSL to connect to smtp.gmail.com on port 587, then check that TLS negotiation occurs and the server responds properly to AUTH commands.

Does Emaillistchecker.io check for Gmail-specific issues?

It identifies invalid, disposable, role, and catch-all addresses—common root causes of SMTP failures—before you attempt delivery.

What’s the difference between a 535 error and a 550 error?

SMTP 535 is authentication failure; 550 usually means the recipient address is invalid or rejected by the server.

Can a shared IP cause SMTP 535 errors with Gmail?

Yes—shared IPs with poor reputation may trigger Gmail’s security filters, even with correct credentials.

What happens if I send emails to role addresses?

Gmail often rejects them silently. Role accounts like info@ or admin@ are frequently used for spam traps and may be blocked.

Are disposable email domains a common cause of SMTP 535 errors?

No—but they often lead to high bounce rates or sender reputation damage, which can indirectly trigger SMTP rejections.

How often should I verify my email list?

Before every major send. Even valid addresses can become invalid over time; regular verification keeps bounce rates low.

Is there a free way to check if an email is valid?

Yes—Emaillistchecker.io offers 100 free verifications to start. You can verify a list or single address without charge.