Why does SMTP 535 happen when using Google Cloud services?

You set up a service account, generated credentials, and tried to send email via Gmail’s SMTP — but the connection fails with SMTP 535: Authentication credentials invalid. You’re not alone. This error doesn’t usually mean your password is wrong, your network is blocked, or your app is misconfigured. It means the service account lacks the right role in Google Cloud IAM.

Think of it like having a library card that grants access to the building—but not to the periodicals section. You’re authenticated, but not authorized to check out certain resources. The same applies when a service account can authenticate but lacks permissions to send email using Gmail’s SMTP or API endpoints.

You’re not dealing with a network glitch or a typo. The credentials are correct, but the role assigned to the service account doesn’t include the scopes needed to send mail. This is the most common root cause of SMTP 535 failures in Google Cloud integrations.

Key takeaways

  • SMTP 535 failures during Gmail SMTP or API use are almost always due to missing IAM roles, not credential errors.
  • Even with valid service account credentials, insufficient permissions prevent successful email transmission.
  • Fixing the issue requires adding the correct IAM role (like `roles/gmail.send`) to the service account, not adjusting passwords or network settings.

What service account role is required to send emails via Google Cloud SMTP?

You need to assign the roles/gmail.send role explicitly to your service account in Google Cloud IAM. Without this, even if the account has broader permissions like Project Editor, you’ll hit an SMTP 535 authentication failure. This role grants the minimal, required access to send emails via Gmail’s API or SMTP relay. Ensure it’s assigned directly—don’t rely on inherited or indirect roles.

Required roles and permissions

  • Assign roles/gmail.send to the service account in the Google Cloud IAM console. This is the only role that grants the right to send mail using Gmail's API or SMTP.
  • If using GCE, ensure the service account has roles/compute.instanceAdmin.v1 for instance management, and roles/gcp-iam-iam with serviceAccountTokenCreator for token generation.
  • Never assume Editor or Owner roles grant gmail.send. These are insufficient and will result in 535 failures regardless of other settings.
  • Use the Google Cloud IAM documentation to verify role assignments and avoid dependency on legacy or inferred permissions.

Common pitfalls and how to avoid them

  • Using a service account with only Project Editor or Viewer roles will fail. Even with full project access, gmail.send is not included by default.
  • Running SMTP client libraries like Node.js nodemailer or Python smptlib without the correct IAM role leads to 535 errors—your code may be correct, but the access isn’t.
  • Check your API enablement: ensure the Gmail API is enabled in your project’s APIs & Services dashboard. A missing API doesn’t trigger 535—but it does prevent delivery.
  • Use OAuth 2.0 with a service account key or workload identity. Avoid using personal Gmail accounts for automation—this breaks at scale and triggers security warnings.

How to verify your Google Cloud service account has the right role

If you're hitting an SMTP 535 authentication failure when sending via Gmail API or SMTP with a Google Cloud service account, the issue is likely missing the roles/gmail.send permission. You must assign it directly to the service account in the IAM console—roles inherited from folders or projects won't work. Use the exact role name and ensure no organizational policies override it.

Check and assign the required role in Google Cloud Console

  1. Go to the Google Cloud Console and navigate to IAM & Admin → IAM.
  2. Use the search bar to locate the service account you’re using for Gmail API or SMTP access. It typically has a name like [email protected].
  3. Look at the Roles column. Verify it includes roles/gmail.send. If it’s missing, click Edit next to the account.
  4. Click Add another role, then type roles/gmail.send in the search box. Select it exactly as written—no typo, no alternate name.
  5. Click Save. Changes apply immediately, but you may need to re-authenticate your app or reconnect the service account.

Why direct role assignment matters

Google Cloud’s IAM system allows roles to be inherited from parent resources like folders or organizations. However, the Gmail API requires role assignments to be explicit on the service account itself. Inherited roles are effectively ignored for this specific API—this is a known behavior documented in Google’s APIs & Credentials documentation.

Even if you've granted roles/gmail.send at the project level, the service account still won't work unless the role is assigned directly to it. This common oversight causes 535 errors even when everything else—the client ID, secret, and scopes—appears correct.

