AWS Account How to fix AWS SES invalid security token error during SMTP setup

AWS Account / 2026-09-02 16:27:44

You’re here because your SMTP client can’t authenticate against Amazon SES and you’re seeing something like InvalidClientTokenId, The security token included in the request is invalid, or Invalid security token. In practice, this usually isn’t an “email/SMPP problem”—it’s an AWS credentials + request-signing problem, sometimes triggered by account state, rotation, or restrictions on newly created accounts.

This guide is written for the exact scenario you’re in: you’re past account sign-in, you’re trying to configure SMTP, and SES refuses the credentials. I’ll focus on what to check (in the order I typically debug it), what’s caused by credential lifecycle and IAM settings, and what role AWS account verification / risk controls can play.

AWS Account First: confirm which SES SMTP auth method you’re using (this determines the fix)

Before touching IAM or keys, check your SMTP setup screen and your SMTP library docs. There are two common paths people mix up:

SMTP using IAM user credentials (Access Key + Secret) to generate an SES SMTP password through the AWS console “SMTP credentials” workflow.
- In this model, your SMTP user/pass are not your AWS Access Key/Secret.
- The SMTP “password” is an SES SMTP credential (derived/managed via AWS).
SMTP using “direct IAM auth” (some third-party guides incorrectly tell you to use AWS Access Key/Secret as SMTP username/password).
- This almost always results in “invalid security token” style errors, because SES SMTP expects specific credentials/format.

Action: In AWS SES, create/check SMTP credentials for the IAM user you intend to use. Your SMTP username will typically look like an SES-specific SMTP username, and your password is the SMTP credential password—not your AWS Secret Access Key.

If you’re using access keys directly as SMTP password, stop. Reconfigure to SES SMTP credentials. This single mistake accounts for a large portion of “invalid security token” reports we see in the field.

AWS Account Most common root causes (ranked by frequency I see in real setups)

Symptom you see	Likely cause	What to do immediately
“The security token included in the request is invalid”	Stale/rotated keys or wrong key-secret pair	Verify the exact Access Key ID + Secret pair, and ensure you didn’t copy only part of the credentials.
“InvalidClientTokenId”	Using a non-existent/deleted access key, or wrong region/account	Check IAM access keys for that user; confirm the key is enabled and belongs to the SES account.
“Invalid security token” during SMTP AUTH	Using AWS keys as SMTP password instead of SES SMTP credentials	Generate “SMTP credentials” in SES console for that IAM user and use those for SMTP AUTH.
Works on one app, fails on another	Different credential source (env vars, shared config, rotating secrets manager)	Confirm which credential set your application actually uses at runtime.
Fails only after switching from local to production	Clock drift + STS tokens (if you use temp credentials)	Sync server time; don’t cache STS tokens too long; use correct token lifetime.

Step-by-step troubleshooting (do these in order)

1) Verify you are using the correct SMTP username/password from SES (not AWS access keys)

In AWS SES:

Go to Amazon SES → SMTP settings (or “SMTP credentials” / “Create SMTP credentials” depending on console layout).
Select the IAM user you will authenticate as.
Create or view your SMTP credentials.
Copy the SMTP username and SMTP password into your SMTP client.

Common failure: people paste Access Key ID into SMTP username and Secret into SMTP password. That produces token errors even though “the values look like credentials.”

Extra check: Some libraries cache credentials in config files. If you updated keys, restart the service to ensure the new values are used.

2) Confirm the IAM user’s access key is enabled (only if your setup uses IAM keys elsewhere)

If your setup uses AWS SDK (for SES API sending) or you’re mixing SMTP credentials with IAM keys for any part of the workflow, confirm:

IAM user exists in the same AWS account.
Access key is Active.
You didn’t accidentally disable/delete the key after rotation.

In IAM → Security credentials → access keys, check status and last-used time if available.

Operational tip: If you recently rotated credentials, ensure the application’s credential source matches the new set. “Key mismatch” is the fastest way to trigger InvalidClientTokenId and token validation failures.

3) If you use temporary credentials (STS, SSO, role assumption), check token validity and server time

Token errors often show up when you’re using:

STS AssumeRole credentials
SSO-derived temporary tokens
Kubernetes/EC2 metadata-based role credentials with caching

If your server clock is off by even a few minutes, AWS signature validation can fail with “security token invalid” behaviors.

Action checklist:

Sync system time using NTP (or provider time sync).
Reduce token caching: refresh STS credentials on a schedule slightly shorter than the token expiration.
If your library supports it, disable long-lived credential caching during auth tests.

Real-world case: Teams often test SMTP auth locally (time is correct), then deploy to a VM where time drift exists. The failure appears only in production with token errors—yet the “keys” are identical.

4) Confirm you’re authenticating in the correct region/account (especially with multiple AWS accounts)

