// how to fix
Amazon SES "Email address is not verified": sandbox and identities fixed
Amazon SES rejects your email because a sender or recipient identity is not verified. Verify identities, leave the sandbox and send safely.
What it means
Amazon SES (Simple Email Service) refused to send your message because one of the addresses in it is not a verified identity in your AWS account, in the AWS Region you are using. An identity is an email address or a domain that you proved you own. The error looks like this through SMTP:
554 Message rejected: Email address is not verified. The following identities failed the check in region US-EAST-1: sender@yourdomain.com, customer@example.com
Through the API or an SDK it comes back as a MessageRejected error with the same text. The list at the end tells you exactly which identities failed. If it is too long, it ends with an ellipsis (...).
Why it happens
- The sender is not verified. SES only sends from addresses or domains you verified. This applies to the From, Sender and Return-Path addresses (and
FromEmailAddressin the API). - Your account is still in the sandbox. Every new SES account starts in the sandbox. There, you can only send to verified addresses or domains, or to the SES mailbox simulator. By default the sandbox also limits you to 200 messages per 24 hours and 1 message per second.
- Wrong Region. Verification and sandbox status are separate for each AWS Region. A domain verified in
eu-west-1is unknown inus-east-1. Check the Region in your SMTP endpoint (email-smtp.eu-west-1.amazonaws.com) or SDK configuration. - A typo or a different address. Your app sends from
noreply@mail.yourdomain.combut you verifiedyourdomain.comonly for another subdomain, or you verified a single address that is not the one used.
How to check
- Read the identities listed in the error. Note whether it is your sender, your recipient, or both.
- In the SES console, select the right Region, then open Identities (under Configuration). Each identity must show the status Verified.
- Open the Account dashboard. If a banner says Your Amazon SES account is in the sandbox, recipients must be verified too. With the AWS CLI:
aws sesv2 get-account --region us-east-1shows"ProductionAccessEnabled": falsewhile you are in the sandbox. - Check your domain records on the Delivmail domain scanner: SES verifies a domain through its DKIM records, so missing DKIM records mean the domain cannot become Verified.
How to fix it
Verify the sender
Verifying the whole domain is better than verifying single addresses: every address on it becomes usable, and it enables DKIM signing. In Identities, choose Create identity, pick Domain, and publish the three DKIM CNAME records SES shows you. If the status stays pending, see Amazon SES DKIM verification pending or failed. For a single address, choose Email address and click the link in the message SES sends to it.
While testing in the sandbox
Verify each test recipient as an email identity, or send to the mailbox simulator, for example success@simulator.amazonses.com. This is fine for development, not for real customers.
Request production access
In the console: Account dashboard, then View Get set up page, then Request production access. Choose Marketing or Transactional, give your website URL, and confirm that you only send to people who asked for your email and that you handle bounces and complaints. You can also do it from the CLI:
aws sesv2 put-account-details \ --production-access-enabled \ --mail-type TRANSACTIONAL \ --website-url https://yourdomain.com \ --contact-language EN \ --region us-east-1
AWS says it gives an initial response within 96 hours. Explain clearly how people sign up, how you remove bounced addresses and how they can unsubscribe. A verified domain with DKIM helps the request. Do this for each Region you send from.
Leaving the sandbox raises the default limits; if you later hit a rate or daily quota, see Amazon SES throttling errors. Once in production, you still have to verify every sender identity.
Check that it is fixed
Copy your unique test address from the Delivmail home page and send it a message through SES with your normal app settings. In the sandbox this only works if you verify that test address first; in production it works directly. The report should show DKIM passing for your domain. Then resend to the recipient that failed. If the error still lists an identity, compare its spelling and the Region in the error with what the console shows.
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- Gmail bounce "550 5.7.26": unauthenticated emailGmail refused your email because it could not confirm it comes from your domain. SPF, DKIM or DMARC is missing or failing. Here is how to fix it.
- Bounce "550 5.7.1": message rejected or blocked by policyA 5.7.1 bounce means the receiving server refused your email on purpose. Learn to read bounce messages, find the real reason and fix it.
- High bounce rate: clean your mailing listSending to addresses that no longer exist damages your reputation fast. Learn the difference between hard and soft bounces and remove bad addresses after every send.
- Emails delayed: greylisting and 4xx temporary errorsSome servers answer "try again later" on purpose. A normal mail server retries and the email arrives a few minutes late. Here is how to tell normal delays from real problems.
- Yahoo and AOL "421 4.7.0 [TSS04]" deferralsYahoo is temporarily refusing your emails because of their volume or complaints. Slow down, keep retrying, and fix what Yahoo does not like.