Fix Gmail API SMTP 535 Error with Correct Service Account Ro

Why Does SMTP 535 Error Appear When Using Gmail API?

You’ve double-checked your password. You’ve rerun the OAuth2 flow. The code looks right. Yet Gmail API still rejects your request with SMTP 535: “Authentication credentials invalid.” This isn’t a typo. It’s a permission problem.

The error isn’t about your password — it’s about your service account’s role. Even with correct credentials, Gmail API will reject access if the account lacks the right OAuth2 scopes or Google Cloud roles, like Gmail API access or the proper IAM role.

Think of it like trying to enter a secure building. You have the right ID badge, but the door only opens if your badge has the correct access level. A service account without proper role assignment is locked out — no matter how valid the login details.

Key takeaways

SMTP 535 errors in Gmail API are commonly caused by missing IAM roles or incorrect OAuth2 scopes, not invalid credentials.
Even with valid service account keys, Gmail API access requires explicit role assignments in the Google Cloud Console.
Fixing the error means verifying both OAuth2 scopes (like https://mail.google.com/) and IAM roles (like Mail Sender or Gmail API Reader).

What Is a Service Account in Google Cloud, and Why Does It Matter?

A service account is a special Google Cloud identity that lets your application access APIs like Gmail API without needing a real person to sign in. It’s designed for backend processes and automations, replacing user-level credentials with secure, programmatic access. If you skip assigning the right roles, even a perfectly configured key and endpoint will fail — and that’s where the SMTP 535 error often shows up.

How Service Accounts Work Under the Hood

When you use the Gmail API, your app needs proof it’s authorized. Instead of logging in with a Gmail user, it uses a service account — a machine identity tied to your Google Cloud project. This identity is backed by a private key file you download and use to sign requests.

Google Cloud doesn’t trust just anyone. It checks the service account’s assigned roles. Roles define what the account can do — like reading emails, sending messages, or managing labels. No role? No permissions. That’s why you’ll see a 535 error even with a valid email and correct API endpoint: the account simply isn’t allowed to act.

Why Permissions Are the Silent Killer

You might double-check your OAuth scope, verify your credentials, and test your API endpoint — all while missing the real issue: the role assignment. The Gmail API requires specific permissions like https://www.googleapis.com/auth/gmail.send or https://www.googleapis.com/auth/gmail.modify.

Even if your service account has the correct key and project setup, granting it the wrong or missing role means the request is rejected before it reaches the Gmail server. This isn’t a networking issue. It’s a policy enforcement failure. Google’s documentation confirms this via its IAM permissions model, which governs access control across all Google Cloud services.

Let’s say you’re building a tool to send transactional emails. Without the proper scope and role, your app sends a request that hits Gmail's servers — but gets shot down immediately with a 535 error because authorization failed at the identity layer. Fixing it isn’t about changing code. It’s about ensuring the service account has the required roles in the IAM console.

Once the roles are assigned correctly, you can move on to testing. And if you’re validating a list of email addresses for your email campaigns, you might want to check if they’re deliverable before sending — which is where tools like bulk email verification help eliminate invalid addresses before they trigger delivery issues.

How to Assign the Proper Role to Fix SMTP 535 Error in Gmail API

SMTP 535 errors in Gmail API usually stem from insufficient service account permissions. To fix it, go to the Google Cloud Console, navigate to your project’s IAM & Admin > Service Accounts, select the service account your app uses, and assign both the 'Gmail API Reader' role and the 'Service Account Token Creator' role. Save the changes and wait up to 5 minutes for them to propagate.

Step-by-step: Assigning Roles in Google Cloud

Go to the Google Cloud Console and open your project. You must be using the correct project where your Gmail API integration is configured. Make sure your credentials (service account key) are tied to this project.
Navigate to IAM & Admin > Service Accounts. This is where Google manages identity and access control for your cloud resources. Service accounts are used by applications to authenticate and access APIs.
Select the service account used by your application. If you’re unsure which one to pick, check your app’s configuration for the email address ending in @.iam.gserviceaccount.com.
In the 'Permissions' section, click 'Edit' to add roles. Each role grants specific access. You're not just adding permissions—you're defining what the service account can do with Gmail data.
Add the 'Gmail API Reader' role (or 'Gmail API' role if available). This role allows the account to read mailbox data. Without it, the API call will fail with a 535 error due to lack of access.
Ensure the account has the 'Service Account Token Creator' role. If your app uses OAuth2 and needs to generate tokens dynamically, this role is required. Without it, token creation fails, disrupting authentication.
Save changes. Google applies updates asynchronously. Wait up to 5 minutes for the roles to take effect across the system.

Why This Fixes the 535 Error

SMTP 535 errors in Gmail API often mean the server rejected the authentication attempt due to insufficient privileges. By explicitly granting the right roles, you’re correcting the underlying issue—misconfigured access. According to Google's OAuth2 documentation, service accounts must have precise permissions to access restricted APIs.

The 7 steps described in “Step-by-step: Assigning Roles in Google Cloud”, in order.

A missing or incorrect role is one of the most common misconfigurations. You can validate your setup using tools like Google’s developer resources or the OAuth2 Playground. For teams handling large email lists, verifying email validity and deliverability upfront can prevent issues like this at scale. See how bulk verification with EmailListChecker helps catch invalid or risky addresses before they’re sent.

What Are the Required Roles for Gmail API Access via Service Account?

You need at minimum the Gmail API Reader role to read messages, and the Service Account Token Creator role to impersonate users via OAuth2 tokens. Avoid granting Owner or Editor roles—use least-privilege principles. Google’s OAuth2 documentation confirms that token creation requires explicit permission, not just access to the API.

Essential Roles for Gmail API Access

Gmail API Reader (or roles/gmail.api.reader): Grants read-only access to the user’s mailbox. Required for any operation that reads emails, labels, or threads via the API.
Service Account Token Creator: Required when your app impersonates a user. Without this, you cannot generate OAuth2 tokens for user-level access, even if the user has granted consent.
Cloud Resource Manager Project Viewer (roles/resourcemanager.projectViewer): Not mandatory, but helpful when troubleshooting access across Cloud projects or IAM policies. Provides visibility into project configurations.

Principle of Least Privilege: Why It Matters

Using Owner or Editor roles exposes your infrastructure to unnecessary risk. These roles grant broad permissions across all resources in a project, increasing the attack surface. Google recommends limiting permissions to only what’s needed—this is how you avoid accidental data exposure or unauthorized actions.

For example, if your app only reads email metadata and doesn’t modify messages or send mail, assigning Reader roles is enough. If you need to send messages via impersonation, then add Service Account Token Creator, but still avoid full project access.

When in doubt, use our verification API to test email endpoints before integrating with Gmail APIs—ensuring your email list is clean and reducing the chance of failed auth due to invalid or misconfigured addresses.

Why You Might Still Get 535 Errors After Assigning Roles

You might still get a 535 error after assigning roles if the service account isn’t set up for domain-wide delegation, the OAuth2 scopes in your request are missing or incorrect, the service account key has expired or been regenerated without updating your app, or Google Cloud API access was inadvertently disabled at the project level. These are common missteps even after role assignment, and they often cause authentication failures that look like permission issues.

Domain-Wide Delegation Is Required for User Impersonation

If you're impersonating users in Gmail API, the service account must be granted domain-wide delegation in the Google Admin Console. Without this, even a correctly assigned role won’t let you act on behalf of users. The key step here is enabling "Delegated Domain-wide Authority" under API controls. If it’s not enabled, the API will return a 535 error, regardless of role level.

Google’s own documentation on service accounts and domain-wide delegation is the definitive source — you can review the process at Google’s service account docs.

Scopes, Keys, and Project-Level Access Matter

Your OAuth2 request must include the exact scopes needed. A common missing scope is https://www.googleapis.com/auth/gmail.readonly, which is required to access user mail. Missing scopes cause 535 errors even with proper roles. Double-check the scope in your token request.

Also, service account keys expire after 1 year and can be regenerated at any time. If you regenerated the key but didn’t update your app, the old key won’t work. The most frequent cause of post-role 535s is using an expired or outdated key.

Finally, check your Google Cloud project. API access might be disabled due to billing issues, project deletions, or accidental API disablement. A disabled API will reject all calls with a 535 error. You can confirm this in the Cloud Console under "APIs & Services > Library".

Let’s be honest: even with perfect roles, one missing scope or expired key can break everything. Always validate delegation settings, scopes, key age, and API status — they’re the hidden gatekeepers behind every 535 error.

If you're managing large email lists and notice unexpected failures like this, it’s worth verifying the accuracy of your email addresses before sending. Use tools that check validity in bulk, like bulk email verification, to reduce delivery issues at the source.

How to Verify Service Account Role Assignment Is Effective

After assigning roles to your service account, you must confirm they’re active and correctly applied. Use the Google Cloud SDK to fetch the IAM policy, verify the required roles exist and aren’t marked as 'removed', then test API access with a minimal script. A 200 response confirms success; 535 means authorization is still missing.

Step-by-step verification process

Fetch the current IAM policy: Run gcloud projects get-iam-policy [PROJECT-ID] in your terminal with the appropriate project ID. This returns the full IAM configuration for the project, including all assigned roles for every service account.
Check for required roles: Look through the output for roles like roles/gmail.send, roles/iam.serviceAccountTokenCreator, or any other permission critical to your use case. Ensure they appear in the bindings section and are not listed under deleted: true. Roles with removed status are effectively inactive.
Validate permissions with a minimal script: Write a simple test script using the service account key and OAuth2 flow to request an access token and attempt a basic Gmail API call—like listing unread messages in the user's inbox. This simulates real API usage and catches policy mismatches early.
Monitor response codes: If your test returns a 535 (authentication failed), the role assignment is still not effective. Common causes include incorrect project ID, missing scopes, or roles not applied at the project level. A 200 response confirms the roles are correctly assigned and the service account can now access the API.

What to do if you still see a 535 error

Even after confirming role presence, a 535 error can persist due to token expiration, incorrect scopes, or misconfigured service account keys. Ensure the OAuth2 flow uses the correct scope (e.g., https://www.googleapis.com/auth/gmail.send) and that you’re not relying on deprecated scopes.

Google’s documentation on OAuth 2.0 and service accounts is considered the authoritative reference for correct setup. Always refer to the official IAM roles documentation when validating your configuration.

Once verified, you can proceed with production workflows with confidence. For teams managing large volumes of email-related automation, ensuring role precision prevents costly delays and delivery failures.

Common Mistakes That Cause SMTP 535 Errors Despite Correct Roles

You’re seeing SMTP 535 errors in Gmail API despite assigning what you think are correct roles because you’re using a regular user account instead of a service account, forgot to enable the API in Google Cloud, skipped domain-wide delegation, or used the wrong email format in the OAuth2 scope. These are common setup traps that break authentication—even when permissions appear correct.

The Service Account Misstep

Using a regular user account or a personal Google account key instead of a dedicated service account. The Gmail API requires a service account for server-to-server use; user accounts don’t support delegated access correctly.
Not creating a service account key file in the Google Cloud Console. A key is required for OAuth2 authentication. Missing or expired keys trigger 535 errors.

Missing API and Delegation Setup

Failing to enable the Gmail API in the Google Cloud Console before attempting authentication. Without it, the API endpoint rejects all requests—even with valid credentials.
Not enabling domain-wide delegation for the service account. If your app needs to impersonate users (e.g., send as a user), you must grant the service account permission to do so in the Google Admin Console.
Using the service account email (e.g., [email protected]) in the OAuth2 scope instead of the actual user’s email address. The scope must reference the target user’s email, not the service account.

Verification and Real-World Checks

Even if all settings are correct, syntax errors or invalid scopes can still result in 535. It’s worth validating your OAuth2 token request with tools like Google’s OAuth2 Playground to catch scope mismatches early. You can also test your API endpoint with a minimal request to isolate the issue.

If you’re still stuck, audit every step: verify the service account is added as a delegate in the Google Admin Console, confirm API access is enabled, and double-check that the email in the scope matches the target user exactly. A single character mismatch breaks authentication.

For teams managing high-volume email flows, verifying email addresses and sender infrastructure upfront reduces delivery risk. You can test inbox placement and sender reputation using inbox placement testing tools, like the one available at inbox placement testing.

Best Practices for Maintaining Service Account Access and Avoiding 535 Errors

To prevent SMTP 535 errors when using the Gmail API, ensure your service account has only the minimal roles required, use short-lived credentials, rotate keys every 90 days, never hardcode secrets, and monitor auth logs for failed attempts. These steps reduce exposure, enforce security, and maintain consistent access.

Secure Credential Handling

Use short-lived access tokens and refresh tokens instead of long-lived credentials when possible.
Rotate service account keys every 90 days—this aligns with industry standards and minimizes risk from compromised keys.
Avoid hardcoding service account JSON keys in your source code. Instead, use secret management tools like Google Secret Manager or AWS Secrets Manager.
Store credentials in environment variables or secure vaults, not in plain text files or version control.

Role and Access Management

Assign only the minimum required roles—never grant "Owner" or "Editor" unless absolutely necessary.
Use IAM roles such as Mail or Service Account Token Creator to limit scope to just what the app needs.
Monitor authentication logs in Google Cloud's Audit Log system to detect failed login attempts or unusual activity.
Set up alerts for multiple failed attempts to catch potential brute-force or misuse early.
Regularly audit service account permissions using the Google Cloud IAM Logs and remove unused or expired access.

When you're managing multiple APIs or services, validating access and credentials across the stack helps isolate issues quickly. For instance, if your app fails to authenticate, checking the service account’s role and expiration status often reveals the root cause before you alter code or reset workflows.

How Email Verification Tools Like Emaillistchecker.io Can Help Prevent SMTP 535 Errors

Verifying your email list before using the Gmail API reduces the risk of SMTP 535 authentication failures by eliminating invalid addresses that trigger repeated failed delivery attempts and trigger rate limiting or account flags. A clean list means fewer connection errors and more reliable send rates.

Why List Quality Matters Before Sending via Gmail API

SMTP 535 errors often stem from Gmail rejecting login attempts due to patterned failures — like repeatedly connecting to non-existent addresses. These failures can signal abuse, prompting Gmail to block your service account. Preventing this starts with a clean list.

Before hitting the API, confirm each email address is valid, active, and capable of receiving mail. Tools like Emaillistchecker.io do this at scale with 98.9% accuracy, filtering out typos, role accounts, and non-existent domains. This reduces stress on your sending infrastructure and protects your sender reputation.

By catching invalid emails early, you avoid the chain reaction that leads to SMTP 535: failed connections → rate limiting → authentication issues → blocked access. It’s not about the API settings alone — it’s about feeding it data that works.

Beyond Basic Validation: Inbox Placement and Workflow Integration

Basic syntax checks aren’t enough. Many tools only confirm format or domain existence, but Emaillistchecker.io goes further, testing whether emails actually land in the inbox — not just the SMTP layer. This inbox-placement testing reveals issues like spam filtering or blacklisting before you send.

For teams using Mailchimp, SendGrid, or Klaviyo, the integration feature ensures verified lists flow directly into your workflow, reducing manual steps that can introduce errors. You’re not just cleaning the list — you’re automating trust into your campaigns.

Use the real-time verification API to check individual addresses during sign-up or data capture, or leverage bulk verification for large campaigns. Both options are designed to work with standard authentication flows — including Gmail API — ensuring you only send to addresses that can receive mail.

With features like catch-all detection and disposable domain filtering, Emaillistchecker.io removes the guesswork. You send from a cleaner, more reliable list. This directly lowers the chance of SMTP 535 errors tied to failed delivery attempts.

Find out how it works: verify a list in bulk, integrate real-time checks into your app, or test inbox delivery before you send. Your Gmail API will thank you.

Summary: Preventing SMTP 535 Errors in Gmail API Requires Both Access and List Integrity

SMTP 535 errors in Gmail API are rarely due to incorrect passwords. They more often indicate a missing or misconfigured service account role in Google Cloud Console.

Assigning the correct roles—like `Gmail API User` and appropriate OAuth scopes—is essential for authentication to succeed. Without it, even valid credentials fail.

Why Lists Matter, Even With Correct Permissions

Even with proper access, messages may fail if sent to invalid, catch-all, or role-based addresses (e.g., admin@, contact@). These addresses often trigger rejection, false negatives, or greylisting.

Catch-all domains accept all incoming mail, which inflates bounce rates and harms sender reputation. Role accounts are frequently flagged as low-quality by filtering systems.

Best Practice: Combine Access Control with List Hygiene

Verify every email before sending. Clean lists reduce bounce rates, improve inbox placement, and prevent delivery delays.

Robust deliverability starts with two layers: correct service account access and a validated email list.

Sources

Gmail classifies anyone sending close to 5,000 or more messages to personal Gmail accounts in 24 hours as a bulk sender — and that status is permanent once triggered. — Google Email Sender Guidelines FAQ (2024)

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 error mean when using Gmail API?

SMTP 535 indicates authentication failure. It typically means the service account lacks proper permissions or the OAuth2 scopes are incorrect.

Which role do I need for Gmail API service account access?

You need at least the 'Gmail API Reader' or equivalent role. Additional roles like 'Service Account Token Creator' may be required depending on your use case.

Can I fix a 535 error by changing my service account key?

Only if the key was corrupted. The error is more likely due to missing roles or scopes, not the key itself.

Do I need to enable domain-wide delegation for Gmail API?

Only if you're impersonating user accounts. It's not required for general mailbox access with a service account.

How often should I rotate service account keys?

Every 90 days to reduce exposure risk. Update keys in your application and environment variables after rotation.

Why am I still getting 535 errors after adding roles?

Check that the roles have propagated (up to 5 minutes), verify your OAuth2 scopes, and confirm the Gmail API is enabled in your project.

Can Emaillistchecker.io help with SMTP errors?

Yes. By verifying email addresses before sending, it reduces bounce rates and prevents delivery-related issues, including those caused by poor list hygiene.

How accurate is Emaillistchecker.io's email verification?

It achieves 98.9% accuracy for detecting valid, invalid, catch-all, and risky email addresses.

Does Emaillistchecker.io integrate with Gmail API?

No direct integration, but it helps prepare clean lists for use with Gmail API and other sending platforms.

What happens if a service account has the wrong role?

Authentication will fail with a 535 error. Access to Gmail APIs will be denied, regardless of correct keys or scopes.

How do I test if my service account works with Gmail API?

Use a minimal script with correct scopes and the service account key. If the API returns a 200 status, authorization is working.

Can role assignment be automated?

Yes. Use Google Cloud CLI or infrastructure-as-code tools (like Terraform) to apply roles consistently across environments.