AWS SES
email sending
non-verified email
cloud services
email tutorial

How to send email to non-verified email address using AWS SES

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

With Amazon SES, the rule is simple: in the sandbox, you can send only to verified recipients, but outside the sandbox you can send to normal unverified recipients. The sender identity still needs to be verified, but the recipient address does not once your SES account has production access.

The Real Restriction: Sandbox vs Production

New SES setups begin in the sandbox. In that mode, SES limits sending so you can test safely and build sending reputation. The practical effects are:

  • you must verify the sender identity
  • recipient addresses must also be verified
  • sending limits are low

If you want to send to arbitrary customer addresses, you need to move the SES account out of the sandbox. That is the actual answer to “how do I send to a non-verified address?” You do not verify every customer address one by one; you request production access.

What Still Must Be Verified

Even in production, SES still expects you to verify what you send from. Usually that means verifying a domain, which lets you send from addresses at that domain.

Typical setup steps are:

  1. verify a domain or sender email identity in SES
  2. configure DKIM and, ideally, SPF and DMARC for deliverability
  3. request production access for the SES region you are using
  4. monitor bounces and complaints carefully

The recipient does not need verification after production access is granted.

Sending a Message with Boto3

Once the account is out of the sandbox and the sender identity is verified, sending to a normal recipient is straightforward.

python
1import boto3
2
3ses = boto3.client("ses", region_name="us-east-1")
4
5response = ses.send_email(
6    Source="[email protected]",
7    Destination={
8        "ToAddresses": ["[email protected]"],
9    },
10    Message={
11        "Subject": {"Data": "Welcome"},
12        "Body": {
13            "Text": {
14                "Data": "Your account is ready."
15            }
16        },
17    },
18)
19
20print(response["MessageId"])

In this example, [email protected] must belong to a verified SES identity. [email protected] does not need to be verified if the SES account has production access.

How to Tell What Is Blocking You

If SES rejects the send, the error usually tells you whether the problem is sandbox access, identity verification, or policy configuration.

A quick mental checklist is:

  • is the SES account still in the sandbox for this region
  • is the Source identity verified
  • is the application calling the correct SES region
  • does the IAM role or user have permission to send

The region check matters because SES identity verification and production status are region-scoped. A verified identity in one region does not automatically apply in another.

Deliverability Matters More Than Raw Permission

Getting out of the sandbox only gives you permission to send. It does not guarantee good inbox placement or account health. SES expects you to handle:

  • bounce processing
  • complaint processing
  • unsubscribe flows where relevant
  • clean recipient lists

That is why domain-level authentication is important even though the question is really about recipient verification.

Common Pitfalls

The most common mistake is thinking the recipient must always be verified. That is true only in the sandbox.

Another mistake is forgetting that the sender identity still must be verified in production. Moving out of the sandbox does not remove that requirement.

It is also easy to verify an identity in one SES region and then try sending from another region, which makes it look like verification “did not work.”

Summary

  • In SES sandbox mode, both sender and recipient addresses must be verified.
  • To send to non-verified recipients, request production access for your SES region.
  • The sender identity still must be verified even after production access is granted.
  • Domain verification plus DKIM is usually the best production setup.
  • If sending fails, check sandbox status, identity verification, region, and IAM permissions.

Course illustration
Course illustration

All Rights Reserved.