When an application sends transactional emails such as account verification messages, password resets, invoices, alerts, or order confirmations, the email service is usually treated as part of the application infrastructure.
That makes AWS Region selection more important than it may first appear.
Amazon Simple Email Service (Amazon SES) is regional. An identity, sending quota, SMTP setup, configuration, and sending endpoint are associated with a specific AWS Region. Moving an application to another Region without planning the SES side can result in failed email delivery, authentication errors, unexpected sandbox restrictions, or applications continuing to send through the old Region.
This article explains how to configure transactional email sending from a new AWS SES Region and what should be checked before moving production traffic.
Why Move Transactional Email to Another SES Region?
There are several practical reasons to use a different SES Region.
For example, an application may already be moving its compute resources from one AWS Region to another. Keeping email traffic in the old Region can create unnecessary dependencies between Regions.
Other reasons include:
- Aligning email infrastructure with application infrastructure
- Reducing cross-Region dependencies
- Supporting a disaster recovery strategy
- Using a Region closer to application workloads
- Separating production and non-production email infrastructure
- Using a newly available SES Region
- Preparing for regional failover
- Meeting internal architecture or data residency requirements
The important point is that creating resources in a new Region does not automatically move SES configuration with them.
How AWS SES Regional Configuration Works
SES configuration is regional.
Suppose an application currently sends email from:
us-east-1
and the application is being moved to:
ap-south-1
The SES setup in us-east-1 should not be assumed to exist in ap-south-1.
A useful way to think about the setup is:
Application
|
+-- AWS SDK / SMTP
|
+-- SES Region A
|
+-- Verified identity
+-- Sending access
+-- Quotas
+-- Configuration
+-- Monitoring
After migration:
Application
|
+-- AWS SDK / SMTP
|
+-- SES Region B
|
+-- Verified identity
+-- Sending access
+-- Quotas
+-- Configuration
+-- Monitoring
The application must explicitly use the new SES Region.
Verify the Email Identity in the New Region
One of the first migration tasks is verifying the sender identity in the target Region.
An SES identity can be a:
For production applications, domain verification is generally easier to manage because multiple addresses under the domain can be used without verifying every address individually.
For example:
example.com
could be used for:
[email protected]
[email protected]
[email protected]
[email protected]
The important detail is that SES identity verification is regional.
If example.com is already verified in one Region, check and configure the identity for the new Region as well.
Domain Verification and DKIM
Domain-based sending should normally use DKIM because it provides authentication for outgoing email and helps receiving mail systems establish that the messages are authorized.
The basic flow is:
Application
|
v
Amazon SES
|
v
DKIM signing
|
v
Recipient Mail Server
When setting up the identity in the new Region, SES provides DNS records that must be configured according to the verification and DKIM setup.
Before switching production traffic, verify that the domain identity shows as verified and that DKIM is correctly configured.
Do not assume that a successful setup in the previous Region means the new Region has been completely configured.
Check Sandbox and Production Access
A common migration problem is discovering that the new SES Region is still operating under sandbox restrictions.
SES accounts can have restrictions on who they can send to while in the sandbox.
This creates a situation where the application works during development but fails when it starts sending real transactional messages to customers.
Before production migration, confirm that the target Region has the required production sending access.
A simple migration checklist should include:
Target Region selected
|
v
SES identity configured
|
v
Domain verified
|
v
DKIM configured
|
v
Production sending access confirmed
|
v
Application configured
|
v
Test emails delivered
Configure the AWS SDK for the New Region
Applications using the AWS SDK should explicitly configure the SES client for the target Region.
For a .NET application using the AWS SDK, the configuration can look like this:
using Amazon;
using Amazon.SimpleEmailV2;
using Amazon.SimpleEmailV2.Model;
var client = new AmazonSimpleEmailServiceV2Client(
RegionEndpoint.APSouth1);
var request = new SendEmailRequest
{
FromEmailAddress = "[email protected]",
Destination = new Destination
{
ToAddresses = new List<string>
{
"[email protected]"
}
},
Content = new EmailContent
{
Simple = new Message
{
Subject = new Content
{
Data = "Your order has been confirmed"
},
Body = new Body
{
Text = new Content
{
Data = "Your order has been confirmed."
}
}
}
}
};
await client.SendEmailAsync(request);
The important migration change is the Region used by the SES client.
In production code, avoid hard-coding this value directly into application logic.
A better approach is configuration.
{
"Aws": {
"Region": "ap-south-1"
}
}
Then the application can load the Region from its environment-specific configuration.
Use Configuration Instead of Code Changes
A regional migration should ideally not require a new application build just to change the SES Region.
For example:
Development
SES_REGION=us-east-1
Staging
SES_REGION=ap-south-1
Production
SES_REGION=ap-south-1
The application reads the Region during startup.
This makes regional migration easier and also supports disaster recovery.
For example:
var regionName = configuration["Aws:Region"];
var region = RegionEndpoint.GetBySystemName(regionName);
var sesClient = new AmazonSimpleEmailServiceV2Client(region);
This pattern keeps deployment configuration separate from application behavior.
SMTP Users Need Regional Attention
Applications can also send email through the SES SMTP interface.
If an application uses SMTP, check the following during migration:
- SMTP endpoint
- SMTP credentials
- Port
- TLS settings
- Username
- Password
- Region
- Sending limits
Do not simply copy the old SMTP endpoint into the new deployment.
The SMTP configuration is tied to the SES Region being used.
A typical application configuration might look like:
SMTP_HOST=<regional SES SMTP endpoint>
SMTP_PORT=587
SMTP_USERNAME=<regional SMTP credential>
SMTP_PASSWORD=<secret>
SMTP_USE_TLS=true
Store credentials in AWS Secrets Manager or another approved secret-management system instead of committing them to source control.
Custom MAIL FROM Domains
Some applications configure a custom MAIL FROM domain to control the envelope sender used by SES.
For example:
From:
[email protected]
MAIL FROM:
bounce.example.com
If the application uses a custom MAIL FROM configuration, include it in the regional migration checklist.
Review the required DNS configuration and confirm that the new SES identity and MAIL FROM setup work correctly.
This is especially important for applications that depend on bounce and complaint handling.
Update IAM Permissions
Moving the application to another Region may require IAM review.
A policy that restricts SES actions to a specific Region can prevent the application from sending through the new Region.
For example, an IAM policy may contain a condition such as:
{
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
If the application is moved to another Region, that restriction may need to be updated.
Do not simply remove the Region restriction to make the migration work.
Instead, decide whether the application should be allowed to use:
- Only the new Region
- Both old and new Regions during migration
- Multiple approved Regions for disaster recovery
Least-privilege access should remain the goal.
Update Application Monitoring
Email migration is not complete when the application successfully sends one test email.
Production monitoring should cover:
- Send attempts
- Successful sends
- Rejected messages
- Bounces
- Complaints
- Delivery failures
- API errors
- Throttling
- Sending quota usage
- Application email queue size
CloudWatch metrics and SES event publishing can be used to build visibility around the new Region.
For example:
Application
|
v
SES
|
+---- Delivery event
+---- Bounce event
+---- Complaint event
+---- Rejection
|
v
Monitoring / Alerting
This helps detect problems that a simple SMTP success response cannot reveal.
Test Before Switching Production Traffic
A regional migration should use controlled testing.
Start with a test sender and a small set of recipient addresses.
Test the following:
Identity Verification
Confirm that the sender domain or email identity is verified.
Authentication
Check that DKIM is passing and the email is authenticated as expected.
Delivery
Send messages to multiple recipient providers where possible.
HTML and Text Content
Verify that both HTML and plain-text versions are delivered correctly.
Links
Check links in password reset, verification, and notification emails.
Attachments
If the application sends attachments, verify their size and content.
Bounce Handling
Use controlled test scenarios to verify that bounce events reach the application's event-processing pipeline.
Complaint Handling
Verify that complaint events are captured and processed correctly.
Plan a Controlled Production Cutover
Avoid changing every application instance simultaneously unless the deployment architecture requires it.
A safer approach is:
Old SES Region
|
| Existing traffic
|
v
Application
|
+---- Small percentage ---> New SES Region
|
+---- Remaining traffic --> Old SES Region
Monitor the new Region before increasing traffic.
Once the new Region is stable:
Application
|
+----> New SES Region
Keep the old configuration available temporarily if rollback is required.
Regional Failover Strategy
For business-critical applications, email can be included in disaster recovery planning.
A basic strategy could look like:
Primary Region
Application
|
v
SES Region A
|
v
Customers
During a regional failure:
DR Region
Application
|
v
SES Region B
|
v
Customers
However, failover should not be treated as simply changing one configuration value.
The backup Region must already have:
- Verified sending identity
- Production sending access
- Appropriate IAM permissions
- Required DNS configuration
- SMTP configuration if applicable
- Monitoring
- Event handling
- Application configuration
- Tested sending capability
A failover plan that has never been tested is only a configuration assumption.
Common Migration Mistakes
Assuming SES Identity Is Global
SES identities are regional. Verify and configure the identity for the target Region.
Forgetting Sandbox Restrictions
A new Region may have different account sending status from the Region currently used by production.
Leaving the Old SMTP Endpoint
SMTP configuration must point to the SES Region being used by the application.
Hard-Coding the Region
Hard-coded Region values make future migration and failover harder.
Ignoring IAM Region Conditions
Region-specific IAM restrictions can block the new SES configuration.
Testing Only Successful API Calls
An API call succeeding does not guarantee good email delivery.
Monitor delivery, bounce, complaint, and rejection events.
Switching All Traffic Immediately
A gradual migration makes it easier to identify configuration and reputation problems before they affect the entire customer base.
Advantages of Using a New SES Region
Using a new SES Region can provide several operational benefits:
- Better alignment with application infrastructure
- Reduced cross-Region dependencies
- Simpler regional architecture
- Better disaster recovery planning
- Regional isolation
- Easier environment separation
- More control over production email infrastructure
Disadvantages and Considerations
There are also trade-offs:
- SES configuration must be recreated or verified regionally
- Sending quotas are regional
- Monitoring must cover the new Region
- SMTP configuration may need changes
- IAM policies may need updates
- DNS and authentication settings require validation
- Regional failover adds operational complexity
The migration should therefore be treated as an infrastructure change rather than a simple endpoint change.
Production Checklist
Before sending production traffic through the new SES Region, verify:
[ ] Target SES Region selected
[ ] Domain or email identity configured
[ ] Identity verified
[ ] DKIM configured and validated
[ ] Custom MAIL FROM checked
[ ] Production sending access confirmed
[ ] Sending quota reviewed
[ ] AWS SDK Region updated
[ ] SMTP endpoint updated if required
[ ] SMTP credentials configured if required
[ ] IAM permissions reviewed
[ ] Secrets updated
[ ] Application configuration tested
[ ] Delivery tested
[ ] Bounce handling tested
[ ] Complaint handling tested
[ ] Monitoring configured
[ ] Alerts configured
[ ] Failover plan documented
[ ] Rollback plan tested
Final Thoughts
Moving transactional email to a new AWS SES Region is more involved than changing the AWS Region used by an application.
The SES identity, sending access, quotas, SMTP configuration, IAM permissions, monitoring, and application endpoint all need to be checked for the target Region.
The safest approach is to prepare the new SES environment before moving production traffic. Verify the domain, confirm production sending access, update the application configuration, test delivery and event handling, and then perform a controlled cutover.
For applications that require high availability, the same preparation can become the foundation for a regional email failover strategy.
The main lesson is simple: treat SES as a regional dependency in your application architecture. When the application moves to another AWS Region, the email infrastructure should be migrated and tested as part of the same change rather than handled afterward.
Join the conversation! Your thoughts help the community grow.