SES "Email Address Is Not Verified": Sandbox and Region Fix

Amazon SES's "Email address is not verified. The following identities failed the check in region …" means one of two things, and the error names which: either the From address is not verified in the Region that is actually sending, or your account is still in the SES sandbox in that Region and the recipient is not verified either. Check SES → Configuration → Verified identities in the Region named in the error, verify the sender or its whole domain, and look at Account dashboard for sandbox status. The surprise that catches almost every first-time sender: verifying your own address is not enough. In the sandbox, SES also refuses to deliver to any inbox you have not verified, so a perfectly configured WordPress contact form fails because the visitor's Gmail address has never clicked an AWS link. And verification is per Region: a domain verified in Oregon is a stranger in Virginia.

Jake runs a phone repair shop. His website sends repair-booking confirmations, and last week Ethan, his friend who does the technical side, switched the WordPress mail plugin from the hosting company's relay to Amazon SES to stop the emails landing in spam. Jake clicked the verification link for hello@example.com himself. The next booking confirmation bounced back with a red paragraph about identities failing a check.

Jake: "I verified the address. I clicked the link. It says verified. Why is it still blocked?"

Ethan: "Two questions before anything else. Which Region is sending this message, and is the account still in the sandbox there?"

Jake: "Region? It's email. It goes to the customer."

Ethan: "SES is not one post office. It is a post office in every AWS Region, and each one keeps its own list of who you have proven you are. You proved it to the one in Oregon. Your plugin is handing letters to the one in Virginia, and Virginia has never heard of you."

If "SES", "identity" and "Region" are new words, our plain-English page on what Amazon SES is explains the service in five minutes. The post office analogy below carried Jake through without it.

Read the whole error before touching anything

The full message is more helpful than the first line suggests. It lists the identity or identities that failed and ends with the Region. Those two facts decide the fix, so copy the whole thing. The rejection happens inside SES, before the mail goes anywhere near the customer's provider, so the customer's spam folder is irrelevant until the named identities are sorted.

Three addresses travel with every email and they are not interchangeable. The From address is the visible author the reader sees. The recipient is the inbox the mail is going to. The MAIL FROM is a separate envelope address used for bounces and authentication. SES verification is about the first one, and in the sandbox about the second one too.

What the error names	What it means	First repair
Your own sender, hello@example.com	That From address, or its parent domain, is not verified in the sending Region	Verify the sender in that Region
A customer's address	You are in the sandbox and recipients must be verified too	Verify test inboxes now; request production access for real customers
A From address you never chose, like visitor@gmail.com	A plugin or form is setting From to the visitor's address	Fix the plugin: From = your domain, Reply-To = the visitor
A Region you do not use	The SMTP endpoint or SDK is pointed at a different Region than the console you verified in	Verify there too, or point the app at the right Region
A Return-Path or MAIL FROM domain	Custom envelope setup, a different mechanism	Check the identity's MAIL FROM configuration

Jake: "Is it the SMTP password? I typed it twice."

Ethan: "No. Authentication decides whether you can connect; your plugin connected fine, or you would have a different error. Identity verification decides which addresses you can send as. Sandbox rules decide which destinations are allowed. Three gates, and you are through the first one."

The decision path: one check instead of ten verification emails

People who hit this error tend to create the same identity five times. One careful pass beats that:

1. Record the complete rejection: every identity it names, and the Region.
2. Identify which AWS account and which credentials (SMTP user or IAM principal) the sending application uses.
3. Read the sending Region from the SDK configuration or the SMTP hostname, for example email-smtp.us-east-1.amazonaws.com.
4. Open SES Verified identities in that Region.
5. Compare the actual From address the application sends with the verified email or parent domain.
6. Check Account dashboard or get-account for production access in that Region.
7. If the account is sandboxed there, check the destination addresses too, including Cc and Bcc.
8. Send one controlled message and record the result before changing anything else.

aws sts get-caller-identity
aws sesv2 get-account --region us-east-1 --query '{Production:ProductionAccessEnabled,Quota:SendQuota}'
aws sesv2 list-email-identities --region us-east-1
aws sesv2 get-email-identity --email-identity example.com --region us-east-1

Replace us-east-1 with the Region your software actually uses. Those commands report the state of that Region; look up the wrong one and a perfectly verified identity appears to be missing.

The sandbox: why your own verified address still cannot reach a customer

