Amazon SES for WordPress: The Region Trap That Breaks Most Setups

Amazon SES is among the cheapest and most reliable ways to send WordPress email. It also has the highest setup failure rate of any major provider, and a large share of those failures come down to one fact people are never told clearly.

Everything in SES is per-region

SES is not one service. It is a separate service in every AWS region, and the regions do not share state.

Region-scoped, independently, in each region:

• Whether your account is in the sandbox
• Which email addresses and domains are verified
• Whether production access has been granted
• Your sending quota and rate limit
• Your SMTP credentials

So this sequence is entirely possible, and extremely common: you verify your domain in us-east-1, request production access, get approved, then configure WordPress with an endpoint in eu-west-1 because it is nearer. In eu-west-1 your account is still in the sandbox and your domain is not verified. Every send fails, and everything in the console looks correct — because you are looking at the other region.

The error is usually:

Email address is not verified. The following identities failed the check in region EU-WEST-1

Read the region in that message. It is telling you exactly what is wrong, and it is the part people skim past.

The fix: pick one region and use it for everything — verification, production access and your plugin’s endpoint. If you have already been approved in one region, use that one rather than starting again elsewhere. There is no way to copy verification or production access between regions.

The sandbox

New SES accounts start in a sandbox with real restrictions:

• You can only send to verified addresses. Verifying your sending domain is not enough — every recipient must be verified too.
• 200 messages per 24 hours.
• One message per second.

The first restriction is what confuses people. Your test to your own verified address works perfectly. A real customer never receives anything. The setup looks proven and it is not.

You leave the sandbox by requesting production access in the SES console, per region. Approval is usually quick but is a manual review, so do not schedule a launch around it.

Requests get rejected for vagueness. Say what mail you send, that it is transactional, that recipients are your own customers, and how you handle bounces and complaints. “Sending emails from my website” is the kind of answer that gets a follow-up question and another day of delay.

Which credentials to use

A real trap: your AWS access key is not your SES SMTP password.

SES SMTP credentials are generated specifically, in the SES console, and the SMTP password is derived from a secret key — it is not the secret key itself. Pasting your AWS secret access key into an SMTP password field will always fail authentication.

If your plugin asks for an access key ID and a secret access key, it is using the SES API rather than SMTP, and those are ordinary IAM credentials. NimblyMail’s SES mailer works this way, so you provide IAM credentials and a region rather than generating SMTP credentials.

Whichever you use, create a dedicated IAM user with only SES sending permission. Do not use root credentials.

Bounces and complaints will get you suspended

SES enforces this harder than most providers, and account review is automated.

Keep bounce rate under 5% and complaint rate under 0.1%. Exceed them and you get a review, then a sending pause. The usual cause on WordPress sites is sending to an imported or scraped list, or repeatedly retrying a hard-bounced address.

Configure bounce and complaint notifications when you set up SES, not after a warning. Without them you have no idea your rates are climbing until AWS tells you.

Setup, in a working order

1. Choose your region and write it down. Everything below happens there.
2. Verify your domain, not just an address. Publish the DKIM records SES gives you — three CNAMEs — at whatever DNS host your nameservers point to.
3. Add SES to your SPF record, merging into any existing record rather than adding a second one.
4. Request production access in that region, describing your mail specifically.
5. Create an IAM user with SES sending permission only.
6. Configure WordPress with those credentials and the same region.
7. Send a test to an address you have never verified — this is the step that proves you actually left the sandbox.
8. Check the authentication results on that delivery: spf=pass dkim=pass dmarc=pass.
9. Set up bounce and complaint notifications.

Step 7 is the one to insist on. Testing only to a verified address is how sandboxed setups get declared finished.

Choosing a region sensibly

Since everything is region-scoped and nothing transfers between regions, this choice is worth two minutes rather than none.

Pick the region closest to your web server, not your customers. The latency that matters is between your site and the SES endpoint, since that is the connection made on every send. Where the recipient reads the mail is irrelevant.

Check the region supports what you need. Not every SES feature is available everywhere, and newer regions lag.

Consider data residency. If you have an obligation to keep processing within a jurisdiction, the sending region is part of that.

Then write it down, because the region is not obvious from your plugin settings six months later and it is the first thing you will need when something fails.

SMTP or the API?

SES offers both, and they behave differently in ways worth knowing before choosing.

For WordPress the API is usually the better choice, principally because it is immune to the blocked-port problem that affects a large share of shared hosting. NimblyMail’s SES mailer uses the API, so you supply IAM credentials and a region rather than generating SMTP credentials.

The IAM policy you actually need

Create a dedicated IAM user rather than using root credentials, and give it only the permission to send. A minimal policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ses:SendEmail", "ses:SendRawEmail"],
    "Resource": "*"
  }]
}

If the user can send but not read your account, a compromised site cannot enumerate your AWS environment. Store the secret key encrypted, or keep it out of the database entirely with a constant in wp-config.php — which also stops a production database restored onto staging from carrying live AWS credentials.

Diagnosing later failures

Once running, SES failures are usually one of:

• “Email address is not verified” — wrong region, or still sandboxed. Read the region in the error.
• “Maximum sending rate exceeded” — you are over your per-second limit. A send queue that paces delivery solves this; sending everything at once does not.
• Daily quota reached — still sandboxed at 200/day, or you have grown into your quota and should request an increase.
• Credentials rejected — SMTP password confused with an AWS secret key.

Because SES is region-scoped and quota-limited, it benefits more than most providers from a scheduled check that verifies the connection and the DNS records together, rather than assuming a working setup stays working.