Once the role is properly assigned, retry your SMTP or API request. If the error persists, check your application’s authentication flow to confirm it’s using the correct service account key and scopes (https://mail.google.com/). You can test the key in tools like inbox placement testers to verify delivery behavior without full-scale sending.

What happens if the service account lacks the correct role?

If your Google Cloud service account doesn’t have the right IAM role assigned—like roles/compute.viewer or roles/iam.serviceAccountTokenCreator—the SMTP server will reject your authentication attempt with a 535 5.7.8 Username and Password not accepted error, even with a valid service account email and access token. The issue isn’t in your code or credentials—it’s that the service account lacks the minimal permissions to authenticate at all.

The root cause is IAM permission, not SMTP config

You’re seeing this error because Google Cloud’s security layer checks IAM roles first—before any SMTP handshake begins. Even if your app password is correct (which it isn’t in this case—the access token is the real credential), the server refuses access if the service account lacks the required role to act on behalf of the project.

Let’s say you’re trying to send via Gmail’s SMTP with a service account. The service account must have a role that grants it permission to access the Google App SMTP API. Without it, the backend auth system returns 535 immediately. You can’t "fix" this in the client code. No retries, no token refresh, no password change will help.

How to confirm and fix it

Check the IAM page in the Google Cloud Console: navigate to your project, go to Identity & Access Management, and verify the service account has a role that lets it initiate OAuth2 or impersonate users. If it only has roles/storage.objectViewer, it won’t be able to send email.

Google’s documentation on IAM roles explains how permissions cascade and how to assign them correctly. This isn’t about the SMTP server’s settings—it’s about Google Cloud’s permission model.

If you’re using an email service that relies on Google Cloud’s SMTP, and you’re still getting 535 errors, confirm the service account has at least one role that grants access to the APIs it’s trying to use. A common mistake is assuming that just having a service account email and access token is enough. It isn’t. The role dictates what the account can do, regardless of authentication success.

Once you assign the correct role, wait 1–2 minutes for propagation, then retry. The 535 error should disappear. No code change required—just permission update.

Why do some developers misdiagnose this as a credential issue?

SMTP 535 errors often look like credential problems, but they’re frequently caused by missing roles in Google Cloud, not expired or incorrect keys. Tools like Postman or Gmail’s OAuth Playground only report “invalid credentials,” which hides the real issue: the service account lacks the necessary permissions to access the target API. This leads teams to regenerate keys or re-authenticate—steps that don’t fix the underlying role scope problem.

Why the error message is misleading

The 535 response code is generic. It means “authentication failed,” but it doesn’t specify whether the failure came from a bad password, an expired key, or a missing role. Since the error doesn’t distinguish between these causes, developers naturally assume it’s a credential issue, especially when they see authentication in the stack trace.

Even OAuth tooling, designed to help with auth flows, doesn’t expose granular permission failures. You might see a “token invalid” error while the real issue is that the scope required for sending messages through Gmail’s API isn’t granted to the service account. This gap between visibility and actual cause creates a common blind spot.

The role scope confusion

Google Cloud uses fine-grained roles to control access to APIs. A service account with valid credentials still fails if it’s not assigned the right role—like roles/gmail.send for sending via Gmail’s API. Without this, the API call is rejected at the authorization layer, even with a perfect key.

Let’s say you’ve set up your app correctly, generated a key, and configured your environment. The code works locally. But when deployed, you get 535. The credentials are correct. The key hasn't expired. The real fix? Assigning the service account the proper role in the Cloud Console, not regenerating anything.

It’s a classic case of misaligned focus. You’re treating the symptom—the error code—while ignoring the root cause—the missing role. This happens often because Google’s documentation for role-based access is detailed, but the error response doesn’t point there. You have to know to check the IAM console.

For teams troubleshooting API integrations, this kind of mismatch can cost hours. It’s not about the code, nor the key. It’s about permissions. The fix is simple once you know to look there.

How does Emaillistchecker.io help prevent this issue before it causes delivery failures?

By catching invalid, malformed, or high-risk email addresses before you send, Emaillistchecker.io stops SMTP 535 authentication failures caused by poorly managed lists—especially those tied to misconfigured service accounts. You’re not just cleaning up after failed deliveries; you’re preventing the root causes, like sending to role-based or non-existent addresses, which often trigger authentication errors when the domain denies access. With 98.9% accuracy, you reduce bounces and protect sender reputation, minimizing the chance that repeated 535 errors flag your domain as suspicious.

Scan your lists before sending—with real-world accuracy

SendGrid and Mailchimp integrations let you run pre-send checks through Emaillistchecker.io’s bulk verification tool. It checks each address against the actual domain, filtering out invalid entries, catch-all domains, and role accounts (like admin@ or info@) that often trigger 535 errors when the service account lacks proper permissions. This isn’t guesswork—it’s real-time validation based on how the receiving mail server responds to a probe. You’re not just guessing; you’re seeing what the server actually permits.

Validate at scale, and catch configuration risks early

Using the real-time Verification API, you can validate individual emails as they enter your system—before they ever hit your ESP. This catches malformed addresses, outdated domains, or roles that won’t accept mail, even if the underlying service account is misconfigured. Each check mimics how an actual mail server would respond, catching issues like missing MX records or greylisting that can lead to 535 failures when the sending service isn’t authorized to send through that domain.

High bounce rates and repeated 535 failures damage sender reputation significantly. According to the APWG, even a small spike in delivery errors can signal spam behavior to filtering systems, increasing the likelihood of being blocked. Emaillistchecker.io’s 98.9% accuracy rate means fewer bad addresses make it through, reducing those failure signals. This isn’t just cleaner data—it’s smarter deliverability.

Integrations with platforms like SendGrid and Mailchimp mean you can automate verification right before sending, layering a quality gate that catches domain-level delivery risks—like incorrect authentication setup—before they cause a 535 error. See how it works with your existing tools. You’re not just verifying emails—you’re reducing the risk of infrastructure-level failures that harm deliverability. This is prevention, not post-mortem cleanup.

What role does DNS and domain configuration play in SMTP 535 failures?

None. SMTP 535 authentication failures stem from incorrect or missing credentials at the service account level in Google Cloud—not from DNS settings like SPF, DKIM, or DMARC. These records govern message authenticity and reputation, not login validation. A 535 error means the server rejected your identity during authentication, which is independent of domain policy checks. Fixing DNS won’t resolve this issue. It’s about permissions, not deliverability.

Why DNS misconfigurations don’t cause 535 errors

  • SPF records control which mail servers are allowed to send on your domain’s behalf, but they only trigger 550 or 554 rejection codes if violated, not 535.
  • DKIM signing ensures message integrity; a missing or failed signature results in rejection after message ingestion, not during login.
  • DMARC policies govern how receivers act on SPF and DKIM results. Again, these affect delivery decisions post-authentication, not login phase errors.
  • When you see a 535 response, the receiving server is saying: “I don’t recognize your credentials,” not “Your message doesn’t match our domain rules.”
  • Let’s be clear: if your SMTP client is rejected with 535, check the Google Cloud IAM role assigned to the service account—not your DNS records.

Google Cloud IAM roles are the real culprit

  • Make sure your service account has the correct role: roles/compute.serviceAccountTokenCreator or equivalent for OAuth2 authentication.
  • Use Google Cloud’s IAM console to verify the member has been granted the exact role needed for SMTP authorization.
  • Role mismatches are common after service account recreation or project migration—re-verify the assignment.
  • Changes take effect immediately after role validation, so no need to wait or restart services.
  • For bulk sender validation, use bulk verification to catch invalid or misconfigured recipients early.
Even if all DNS records are perfect, a service account with no valid login permissions will always fail with a 535 error. That’s not a delivery issue—it’s a permissions issue.

For context on how authentication works in email systems, refer to RFC 5321 (SMTP) and the OAuth2 specification. These define the expected handshake, where 535 is a clear indicator of failed identity proofing.

Can a missing service account role cause all outgoing mail to fail?

Yes — if your application relies on Google Cloud’s Gmail API and the service account lacks the gmail.send permission, outgoing mail will fail with an SMTP 535 authentication error. Other GCP services like Cloud Storage or BigQuery continue to work normally. The issue isolates to email-sending actions, not overall access.

The Scope of the Failure

Even if the service account has roles for storage, database queries, or API access, a missing gmail.send permission blocks only email delivery. You can still run queries, access buckets, or call other APIs without issue. The 535 error appears strictly during SMTP authentication when the system verifies the account’s right to send mail.

Let's say you're using a shared service account across multiple tools. Access to BigQuery or Cloud Storage isn’t affected. But if your app attempts to send a transactional email via Gmail API, it fails. This is why you might see consistent 535 errors only for email functions, not other workflows.

Why the Error Is Specific to Gmail Sending

Google Cloud’s IAM system grants granular access. The gmail.send permission is separate from general API access or admin roles. Without it, the Gmail API denies the request, returning SMTP 535 — a standard code meaning "authentication failed" — even if the credentials are otherwise valid.

For reference, Google’s IAM documentation confirms that access decisions are based on individual permissions, not account-level roles alone. This allows fine-grained control across services. You'll find the full list of required permissions in the Gmail API OAuth2 scopes documentation, which lists https://www.googleapis.com/auth/gmail.send as the minimal required scope.

In most cases, the failure isn’t due to a misconfigured SMTP password or server issue. It’s an IAM policy gap. Check your service account’s bindings in the Google Cloud Console under IAM & Admin — ensure it includes the specific Mail Sender role or custom role with gmail.send enabled.

If you're unsure, use the bulk email verification tool to test whether delivery problems stem from invalid addresses or infrastructure misconfiguration — a useful first step to rule out list hygiene issues.

How to test if the role fix resolves the SMTP 535 issue

After assigning the roles/gmail.send role to your service account, re-authenticate using the updated key and send a test email via SMTP or the Gmail API. A successful send confirms the role is properly configured; if not, verify your credential scope with the default access token.

Test the fix step by step

  1. Re-authenticate with the new key using gcloud auth activate-service-account and point it to the updated service account JSON file. This ensures your local environment uses the latest credentials with the correct permissions.
  2. Send a test email using either the Gmail API or an SMTP client (like SMTP with Gmail’s servers). Use the same credentials you’ve just re-authenticated with. A successful delivery means the role was correctly assigned.
  3. If the 535 error persists, check the token scope by running gcloud auth application-default print-access-token and inspecting the resulting JWT. Ensure it includes the https://www.googleapis.com/auth/gmail.send scope. Without this, even a proper role won’t work.
  4. Verify the token payload using a tool like jwt.io to confirm the scopes match expectation. Missing scopes indicate an issue with how the credentials were generated or applied.
  5. Review service account status in the Google Cloud Console. Ensure it's active, not deleted, and that the role is assigned at the correct project or folder level. Role inheritance or misconfigured resource hierarchy can block access.

When in doubt, check the logs

Even if the role and token appear correct, some failures stem from rate limits, IP restrictions, or Gmail’s sending policies. Use the Gmail API documentation to cross-check your request frequency. Exceeding limits can trigger 535 errors even with valid credentials.

Never assume a role assignment is active immediately. It can take up to a minute for IAM changes to propagate. Let’s not skip the test step — a successful send is the only proof you have.

Why is SMTP 535 failure often overlooked in delivery troubleshooting?

SMTP 535 authentication failures due to incorrect Google Cloud service account roles are frequently missed because most troubleshooting guides focus only on DNS records, sender reputation, or daily send limits—not IAM permissions. Teams often misdiagnose the error as a simple credential issue, not recognizing it stems from Google Cloud’s role-based access control, which is rarely covered in basic email setup documentation.

The blind spot in standard email delivery checks

Most tools and guides focus on SPF, DKIM, and DMARC alignment, or check for rate limits and blacklists. They rarely address the role assignments required for service accounts to authenticate via SMTP with Google Cloud’s mail servers. This gap leaves teams looking for DNS misconfigurations or IP reputation issues when the real problem is a missing or misconfigured IAM role.

When a service account lacks the proper role—like roles/compute.editor or roles/gmail.send—Google Cloud returns a 535 error indicating "authentication failed." But the sender tool or email library sees only the generic message. Without context, teams may retry with the same credentials, change nothing, and waste time on red herrings.

Why the error slips through the cracks

Google Cloud’s documentation is technically thorough but assumes familiarity with IAM concepts like service account creation, role binding, and project-level permissions. Newer engineers or non-SRE teams often don’t have this baseline knowledge. This leads to confusion: “Why does my key work locally but not in production?” The answer may be a role not assigned at the project level—something not immediately obvious from the error code alone.

Unlike a bounce from a bad email address or a blocklist hit, a 535 error won’t trigger immediate alerting in most systems. It’s a silent failure in the SMTP handshake. Without logging the full SMTP response or checking the Cloud Console audit logs, teams don’t see the root cause until after multiple failed attempts.

Even when the error is seen, diagnosing it requires drilling into Google Cloud’s IAM and audit logs—steps beyond most email delivery checklists. Google’s IAM documentation provides the correct guidance, but it’s not built into email deliverability tools. This gap means teams are often left to debug the issue manually, one trial at a time.

Let’s be honest: most systems don’t flag a 535 error for poor role configuration. To avoid this, ensure your service account has the minimal required roles for Gmail API access. You can test email list integrity and sender readiness beforehand with tools that validate addresses and detect known delivery blockers—like bulk verification to catch invalid entries before sending.

Summary: Solving SMTP 535 by fixing service account roles

SMTP 535 authentication failures when using Google Cloud’s SMTP service are almost always rooted in IAM misconfiguration, not credential leaks or OAuth issues.

The fix is simple: ensure the service account has the roles/gmail.send role explicitly assigned in the Google Cloud Console IAM section. This role is required to authorize sending through Gmail’s SMTP servers.

Verification and prevention

  • Always confirm the role assignment directly in the Google Cloud Console—don’t assume it’s inherited or applied via a parent project.
  • Use tools like Emaillistchecker.io to validate email lists and domain configurations before sending, reducing the risk of sender reputation damage from invalid or compromised addresses.

Sources

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 from Google Cloud?

SMTP 535 means authentication failed. In Google Cloud, this usually means the service account lacks the required `roles/gmail.send` role, not invalid credentials.

Can I fix SMTP 535 without changing Google Cloud IAM?

No. If the error is due to missing permissions, only a correct IAM role assignment resolves it. Re-generating keys or changing passwords won’t fix role-based access denial.

Does using Gmail API require the same role as SMTP?

Yes. Both methods require `roles/gmail.send` to send messages. The role is independent of authentication method.

How do I know if my service account has `roles/gmail.send`?

Check the Google Cloud Console under IAM & Admin → IAM. Look for the role explicitly assigned to your service account.

What’s the difference between `roles/gmail.send` and `roles/gcp-iam-iam`?

`roles/gmail.send` allows sending emails; `roles/gcp-iam-iam` manages identity and access within Cloud IAM. Both may be needed, but only the former enables email sending.

Why does my app work locally but not in production?

The service account used in production likely has no `roles/gmail.send`. Local environments may use a different account with broader permissions.

How can I prevent SMTP 535 failures in future deployments?

Enforce role assignment in infrastructure-as-code templates and include IAM role checks during CI/CD pipeline validation.

Does Emaillistchecker.io detect Google Cloud IAM role issues?

No. It doesn’t access Google Cloud IAM or service account roles. But it helps prevent delivery failure by catching invalid or risky email addresses early.

Can a catch-all domain cause a 535 error?

No. Catch-all domains don’t cause SMTP 535 errors. 535 is about identity and permissions, not domain policies.

What’s the role of SPF when seeing SMTP 535 failures?

SPF has no effect on SMTP 535. The error is about authentication—not domain-level policy. SPF issues typically cause 550 or 554 errors.

How long does it take for a role change to take effect?

Most changes apply immediately. However, some clients cache credentials; restarting the sending service or re-authenticating may be required.

Can I use one service account for multiple projects?

Yes, but you must grant `roles/gmail.send` in each project’s IAM settings separately. Role permissions are project-scoped.