AWS SES Endpoints: How to Choose the Right Region and URL

For most applications, choose one AWS Region, configure that region in the AWS SDK, and let the SDK resolve the Amazon SES API endpoint. Do not hardcode the URL unless you have a specific networking or compliance requirement. Your verified identities, sandbox status, sending quotas, suppression list, configuration sets, event destinations, and SMTP credentials are regional, so changing the endpoint is an operational migration, not a simple hostname edit.

First, identify which SES endpoint you need

Amazon SES exposes three endpoint families that solve different jobs:

The exact availability and hostnames can change as AWS adds Regions and endpoint variants, so use the current AWS SES endpoints table as the source of truth.

An inbound SMTP endpoint is not an IMAP mailbox and is not the host your application uses to send mail. It is published in DNS as an MX destination. Likewise, the outbound SMTP host is not interchangeable with the HTTPS API endpoint. A surprising number of ENOTFOUND, TLS, and authentication failures come from selecting the right Region but the wrong endpoint family.

Choose the Region before the hostname

Start with the Region that matches your architecture, then confirm SES supports the features you need there. A practical decision order is:

1. Meet any data-location or compliance constraint your organization has documented.
2. Prefer a Region near the application workers that call SES to reduce network latency and avoid unnecessary cross-region dependencies.
3. Confirm the Region supports your required SES feature, especially email receiving.
4. Confirm production access and sending quotas are sufficient in that Region.
5. Keep event processing, operational ownership, and incident response simple.

For an India-hosted workload, ap-south-1 in Mumbai is often the obvious first candidate, provided it supports the exact SES features your design requires. That is an architecture choice, not a deliverability shortcut. Picking a geographically closer API endpoint can reduce request latency, but it does not guarantee inbox placement.

AWS documents that SES resources and account state differ by Region. In particular:

• Sandbox removal and sending limits are regional.
• Email and domain identity verification is regional.
• Easy DKIM must be configured for each sending Region.
• Account-level suppression lists are regional.
• Feedback notification settings and configuration sets must exist where you send.
• SMTP credentials are unique to each Region.

This is why silently falling back from Mumbai to North Virginia is dangerous. The backup Region may still be in the sandbox, lack the sending identity, have a smaller quota, or publish no bounce and complaint events to your normal pipeline.

Configure the AWS SDK, not a hardcoded API URL

With the AWS SDK for JavaScript v3, set the Region on SESv2Client. The SDK selects the matching endpoint and signs the request for that Region.

import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";

const region = process.env.AWS_REGION;
const from = process.env.SES_FROM_EMAIL;

if (!region) throw new Error("AWS_REGION is required");
if (!from) throw new Error("SES_FROM_EMAIL is required");

const ses = new SESv2Client({
  region,
  retryMode: "standard",
  maxAttempts: 3,
});

export async function sendWelcomeEmail(to: string) {
  if (!to || !to.includes("@")) {
    throw new Error("A valid recipient is required");
  }

  const result = await ses.send(new SendEmailCommand({
    FromEmailAddress: from,
    Destination: { ToAddresses: [to] },
    Content: {
      Simple: {
        Subject: { Data: "Welcome", Charset: "UTF-8" },
        Body: {
          Text: {
            Data: "Your account is ready.",
            Charset: "UTF-8",
          },
        },
      },
    },
    ConfigurationSetName: process.env.SES_CONFIGURATION_SET,
  }));

  return result.MessageId;
}

Use the SDK's default credential provider chain with a narrowly scoped IAM role in production. Do not put access keys in source code. Also keep the Region explicit in deployment configuration. An unset Region should fail during startup, not send through an accidental default.

The example's address check is only a typo guard, not proof that an address exists or that a person consented. Take recipients from trusted application data and send only requested transactional messages or other mail your policy and applicable law allow. If an AI agent can initiate sends, give it narrow credentials, require approval for new recipients or unusual volume, and record the decision before making the external call.

The SDK already retries certain transient failures. AWS says a maxAttempts value of 3 means one initial request plus up to two retries in its retry behavior reference. Your application still needs an idempotency strategy because a timeout can leave you uncertain whether SES accepted the request. Store a business-level send key, such as welcome:user_123:v1, and do not enqueue a second logical email merely because the first HTTP response was lost.

When to use an explicit endpoint override

The client accepts endpoint-related configuration, including FIPS and dual-stack options. Use those settings only when a real requirement justifies them and the SES endpoint table lists support in your Region.

const ses = new SESv2Client({
  region: "us-east-1",
  useFipsEndpoint: true,
  useDualstackEndpoint: true,
});