When you first use SES in a Region, the account is in the sandbox there. A sandboxed account can send from verified identities only to verified recipients, plus SES's mailbox-simulator addresses for testing. It is designed to stop a brand-new account from spamming the world, and it is deliberately useless for emailing arbitrary new customers. No WordPress checkbox turns it off; it is a property of the account in that Region.

The sandbox also has small quotas: 200 recipient messages per 24 hours and one message per second. "Recipient messages" counts recipients, not sends: one confirmation to a customer with two staff copied is three recipient messages, and all three addresses need to be verified while you are sandboxed.

Ethan: "Verifying the sender answers who may speak. The sandbox asks who may listen. Production access changes that second part, and only that part."

"Failed the check in region": the Region is the whole story

SES keeps verification status separately in every Region. Verifying example.com in US West (Oregon) does nothing in US East (N. Virginia). Jake's domain had been verified months earlier in Oregon by the hosting company's setup wizard; the new WordPress plugin was pointed at the Virginia SMTP endpoint. Both facts were true, and the console page Jake kept refreshing, open on Oregon, kept saying "Verified".

aws sesv2 get-email-identity --region us-east-1 --email-identity example.com
aws sesv2 get-email-identity --region us-west-2 --email-identity example.com

A missing identity in one answer and a verified one in the other does not mean SES is confused. It means the two environments were never set up the same way. Verify in the Region that sends, publish that Region's DKIM records if it is a domain identity, and write the Region down next to the sender address in your deployment notes so the next migration does not repeat this.

Jake: "So I have to verify it again in Virginia."

Ethan: "Or point the plugin at Oregon. Either is fine. Having the two disagree is the only wrong answer."

Verifying one address

If you control the mailbox but not the domain's DNS, verifying the single address is fastest. SES emails a link to that mailbox; someone clicks it; done. In the sending Region: Configuration → Verified identities → Create identity → Email address, type the exact address, create, check that inbox, click the link before it expires, come back and confirm the status reads Verified, then set the application's From to exactly that address.

aws sesv2 create-email-identity --email-identity hello@example.com --region us-east-1
aws sesv2 get-email-identity --email-identity hello@example.com --region us-east-1 \
  --query '{Verified:VerifiedForSendingStatus,Status:VerificationStatus}'

Creating the identity starts the process; it is not verified until the link is clicked, and the link expires after 24 hours. If the email never arrives, the problem is in the mailbox, not in SES: check junk and quarantine, check forwarding rules, and send an ordinary message to that address from somewhere else to prove it can receive anything at all.

Jake: "The verification email is taking forever. SES must be slow."

Ethan: "Your hello@ is an old alias that forwards to your personal inbox. If the mailbox cannot receive a normal outside email, it cannot click a verification message either. Send yourself a test from your phone first."

Verifying the whole domain

If the shop sends from orders@, support@ and billing@, verifying the domain once is easier than clicking a link for every mailbox, and it works for addresses that have no mailbox at all. You prove control through DNS: Create identity → Domain, enter the parent domain, and publish the DKIM CNAME records SES gives you for that identity and that Region, with the underscores and the exact names intact.

A verified domain authorizes sending as any address under it. It does not create inboxes; replies still need somewhere to land, which is what Reply-To is for. If the status stays pending, query the authoritative DNS, check the copied names and values, and check whether your DNS host appended the domain to the record name so it reads _abc.example.com.example.com. Our DNS TTL page explains why a correct record can still take a while to be seen.

From, Reply-To, Return-Path and MAIL FROM: four boxes, four jobs

Field	What it means	What SES needs
From	The visible author of the message	A verified address, or an address under a verified domain, in the sending Region
Reply-To	Where a human reply goes	Nothing; it can be the visitor's address
MAIL FROM	The envelope sender domain used for bounces and SPF	SES's default amazonses.com, or a custom domain with its own MX and SPF records
Return-Path	The header that reflects envelope bounce handling	A plugin field with this label does not change your identity

A custom MAIL FROM is optional and separate from verifying the From identity. If you set one up and chose "reject message" when its DNS fails, you can get a different error, MailFromDomainNotVerified, which has its own diagnosis and should not be confused with this one.

The WordPress fix: stop sending as the visitor

The contact-form trap is the single most common cause of this error on a small-business site. The form plugin sets the email's From to whatever the visitor typed, visitor@gmail.com, so that replying feels natural. SES then sees you trying to send as a Gmail address you have never verified and could never verify, because you do not own Gmail. The error names the visitor's address, and people spend an evening trying to "verify" it.

