# Amazon SES "Email address is not verified": Causes and Fix

Source: https://wraps.dev/ses/errors/email-address-not-verified

Identity and verificationMessageRejectedSMTP 554

Why SES returns MessageRejected with “Email address is not verified”, how to tell a sandbox account from an unverified identity, and the fix for each.

## The error

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

AWS exception `MessageRejected`. The Wraps CLI reports it as `SES_MESSAGE_REJECTED`.

## Why this happens

The request reached SES and SES refused it. Nothing is wrong with your credentials, your IAM policy, or your network. SES checked the identity on the request against the identities verified in that region and did not find a match it was willing to send from or to.

-   The account is in the SES sandbox and the recipient is not a verified address.
-   The sender identity, domain or email, is not verified for sending.
-   The sender domain is verified for receiving but not for sending.

## How to fix it

1.  ### 1. Read the region out of the message
    
    The identity list in the error names the region SES checked. SES identities are per region, so a domain verified in us-east-1 is unverified in eu-west-1. If the region in the message is not the one you meant to send from, that is the whole bug.
    
2.  ### 2. Check whether the account is still in the sandbox
    
    A sandboxed account can only send to addresses and domains it has verified. If the failing identity in the message is the recipient rather than the sender, that is the sandbox.
    
    ```
    wraps email statuswraps email doctor
    ```
    
3.  ### 3. Verify the sender identity for sending
    
    A domain added to SES for receiving mail is not automatically usable as a From address. Verify the identity you send from, and confirm its DKIM records are published and reported by SES as verified.
    
    ```
    wraps email verify
    ```
    
4.  ### 4. Request production access to leave the sandbox
    
    Production access is an AWS decision and an AWS form. Approval times vary and requests do get denied, so leave room for it in a launch schedule rather than treating it as a formality.
    

## How to stop it recurring

### Send a probe before you send traffic

Run an identity check as a deploy step rather than discovering the gap from a failed production send. Both the sandbox state and the verification state are readable before anything is queued.

### Pin the region everywhere

Most repeat occurrences are a region mismatch between the deploy and the send, not a verification that was never done. Set the region explicitly in both places.

## Common questions

### Why does SES say the address is not verified when I verified it?

Almost always a region mismatch. SES identities are scoped to a region, and the error names the region SES actually checked. Verify the identity in the region you send from, or send from the region where it is verified.

### Do I need to verify the recipient as well as the sender in SES?

Only while the account is in the SES sandbox. A sandboxed account can send only to verified addresses and domains. Once AWS grants production access, only the sender identity has to be verified.

### My domain is verified for receiving mail but sends still fail. Why?

Verification for receiving does not imply verification for sending. The sending path also needs DKIM published and reported as verified for that identity in that region.

### What SMTP code does this error use?

The SES SMTP interface returns 554 for a rejected message, carrying the same text the API returns as MessageRejected.

## What Wraps does about this

The Wraps CLI maps this exception to SES\_MESSAGE\_REJECTED and prints the three causes above instead of the raw string, so you do not have to guess which one you hit. \`wraps email doctor\` reads the identity and sandbox state before a send, which is where this failure is cheapest to find. Wraps cannot get you out of the sandbox. Production access is AWS's call.