Do not construct a hostname from a guessed pattern. Endpoint suffixes and supported variants are not uniform enough to treat guesswork as configuration. An explicit custom URL is mainly useful for controlled testing, a documented private networking setup, or a specialized AWS partition. For ordinary production code, a Region plus SDK endpoint resolution is easier to audit and less likely to drift.

SMTP uses a different host and different credentials

If a library requires SMTP, use the regional email-smtp hostname and SES SMTP credentials. AWS explicitly states that SMTP credentials are unique to each Region, and the SMTP password is not your AWS secret access key.

A typical application configuration looks like this:

SMTP_HOST=email-smtp.ap-south-1.amazonaws.com
SMTP_PORT=587
SMTP_SECURE=false
SMTP_REQUIRE_TLS=true

Port 587 normally upgrades the connection with STARTTLS. Port 465 uses implicit TLS from the beginning. Require certificate validation and fail if encryption cannot be established. Do not disable TLS verification to make a hostname mismatch disappear.

When moving SMTP traffic to another Region, generate or derive credentials for that Region and update the host as one coordinated deployment. Changing only the hostname commonly produces authentication failures. Changing only the credentials leaves the application connected to the old regional service.

Treat a Region change as a migration

Before directing production traffic to a new Region, complete this checklist:

• Verify the sending domain or email identity in the target Region.
• Publish and validate the target Region's DKIM records.
• Confirm the account has production access in that Region.
• Check the daily quota and maximum send rate for expected traffic.
• Recreate configuration sets and event destinations.
• Confirm bounce, complaint, delivery, reject, and delay events reach the monitored pipeline.
• Review the account-level suppression list strategy across Regions.
• Recreate any sending authorization policy in the target Region.
• For SMTP, provision regional SMTP credentials.
• Run controlled tests before shifting real traffic.

Use the SES mailbox simulator for success and bounce paths instead of sending test messages to real customers. Then test a small set of consented internal recipients. A successful SendEmail response means SES accepted the request. It does not prove delivery, and delivery does not prove inbox placement.

Add a configuration set to sends and publish events to an appropriate destination. AWS lists sends, deliveries, bounces, complaints, rejects, rendering failures, and delivery delays among the available SES event destination types. Alert on missing events as well as negative ones. A broken event route can hide a growing suppression or reputation problem while the send API still returns message IDs.

Do you need an SES Global endpoint?

Most products should begin with one Region. Multi-region email adds replicated identities, aligned quotas, duplicated event handling, suppression decisions, and more incident states. Add it when the business requirement for regional resilience outweighs that cost.

Amazon SES also supports Global endpoints, which distribute outbound traffic between a primary and secondary Region and can shift traffic away from an impaired Region. Applications pass the Global endpoint ID in the SendEmail or SendBulkEmail request. This is not the same as inventing a global hostname or manually rotating regional URLs.

Before relying on a Global endpoint, verify that both Regions have equivalent identities, configuration sets, production access, and enough quota to carry full traffic during an impairment. AWS notes that some identity attributes, feedback settings, and BYODKIM configurations still require manual work in the secondary Region. Your observability also needs to combine events from both Regions without losing the regional dimension.

Common endpoint failures

`ENOTFOUND` or connection timeout: Check for a typo, the wrong endpoint family, blocked egress, or a DNS problem. Compare the host with AWS's current endpoint table.

Signature mismatch: Ensure the request is signed for the same Region as the endpoint. Avoid hand-built signed requests when an AWS SDK can handle endpoint resolution and Signature Version 4.

Identity not verified: Inspect verified identities in the active Region. Verification in another Region does not carry over automatically.

Still in the sandbox: Production access is regional. A working production setup elsewhere says nothing about the current endpoint's sandbox state.

SMTP authentication failure after migration: The SMTP hostname and SMTP credentials must both belong to the target Region.

API accepted the message, but no delivery event arrived: Confirm the configuration set was attached to the send, the event destination is enabled, and the downstream subscription or consumer is healthy. Do not equate API acceptance with recipient-server acceptance.

The practical default

Choose one suitable Region, make it explicit in deployment configuration, let the official SDK resolve the SES API endpoint, and build regional identity, quota, suppression, and event handling into your readiness checks. Use SMTP only when your application or framework needs it. Add multi-region routing only after you can operate every dependency in both Regions.

If you want a simpler API layer while keeping email sends observable and constrained, SendHQ provides a developer-focused path for transactional email workflows without pretending that an accepted request guarantees inbox placement.