The pattern that works: From is your verified shop address, forms@example.com, and the visitor's address goes in Reply-To. The shop can still hit Reply and reach the visitor; SES sees a sender you are authorized to use. In the plugin, check the SMTP host (it encodes the Region), port, encryption, credentials, the From address, and any "force From email" switch. If the mailer has its own From and WordPress has a site-wide one, find out which wins in the final message by sending the plugin's own test email and comparing its From with the booking form's.

SMTP credentials are not your AWS access keys; they are generated separately in the SES console and belong to the Region. If the plugin cannot connect at all, that is a networking or credentials problem with different wording, not this one.

Jake: "The error named a customer's Hotmail address. I don't even know how I would verify that."

Ethan: "You cannot, and you should not try. Your form is pretending the customer wrote the email. Make the From your own address and put the customer in Reply-To. The customer still gets a reply; SES stops objecting."

Requesting production access, and what to write

Production access, granted per Region, removes the requirement to verify recipients. It does not remove the requirement to verify your sender, and it is not unlimited sending. In the console, choose the Region you will send from, open Account dashboard, and follow the request workflow; or from the CLI:

aws sesv2 put-account-details --region us-east-1 --production-access-enabled \
  --mail-type TRANSACTIONAL --website-url https://example.com --contact-language EN \
  --use-case-description "We send repair booking confirmations and order status notices to customers who request our services. Messages are transactional, sent only after a customer action. We monitor bounces and complaints and stop sending to invalid or opted-out addresses."

Submitting is a request, not an approval; check the Region's status afterwards and expect possible follow-up questions. The reviewer wants five things answered plainly: who the recipients are, how they came to expect mail from you, what you send, how much, and what you do about bounces and complaints. "We will send lots of email to customers" answers none of them. Something like this does:

Replace every detail with your real workflow; those numbers describe an example shop, not a target. If you send newsletters, say so and describe consent and unsubscribe handling. Disguising marketing as transactional is the quickest route to a refusal. And choose the mail type that honestly describes most of what you send: a booking confirmation is transactional; a monthly offer is not.

Jake: "How long until they say yes?"

Ethan: "Often quickly, sometimes with questions, never guaranteed. Until then the site should fail politely, with a message your staff can see, instead of silently dropping confirmations."

Production in one Region is not production everywhere

"We are out of the sandbox" is a sentence about one Region. Another Region has its own status and its own quotas, and a failover to it turns into a verification incident at the worst possible moment:

aws sesv2 get-account --region us-east-1 --query '{Production:ProductionAccessEnabled,SendQuota:SendQuota}'
aws sesv2 get-account --region eu-west-1 --query '{Production:ProductionAccessEnabled,SendQuota:SendQuota}'

Keep a short checklist per environment: sending Region, verified domain identity, SMTP or API endpoint, production status. Send only from Regions where all four line up. If you run a failover Region, verify the identity and request production access there before you need it; an approval request filed during an outage arrives after the outage.

Quotas work the same way. Production access in us-east-1 comes with that Region's sending quota and rate, which start modestly and grow with good sending history. A second Region starts from its own sandbox numbers. The SendQuota field in the get-account output above shows the 24-hour maximum, the per-second rate and how much of today's quota is already used, per Region.

Jake: "So 'we're out of the sandbox' is something you say about a place, not about the account."

Ethan: "About one post office. Say it with the Region attached or do not say it at all."

Testing without annoying anyone: the mailbox simulator

You do not need a verified inbox to test the plumbing. SES provides simulator addresses that behave like a real recipient without delivering anything: success@simulator.amazonses.com accepts the message, bounce@simulator.amazonses.com generates a hard bounce, complaint@simulator.amazonses.com generates a complaint, and there are addresses for out-of-office and suppression-list behavior too. They work in the sandbox without verification, they do not count against your sending quota, and they are the right way to test bounce handling without burning a real address's reputation. Send your plugin's test message to the success address first; if that works and a real inbox does not, you have isolated the sandbox or the recipient, not your configuration.

Three senders, three different SES configurations

A small business site often has more than one thing sending "email from the shop": a PHP contact form through SMTP, a Python job that emails the day's bookings through the SES API at six in the morning, and a third-party booking widget sending through delegated authorization. To a customer they are all the same sender. To SES they are three different routes, possibly in three different Regions, under three different sets of credentials.