SES SMTP auth is tied to the SES configuration for an account and region. If you:

Purchased or created multiple AWS accounts
Use different SES regions (e.g., us-east-1 vs eu-west-1)
Point your tooling to one region but you created SMTP credentials in another

…you can end up with authentication that fails even though credentials “look valid.”

Action:

Ensure the IAM user and SMTP credentials were created in the same AWS account you’re using in the SMTP client.
AWS Account In your sending system, ensure SES endpoints/region mapping matches your SES identity configuration (even if SMTP endpoint is the same style, internal account routing matters).

If you’re using a third-party “email API wrapper,” verify how it selects AWS account/region. Some wrappers let you override region, and defaults can silently change.

5) Check for account state restrictions and risk controls (yes, it can affect SMTP auth too)

AWS account verification and risk control can block or throttle operations, and in some cases can lead to confusing authentication failures during setup.

While SES SMTP typically fails with clear reasons when permissions are missing, I’ve seen scenarios where:

The account is newly created and not fully verified for billing or identity.
There are risk events (payment method issues, unusual sign-in patterns, repeated failed auth attempts).
Compliance checks are pending and the account is constrained.

What to check in AWS:

Billing: Ensure you have an active payment method and billing is enabled.
AWS Support / Account health dashboard: look for notices about restrictions or required actions.
Contact verification / tax info: if pending, fix it promptly.

Operational pattern: If you try many SMTP logins quickly while the account is under risk control review, you may trigger additional security measures (rate limiting, temporary blocks, or deeper inspection). Pause, verify billing/verification status, then retry.

AWS Account Identity verification (KYC) and funding: how it impacts SES setup outcomes

Users often ask: “I can sign in and create IAM users—why does SES reject my token?” In cloud ops, SES is sometimes the first place you notice account-level restrictions, especially around billing and compliance posture.

Here’s what I typically see tied to SES failures and the practical fixes:

New AWS account without payment verification
- Symptoms: inconsistent permissions, throttling, or errors that look like auth/signature issues during high-volume testing.
- Fix: add a working payment method and ensure billing is fully activated; complete any identity/tax verification prompts.
Failed or reverted card verification
- Symptoms: risk reviews, temporary blocks, or inability to proceed with usage.
- Fix: remove and re-add a valid payment instrument; confirm it’s not expired; avoid multiple rapid payment attempts.
Account mismatch due to “purchased/managed” setups
- If you bought an AWS account or migrated configs from a third-party: make sure SES SMTP credentials belong to your current account and IAM user. Otherwise you’ll chase “token invalid” for hours.

If you’re buying AWS access or services: avoid setups where the account’s verification or payment status is unclear. Even if SES appears configurable, risk controls can later block sending or auth flows.

Payment methods and renewals: what breaks SMTP/auth workflows in practice

Payment isn’t “just billing” when it comes to AWS operational continuity. Practical failure patterns include:

AWS Account Credit card changed / expired: the account may become constrained, and the next SES test fails in unpredictable ways.
Billing profile mismatch: using a different billing account (rare but happens with enterprise frameworks).
Renewal pending: if your organization uses contracts, a renewal delay can trigger service limits.

Actionable steps:

In AWS console, verify billing status is “active.”
Ensure the payment method is not in a suspended state.
If you manage multiple accounts, confirm the SES account is the one with active billing.

Cost note (so you don’t test endlessly): SMTP auth troubleshooting can create a lot of failed attempts. Some organizations later face audit/risk flags due to repeated auth failures. Do bounded tests—change one variable at a time.

Common configuration mistakes that produce “invalid security token” (and how to correct them)

Using the wrong field mapping in your SMTP client

Many SMTP clients have fields: Username, Password, Auth method.
If you accidentally put the SES SMTP username into the password field (or vice versa), AWS interprets it as invalid credentials, and you get token-like errors.

Fix: log the exact username you paste (not password), and compare to the SES SMTP credentials screen.

Trying STARTTLS vs SSL mismatch

AWS Account Some providers fail the handshake; others accept but later fail auth.

Fix: follow AWS SES SMTP guidance for the port and TLS mode. If your setup uses port 587 but expects SSL on 465 (or vice versa), you might misread the error as token invalid.

Character encoding or whitespace issues

Copy/paste can insert trailing spaces or line breaks.

Fix: trim fields in your environment variables. For Kubernetes secrets, ensure values are not quoted with extra characters.

Environment variable overrides

In production, your app may use environment variables or a secret store entry that is still pointing to old credentials.

Fix: print the Access Key ID prefix or a credential identifier (never print secrets) to verify runtime values.

When IAM permissions are the real issue (what permissions usually matter)

If you were using SES via API/SDK, IAM policy issues can cause errors. With SMTP specifically, SES authentication still relies on the credential that maps to an IAM user.

