Amazon SES SMTP test: regional endpoints and credentials

Amazon SES exposes regional SMTP endpoints for sending email. Each region that supports SES has its own hostname in the format email-smtp.<region>.amazonaws.com, for example email-smtp.us-east-1.amazonaws.com. You must use the endpoint that matches the region where you created your SMTP credentials, and SES SMTP credentials are a derived username/password pair generated specifically for SMTP authentication, not your AWS access keys.

SES has no global endpoint: its credentials are tied to one region, and new accounts sit in a sandbox that limits recipients and volume. Getting any of these wrong produces a confusing SMTP error, so this guide covers credentials, endpoints, sandbox rules, and the errors you are most likely to see in a transcript.

Recommended settings

• Host: email-smtp.<your-region>.amazonaws.com
• Port: 587 (STARTTLS) or 465 (implicit TLS)
• Username: your SES SMTP username (a 20-character alphanumeric string)
• Password: your SES SMTP password (a long Base64 string)
• Auth method: Auto or PLAIN
• From: an email address or domain verified in SES in the same region

Ports 2587 (STARTTLS) and 2465 (implicit TLS) also work if a firewall blocks the standard ports. SES does not accept unauthenticated relaying, so auth is always required.

SES SMTP credentials are not your IAM keys

This is the single most common mistake when connecting to SES. People copy an IAM access key ID and secret access key from the IAM console, paste them into their mail client, and get a 535 Authentication Credentials Invalid response.

SES SMTP credentials are generated in the SES console, not in IAM. When you click "Create SMTP credentials", AWS does two things:

1. It creates an IAM user with a policy that allows ses:SendRawEmail.
2. It derives an SMTP password from that user's secret access key using a signature-based transformation (the same HMAC-SHA256 scheme AWS documents for converting an IAM secret into an SMTP password).

You never see or use the IAM secret access key itself for SMTP. The SMTP username is the IAM access key ID (20 characters, starts with AKIA), but the SMTP password is a longer Base64 string shown only at creation time. If you lose it, you cannot recover it; you create new SMTP credentials instead.

Two rules follow:

• You can derive an SMTP password yourself from an existing IAM user's secret access key using the algorithm AWS documents, but generating fresh credentials in the SES console is simpler and produces a dedicated, minimally privileged user.
• Credentials are region-specific. A pair created in us-east-1 authenticates only against email-smtp.us-east-1.amazonaws.com. The same pair fails with 535 against any other regional endpoint, even though the underlying IAM user is global. When you rotate credentials, generate them in the region your application sends from.

Creating SMTP credentials

1. Open the Amazon SES console in your target region.
2. Go to Account dashboard → SMTP settings.
3. Click "Create SMTP credentials." This creates an IAM user with a policy scoped to ses:SendRawEmail.
4. The console shows a username and password. Download or copy them immediately; the password is displayed only once.
5. The username looks like AKIAIOSFODNN7EXAMPLE (20 characters). The password is a longer derived string (not the IAM secret key itself, since SES transforms it).

If you need to rotate credentials, delete the IAM user in the IAM console and repeat the process. You can also derive SMTP credentials from an existing IAM user's secret access key using the algorithm AWS documents, but the console method is simpler.

Testing with SMTP Tester

1. Set host to your region's SMTP endpoint (e.g. email-smtp.us-east-1.amazonaws.com).
2. Port 587, security STARTTLS (or port 465 with TLS).
3. Enter the SES SMTP username and password.
4. From address: a verified identity in the same region (email or domain).
5. To address: in sandbox mode, this must also be a verified address. When you click Run, a 235 Authentication successful confirms the credentials work, and a 250 Ok after DATA confirms SES accepted the message. Each transcript stage tells you something specific about SES:

If you are new to reading these exchanges, the guide on what an SMTP test is breaks down the handshake stage by stage.

Common errors

535 "Authentication Credentials Invalid"

