Fix AWS SES MessageRejected: Email Address Not Verified (Sandbox Mode)

beginnerโ˜๏ธ AWS2026-03-26| AWS SES (Simple Email Service), any region, SDK/SMTP/CLI

Error Message

MessageRejected: Email address is not verified. The following identities failed the check in region US-EAST-1: recipient@example.com
#ses#email#sandbox#smtp#production

The Error

You send an email through AWS SES and get this back immediately:

MessageRejected: Email address is not verified. The following identities failed the check in region US-EAST-1: recipient@example.com

Your sender address works. Your credentials are fine. SES still rejects every outbound email. That's the Sandbox doing its job โ€” unfortunately, against you.

Root Cause

Every new AWS account starts with SES locked in Sandbox mode. In this mode, SES only allows sending to email addresses or domains you've explicitly verified โ€” no arbitrary recipients, no exceptions.

Sandbox also caps you at 200 emails per day and 1 message per second. The error surfaces when any of these conditions apply:

  • The recipient address hasn't been verified in SES
  • You're still in Sandbox and haven't requested production access
  • Your identity is verified in one region (e.g., us-east-1) but you're sending via a different one (e.g., eu-west-1)

Fix Option 1: Request Production Access (Recommended)

For any real application, this is the fix you want. Production access removes the verified-recipients restriction and raises your sending quota to 50,000 emails/day by default.

  • Go to AWS Console โ†’ SES โ†’ Account Dashboard
  • Click Request production access
  • Fill in the form: use case, estimated volume, how you handle bounces and complaints
  • Submit โ€” AWS typically reviews requests within 24 hours, though complex cases can take longer

Prefer the CLI? Submit the request directly:

aws sesv2 put-account-details \
  --mail-type TRANSACTIONAL \
  --website-url https://yourapp.com \
  --use-case-description "Sending transactional emails (password reset, order confirmation) to registered users who opted in" \
  --additional-contact-email-addresses your@email.com \
  --production-access-enabled \
  --region us-east-1

Check whether your account is already approved:

aws sesv2 get-account --region us-east-1

Look for "ProductionAccessEnabled": true in the response. If it says false, the request is still pending or hasn't been submitted yet.

Fix Option 2: Verify the Recipient Email (Quick for Testing)

Still waiting on production access? Verify the specific addresses you need to test with. SES sends a verification link to that inbox โ€” once clicked, that address is fair game in Sandbox.

# Verify a recipient email address
aws ses verify-email-identity \
  --email-address recipient@example.com \
  --region us-east-1

Check all currently verified identities:

aws ses list-identities --region us-east-1

Need to confirm a specific address is verified before sending?

aws ses get-identity-verification-attributes \
  --identities recipient@example.com \
  --region us-east-1

A verified address returns this:

{
    "VerificationAttributes": {
        "recipient@example.com": {
            "VerificationStatus": "Success"
        }
    }
}

Anything other than Success โ€” like Pending โ€” means the recipient hasn't clicked the verification link yet.

Fix Option 3: Verify an Entire Domain

Verifying addresses one-by-one gets tedious fast. Verify the whole domain instead โ€” every address at that domain becomes a valid recipient in Sandbox mode automatically.

# Get the TXT record to add to your DNS
aws ses verify-domain-identity \
  --domain example.com \
  --region us-east-1

AWS returns a verification token. Add it as a TXT record in your DNS provider:

_amazonses.example.com  TXT  "your-verification-token-here"

DNS propagation typically takes a few minutes to a few hours. Check verification status once it propagates:

aws ses get-identity-verification-attributes \
  --identities example.com \
  --region us-east-1

Fix Option 4: Region Mismatch

SES identities are region-scoped. Verifying your domain in us-east-1 does nothing for requests sent through eu-west-1 โ€” you'll hit the same MessageRejected error even though verification looks fine in the console.

Make sure your code targets the region where your identity actually lives:

import boto3

# region_name must match where your identity is verified
client = boto3.client('ses', region_name='us-east-1')

response = client.send_email(
    Source='verified-sender@yourdomain.com',
    Destination={'ToAddresses': ['recipient@example.com']},
    Message={
        'Subject': {'Data': 'Test'},
        'Body': {'Text': {'Data': 'Hello'}}
    }
)

Compare what's verified across regions to spot the mismatch:

aws ses list-identities --region us-east-1
aws ses list-identities --region eu-west-1

Verify the Fix Worked

Send a test email straight from the CLI โ€” fastest way to confirm things are working:

aws ses send-email \
  --from "sender@yourdomain.com" \
  --destination "ToAddresses=recipient@example.com" \
  --message "Subject={Data=Test,Charset=UTF-8},Body={Text={Data=It works,Charset=UTF-8}}" \
  --region us-east-1

Success looks like this:

{
    "MessageId": "0100018e1234abcd-..."
}

No MessageRejected means you're clear.

Prevention

  • Submit the production access request early. Don't wait until launch day. File it the moment you set up SES โ€” approval isn't instant, and getting blocked during a production deploy is painful.
  • Use SES simulator addresses during automated tests. AWS provides addresses like success@simulator.amazonses.com and bounce@simulator.amazonses.com that work in Sandbox without verification and don't count against your 200/day quota.
  • Set up SNS bounce and complaint notifications before going to production. AWS requires this for production access anyway, and skipping it after approval puts your sender reputation at risk โ€” enough complaints will get your account suspended.
  • Each new region is a fresh start. Expanding to ap-southeast-1 or any other region means re-verifying your domains and filing a separate production access request for that region.

Related Error Notes