What to check:

The IAM user used to create SMTP credentials is correct.
The SMTP credentials you generated weren’t created for a different user.
If your system also uses SES API to send (mixed approach), ensure the IAM principal has the needed SES actions.

Action: keep the SMTP path isolated during debugging: use a direct SMTP test first (like a minimal SMTP client or a tool with explicit username/password fields), then add your integration once auth works.

Cloud account purchasing: the hidden risk behind “invalid security token”

Some users “buy AWS accounts” or use reseller-managed accounts to reduce setup time. I’ll be direct: it can work short-term, but it’s also one of the most common reasons people get stuck on credential errors.

Here’s what goes wrong:

Keys were rotated after you received the account credentials.
AWS Account IAM user was deleted or you’re using SMTP credentials created by another user.
Account risk flags exist from prior activities, and new auth attempts compound the issue.
Billing state is incomplete, so the account is constrained even if the console loads.

If you must use a purchased/managed account: require the seller to provide proof that (a) billing is active, (b) SMTP credentials were generated for the specific IAM user you will use, and (c) there are no pending identity/compliance blocks.

Better alternative: create your own AWS account and pass verification cleanly. In many troubleshooting sessions, the “fix” is actually “stop using someone else’s credential lifecycle.”

Cost comparisons: should you switch providers while debugging SES token errors?

Before switching providers, estimate your cost of debugging and risk exposure:

SES sending cost is often not the main expense during troubleshooting; the bigger cost is the engineering time and potential risk flags due to repeated auth failures.
If you’re blocked by account verification/risk control, switching to another AWS account (or even another cloud) may not help until you stabilize credential and compliance posture.

If you’re comparing against Google Cloud, Azure, or other email services:

Most token/auth issues are localized to credential management, not the cost model.
Switching only makes sense if you can’t remediate the AWS account restrictions within a reasonable window (e.g., compliance review delays).

Practical recommendation: spend 30–60 minutes validating SES SMTP credential usage + IAM user mapping + runtime environment variables + time sync. If it fails after that and the account shows risk/compliance notices, then consider either waiting for account remediation or moving to a backup email provider/service.

FAQ (the questions people actually ask while setting up SES SMTP)

Q1: “I’m sure my keys are correct, why does AWS say the security token is invalid?”

Most likely you’re using the wrong credential type in your SMTP client. SES SMTP password/username are not the same as AWS Access Key/Secret. Or your app is reading old credentials from environment variables/secret store.

Q2: “Does SES SMTP require KYC to work?”

SES itself can be configured, but in practice AWS account verification/billing state can influence what operations are allowed. If your account has pending identity/tax/billing tasks or is under risk control review, SMTP auth attempts can fail in unexpected ways. Check AWS account health/billing pages.

Q3: “Can invalid security token come from choosing the wrong region?”

Yes—especially if you created SMTP credentials in one account/region context and your tooling points to a different setup. At minimum, confirm the IAM user and SMTP credential were generated for the exact account you’re authenticating with.

Q4: “We use AssumeRole—should we worry about token expiration?”

If your SMTP/auth workflow relies on temporary credentials, yes. Ensure your server time is correct and your code refreshes tokens before expiration. Token validation errors can look like “invalid security token” even when the issue is stale/expired temporary credentials.

Q5: “What are safe ways to test without triggering risk controls?”

Limit retries. Validate credentials once, run a single test email, then inspect logs. If you must iterate, change only one variable per run (username/password/TLS/port) and avoid rapid repeated failures.

Q6: “Could this be a cost issue?”

Not directly. SES costs don’t usually trigger token errors; they trigger billing/usage limitations. Token errors are almost always credentials, signature, or credential source mismatch.

A quick “30-minute fix plan” you can follow today

Re-check SMTP fields: Use SES SMTP credentials (username + SMTP password), not AWS Access Key/Secret.
Validate IAM user mapping: SMTP credentials were created for the same IAM user your system expects.
Verify runtime credential source: confirm your app isn’t using old env vars/secret entries.
If using temp credentials: sync server time; refresh tokens; ensure short-lived caching.
Check AWS account health: billing active, no pending identity/tax/compliance blocks, and no risk warnings.
AWS Account Retry once, not in a loop—then analyze the exact error text from your SMTP logs.

If you want, paste your error details (and I’ll tell you which branch you’re in)

Reply with:

The exact error message text (copy/paste)
Your SMTP port + TLS mode (465/587 and SSL/STARTTLS)
Whether you generated SES SMTP credentials or you used AWS Access Key/Secret as SMTP password
Whether your sending system uses AWS SDK/AssumeRole anywhere else

With those, I can pinpoint whether you’re dealing with credential type mismatch, stale keys, temp-token/time drift, region/account mismatch, or an account-state restriction that needs billing/verification attention.