• Region mismatch: credentials created in us-east-1 will not authenticate against eu-west-1. Match the endpoint to the region where you generated them.
• Using AWS access keys instead of SMTP credentials: your IAM access key ID and secret key will not work directly as SMTP credentials. The username happens to be the access key ID, but the password must be the derived SMTP password from the SES console.
• Stale credentials: if you recently regenerated credentials, ensure your config uses the new pair, and check the region first; a 535 immediately after AUTH means credentials or region, not your message.

554 "Message rejected: Email address is not verified"

This error appears after authentication succeeds: the SMTP session was fine, but SES rejected the message content. The exact text is usually 554 Message rejected: Email address is not verified. The following identities failed the check in region <region>: <address>. In sandbox mode, the From address must be a verified identity (email or domain) in the SES region you are using, and the To address must also be verified, because sandbox restricts recipients too. The error names which identity failed verification and in which region, which is often how people discover they verified their domain in one region but are sending through another.

Fix: verify the From domain (or email) and, in sandbox mode, the recipient address too, in the same region. Domain verification covers all addresses at that domain, so it is the more durable option for a production sender.

454 "Throttling failure"

SES rate-limits sending based on your account's sending quota and maximum send rate. New accounts in sandbox start at 1 message per second and 200 messages per day. If you exceed this, SES returns a 454 temporary error, and because 454 is a transient (4xx) code, well-behaved clients retry with backoff while a test tool surfaces it directly.

Check your current limits in SES → Account dashboard → Sending statistics. Request production access to raise them.

Connection timeout

SES SMTP only accepts connections on ports 587, 465, 2587, and 2465, and port 25 is not supported for submission. If 587 times out, your network may block it; try port 2587 (STARTTLS) or 2465 (TLS), which some corporate firewalls allow.

Sandbox mode: how to get out

Every new SES account starts in sandbox mode with restrictions:

• Send only to verified email addresses (both From and To must be verified).
• Maximum 200 messages per 24 hours.
• Maximum send rate of 1 message per second.

To send to arbitrary recipients (real users), request production access through the SES console. AWS typically approves requests within 24 hours. Once approved, you only need to verify the From identity; recipients can be anyone.

When you apply, describe your use case concretely: what you send, how recipients signed up, how you handle bounces and complaints, and your expected volume. Vague applications slow the review down. Sandbox exit applies to the account, not individual credentials, so nothing changes in your configuration after approval.

SES regions and endpoints

Common SMTP endpoints:

This is a sample, not the full list; SES supports additional regions, including AWS GovCloud (email-smtp.us-gov-west-1.amazonaws.com). Always use the endpoint in the region where your identities are verified and your SMTP credentials were created. Cross-region calls will fail authentication, and if you later move regions, you must re-verify domains and regenerate SMTP credentials there.

Domain verification, DKIM, SPF, and the Mail FROM domain

Verifying a domain in SES involves three related pieces:

• DKIM: SES generates three CNAME records for Easy DKIM. Once they resolve, SES signs all outgoing mail from that domain and the identity shows as verified. Easy DKIM is the default and the right choice for almost everyone.
• SPF: for custom Mail FROM domains, SES publishes SPF records you reference. If you use the default amazonses.com envelope domain, SPF on your own domain is not required, but adding SES's include to your SPF record is still good practice.
• Mail FROM domain: by default SES uses a subdomain of amazonses.com as the envelope sender domain (what receivers see in Return-Path). Set a custom Mail FROM subdomain (like mail.yourdomain.com) so the visible From domain and envelope domain align exactly, which improves DMARC alignment for SPF.

Do this before requesting production access: AWS reviewers check that your sending domain is verified with DKIM, and aligned authentication reduces the chance your mail lands in spam once you start sending.

Sending from Node.js with nodemailer

import nodemailer from "nodemailer";