Document each one: for SMTP, the endpoint hostname, the From header and which SMTP credential; for API clients, the SDK Region, the sender identity and the IAM principal; for delegated mail, which account owns the identity and which account sends. When one route works and another fails, compare those fields before touching organization-wide settings. A successful Python test in us-east-1 says nothing about a WordPress plugin connecting to a European SMTP endpoint, and fixing the plugin's From address does nothing for a nightly job with a hard-coded sender from 2023. Standardize the sender, keep different Reply-To addresses per purpose, and let SES always see an address the business controls.

One CLI send to separate SES from your plugin

When a plugin wraps the real error in a generic "mail failed" dialog, a direct SES send from the terminal, using an identity and a destination you control, tells you what the service itself thinks:

aws sesv2 send-email --region us-east-1 --from-email-address hello@example.com \
  --destination 'ToAddresses=test@example.com' \
  --content 'Simple={Subject={Data=SES identity check},Body={Text={Data=Test message}}}'

If this works and the plugin fails, the plugin's From address or Region is the bug, and SES identities are fine. If this fails with the identity error, copy its exact text and match it against the Verified identities list. If it fails with something else, fix that instead; not every mail failure is a verification failure.

DKIM and SPF: real, and not this problem

DKIM signs your messages so receivers can check the domain authorized them; SPF says which servers may send for an envelope domain. Both matter for landing in the inbox and for your domain's reputation. Neither one lifts the sandbox or fixes a wrong Region. SES domain verification uses Easy DKIM CNAME records for the Region and identity in question; a custom MAIL FROM adds an MX and an SPF TXT record on a subdomain. Adding an unrelated SPF value to the parent domain, or editing records for a domain you do not own, changes nothing about this error and can break authentication you had working. Our Route 53 page explains where those records live if the domain is hosted there.

Gmail, Microsoft 365 and forwarded mailboxes

You can verify a single Gmail or Outlook address, if you can receive the link there. You cannot verify gmail.com or outlook.com as a domain, because you do not control their DNS, and no amount of DNS editing on your own domain changes that. A forwarding mailbox is fine as long as the forward actually works; a broken forwarding rule is the usual reason an identity sits in Pending for days. For a business with its own domain, verify the domain, keep the customer-facing From on it, and use Reply-To for anything that needs to reach a team inbox.

Two accounts, one domain

If one AWS account owns the domain identity and a second account, a contractor's or a shared platform's, sends as it, verification in the first account does not authorize the second. SES has sending-authorization policies for that, scoped per identity and per Region, and the delegate account is still subject to its own sandbox status. This is how the owner's test works while the partner integration gets the identical rejection.

Jake: "The new contractor's setup fails with exactly my error. My credentials work."

Ethan: "An identity is not a universal password. The sending account, the authorization policy and the Region all have to agree. Right now one of the three is yours and two are his."

Failures that are not verification

Symptom	Category	Next check
Email address is not verified	Identity or sandbox	Sending Region, verified sender, permitted recipient
Authentication rejected	SMTP credentials or IAM	Credential type, principal, policy, endpoint
Maximum sending rate exceeded	Quota	Regional send quota and pacing
MailFromDomainNotVerified	Custom envelope DNS	MAIL FROM MX and SPF records, failure behavior
SES accepted it, customer saw nothing	Downstream delivery	Bounce events, recipient filters, provider response

A clean incident note records which stage failed: SMTP connection, SES authorization, or recipient delivery. Only the first two are visible from your side without bounce and complaint telemetry, and a "success" from the send API means SES accepted the message for processing, not that it reached an inbox. Our AccessDenied decoder handles the IAM flavor if your error is about permissions rather than identities.

Jake's case, start to finish

The plugin showed From: hello@example.com, the customer was customer@anotherdomain.com, the SMTP endpoint was in us-east-1, and the domain had been verified months before in us-west-2. Two problems at once: the sender was not verified in the sending Region, and the us-east-1 account was still sandboxed, so the customer's address was not allowed either. Fixing only the first would have changed the wording of the error and left the customer without a confirmation.

The sequence that worked: verify the domain in us-east-1 and publish its DKIM records; confirm the sandbox status there; request production access for us-east-1 with an honest description; set the plugin's From to the verified shop domain and move the visitor address to Reply-To; send one controlled test to a verified inbox to prove the application could authenticate and send through the right Region; and, once production access was granted, send to a real customer and watch the result. Then one more check that most people skip: a staff copy.

Jake: "One of the order forms copies staff@example.net on every message. That's just so the front desk sees it."

Ethan: "That extra recipient matters while you are sandboxed. Treat Cc and Bcc addresses as real destinations, not decorations. A hidden staff copy to an unverified inbox is enough to block the whole send."

Price, quota and approval are three different things

Verification costs nothing and is not a meter. The SES bill depends on messages sent and optional features; the sandbox quota decides who can receive before production access; and neither spending more nor buying a support plan grants production access. A shop sending 25 orders a day to one recipient each uses 25 recipient messages of the 200-a-day sandbox quota; copy the front desk on each and it is 50. Monitor the real quota with get-account, and if the approved use case grows, request a quota increase rather than assuming production access means unlimited.

When the error names a sender you did not choose

If the failed identity looks unfamiliar, something downstream of your settings rewrote the From header. A website is a stack: form plugin, SMTP plugin, mail template, custom code, and each layer can set a sender; the one that reaches SES is the one that counts. Start with the smallest possible email, the SMTP plugin's own test, and note its From. Then trigger the real booking flow and compare the identity in its failure. If they differ, the application path overrides the mailer, and the fix is in the form's notification settings or the code that touches headers. A "Force From Address" option is useful when it pins every email to your verified domain, and misleading when another plugin keeps rewriting the value underneath it.

Verified, and still rejected

A green Verified badge is only true for the Region you are looking at and the account you are in. Confirm both match the request. Then: a verified domain is not a wildcard for other domains, so no-reply@otherexample.org is not covered by example.com; a delegate account using your identity needs the authorization policy and its own production access; and "verified" is not quite "enabled for sending", which the identity lookup reports separately. If identity and recipient both look right, do one direct API send with the same Region and principal as the application and compare. A difference isolates the application; a match means SES is really saying no, and the identity lookup fields will say why.

A Region-safe deployment checklist

This error recurs after migrations, failovers and fresh staging environments, because the application moves cleanly and its mail setup does not. Make SES readiness a deployment step:

1. List every Region from which application code or SMTP plugins can send.
2. Verify the sender identity in each of those Regions.
3. Publish that Region's DKIM records for domain identities.
4. Check sandbox versus production status per Region.
5. Store the endpoint, Region and From address together as explicit configuration, not as something someone remembers clicking.
6. Send one controlled test per environment and record the Region, identity, time and response.

If the sender is an environment variable, document the expected value next to the SES Region; a deployment that copies the secret from one environment and picks a different Region authenticates perfectly and then gets this error. And check every sender: the booking page, the scheduled reminder job, the contractor's integration. It is easy for the main form to work while a nightly job uses a hard-coded sender nobody verified.

Ethan: "A working send is a property of one account, one Region and one actual message. Copying the website somewhere else does not copy every mail permission with it."

After SES says yes: delivery is a different job

Once SES accepts the message, verification is finished and a different chain starts: the receiving provider, spam filtering, bounces, complaints. A send that lands in junk is not fixed by verifying the sender again; it needs DKIM, SPF and DMARC alignment and a look at bounce and complaint events. Stop editing identities unless another identity error appears. For Jake the incident was closed only when a test order produced an accepted send and the customer's inbox showed the confirmation, because the original problem was a missing message to a customer, not a red label in a console.

Rolling back without destroying the evidence

When customers are waiting for receipts, five changes at once feels productive and wipes out the trail. Before editing, note the previous From, Region, endpoint and plugin settings. If the trouble started with a plugin upgrade, compare old and new effective From and Reply-To. If it started after a Region migration, check verification and sandbox status in the new Region before rolling the application back. If it started after a DNS change, inspect the identity's own records rather than deleting unrelated ones. A rollback restores a known authorized sender and endpoint; it is not a substitute for production access if the old environment was simply already approved. One controlled test after each change, with the exact wording of any remaining error, lets you say "sender authorized, remaining failure names the recipient" instead of "email is still broken".

The exact SES verification questions people search for

Jake's confirmations started arriving the day production access came through for us-east-1. The fix list was short once it was written down: verify the domain in the Region that sends, stop impersonating the visitor, move the staff copy to a verified inbox until production, request access honestly. The plugin settings page now has a note taped to the monitor beside it, in Jake's handwriting: "Virginia, not Oregon."

Revision note. Written October 9, 2026, with the per-Region sandbox rules and the production-access form as they stand. Trust, but verify: SES means it literally, in every Region you send from.