const transporter = nodemailer.createTransport({
  host: "email-smtp.us-east-1.amazonaws.com",
  port: 587,
  secure: false, // STARTTLS on 587
  auth: {
    user: process.env.SES_SMTP_USER,     // SES SMTP username, not an IAM access key
    pass: process.env.SES_SMTP_PASSWORD, // derived SMTP password from the SES console
  },
});

await transporter.sendMail({
  from: "notifications@yourdomain.com", // verified in SES, same region
  to: "recipient@example.com",
  subject: "Hello from SES",
  text: "Sent through the SES SMTP interface.",
});

Notes for this setup:

• Port 465 works too, with secure: true (implicit TLS). See SMTP port 587 vs 465 for the tradeoffs.
• Nodemailer's transporter.verify() runs a handshake-plus-auth check without sending, mirroring handshake-only mode in SMTP Tester.
• Never hardcode the SMTP password. If a test works in SMTP Tester but your app fails with 535, check which value ended up in pass; a stray IAM secret key is the usual culprit.

SES SMTP vs SES API

SES offers two ways to send: SMTP and the REST API (SendEmail/SendRawEmail). SMTP works from any language or tool that speaks SMTP, with no AWS SDK needed. The REST API offers more control (configuration sets, tags, event publishing) but requires the SDK or signed HTTP requests. For testing connectivity and authentication, SMTP Tester uses the SMTP interface directly: if SMTP works in SMTP Tester, it will work from your application with the same credentials and endpoint. If you later move to the API, note that it uses standard IAM credentials, not SMTP credentials.

Security notes

• SES SMTP credentials are sensitive. Store them in environment variables or AWS Secrets Manager, not in source code.
• SMTP Tester redacts credentials from the protocol transcript automatically.
• Use the minimum IAM permissions (ses:SendRawEmail) for the SMTP user. The SES console does this by default.
• Enable SES event publishing and feedback notifications (bounces, complaints) in production to protect your sender reputation.
• Rotate SMTP credentials on a schedule and after any staff change; since the password is shown only at creation, rotation means generating a new pair and deleting the old IAM user.

Frequently asked questions

Are SES SMTP credentials the same as my IAM access keys?

No. The SMTP username is derived from an IAM access key ID, but the SMTP password is a separate derived value generated in the SES console. Plain IAM keys and secret keys fail SMTP authentication with a 535 error, so generate dedicated SMTP credentials in the SES console under SMTP settings.

Can I use credentials from one region with another region's endpoint?

No. SES SMTP credentials are region-locked. A pair created in us-east-1 only authenticates against email-smtp.us-east-1.amazonaws.com. If your transcript shows a 535 error with credentials you are sure are correct, check the region first.

How long does it take to leave the SES sandbox?

AWS reviews production access requests and typically approves them within 24 hours, though applications that lack detail can take longer. Include your use case, recipient acquisition method, and bounce handling in the request. You will receive an email once your account exits the sandbox; no credential or endpoint changes are needed afterward.

Why does my test work in SMTP Tester but fail in my application?

Compare the endpoint, port, security mode, and credentials character by character. The most common mismatches are a different regional endpoint, an IAM secret key pasted instead of the SMTP password, and STARTTLS configured where the app uses no TLS. Since SMTP Tester uses the same SMTP interface your application does, a passing test means the difference is in your app's configuration.

How is SES different from providers like SendGrid or Mailgun?

SES is an AWS-native service with regional endpoints, IAM-based credential management, and sandbox onboarding. Providers like SendGrid and Mailgun offer a single global SMTP endpoint, API-key credentials, and no recipient verification requirement. SES is usually the cheaper option at scale if you are already on AWS, but it asks more setup up front.

Does SMTP Tester send a real email during an SES test?

Only if you provide To and From fields. In handshake-only mode it stops after authentication, so you can validate credentials and TLS without consuming sending quota. In full mode it sends one test message, which counts toward your sandbox limit.

Related: SMTP port 587 vs 465: STARTTLS or implicit TLS? explains which port and encryption mode to pick, and fixing SMTP authentication error 535 walks through the 535 error above step by step.