Amazon Simple Email Service (SES) is AWS’s managed email-sending service for transactional messages, application notifications, alerts, password resets, verification emails, newsletters, and other email workloads. This guide explains SES from the ground up, including architecture, DNS authentication, SMTP and API examples, monitoring, and production practices.
What problem does Amazon SES solve?
Applications that send email must account for mail servers, IP reputation, authentication, retries, delivery events, bounces, and complaints. Operating that infrastructure is difficult. Amazon SES provides the sending platform so application teams can focus on message workflows.
- User registration and email verification.
- Password-reset links and MFA codes.
- Order confirmations and invoices.
- Application alerts and monitoring notifications.
- Support-ticket notifications.
- Scheduled reports.
- Opt-in product announcements and newsletters.
The easiest SES mental model
Your application → SES API or SMTP → Amazon SES → recipient mail server → inbox. The application submits a request through an AWS SDK/API or SMTP. SES processes the message and attempts delivery to the recipient’s mail server.
SES architecture for a production application
A typical workload uses an application, Lambda, ECS, or EC2 with an IAM role to call Amazon SES, which delivers to internet mailboxes. DNS records establish DKIM, SPF, and DMARC authorization. Configuration sets publish operational events to services such as SNS, EventBridge, CloudWatch, or Firehose.
DNS proves that SES is authorized to send for the domain, IAM controls which workload may call SES, and configuration-set events provide visibility into sends, deliveries, bounces, and complaints.
Verified identities: email address vs domain
Before sending email, SES requires a verified identity. An identity can be an individual email address or an entire domain.
| Identity | Best use |
|---|---|
| Email address | Quick testing or a single sender such as alerts@example.com. |
| Domain | Production workloads where addresses such as no-reply@example.com and support@example.com may send. |
For production, domain verification is usually cleaner because addresses under the domain can inherit its verification and DKIM setup.
SES sandbox vs production access
New SES accounts begin with sandbox restrictions in each AWS Region. The sandbox is intended for safe testing.
| Sandbox | Production access |
|---|---|
| Sender identity must be verified. | Sender identity must still be verified. |
| Recipients generally must also be verified, except mailbox simulator addresses. | Messages can be sent to unverified recipient addresses. |
| Low sending quotas and rate limits. | Higher limits based on approved account quotas. |
| Suitable for testing. | Required for real customer email. |
How to move SES out of the sandbox
- Open Amazon SES in the AWS Region you will use.
- Verify the sending domain.
- Configure DKIM and email authentication.
- Open Account dashboard or the production-access workflow.
- Request production access.
- Describe the email use case clearly.
- Confirm how recipients opt in.
- Explain how bounces and complaints are handled.
- Submit the request and wait for AWS review.
SES is regional
SES identities, sandbox status, sending limits, and SMTP endpoints are Region-specific. Verify the identity in the same Region from which you plan to send, and use that Region’s SES API or SMTP endpoint.
DKIM: prove the message was authorized
DomainKeys Identified Mail (DKIM) cryptographically signs outgoing email so recipient systems can verify that the domain authorized the message and that signed content was not modified in transit. With SES Easy DKIM, AWS provides DNS records for the domain. After DNS verification, SES signs outgoing mail automatically.
SPF and the MAIL FROM domain
Sender Policy Framework (SPF) lets receiving systems check whether a server is authorized to send mail for a domain. SES can use its default MAIL FROM domain, or a custom MAIL FROM subdomain such as bounce.example.com. For a custom MAIL FROM domain, publish the MX and SPF TXT records supplied by AWS.
From: notifications@example.com
MAIL FROM / Return-Path: bounce.example.comDMARC: protect the From domain
DMARC builds on SPF and DKIM, checks domain alignment, and lets a domain owner publish a policy for authentication failures.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Start with monitoring, review reports, and move toward stronger enforcement such as quarantine or reject only after validating every legitimate sender for the domain.
SMTP vs SES API
| Method | Good fit |
|---|---|
| SES API / AWS SDK | Applications already running in AWS, or codebases that can use an SDK and IAM roles. |
| SMTP | Existing applications, frameworks, or devices that support SMTP but not AWS SDKs. |
SMTP credentials are not normal AWS credentials
SES SMTP credentials are separate from access keys used with the AWS CLI. Generate SMTP credentials for the SES Region and configure the client with the matching Regional endpoint, username, password, and TLS settings.
Example: send email with AWS CLI
aws sesv2 send-email \
--region ap-south-1 \
--from-email-address no-reply@example.com \
--destination 'ToAddresses=user@example.net' \
--content 'Simple={Subject={Data="SES test"},Body={Text={Data="Hello from Amazon SES"}}}'The sender identity must be verified. If the account is still in the sandbox, recipient restrictions also apply.
Example: send email with Python and boto3
import boto3
ses = boto3.client("sesv2", region_name="ap-south-1")
response = ses.send_email(
FromEmailAddress="no-reply@example.com",
Destination={"ToAddresses": ["user@example.net"]},
Content={
"Simple": {
"Subject": {"Data": "Welcome"},
"Body": {
"Text": {"Data": "Welcome to our application."},
"Html": {"Data": "<h1>Welcome</h1><p>Your account is ready.</p>"},
},
}
},
)
print(response["MessageId"])IAM policy for an application
If the application runs on EC2, ECS, Lambda, or another AWS service, prefer an IAM role over static access keys.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ses:SendEmail",
"ses:SendRawEmail"
],
"Resource": "*"
}
]
}For stronger least privilege, scope sending to the identities and conditions the workload actually requires.
What happens after SES accepts a message?
- The application submits the email.
- SES validates the request and sender identity.
- SES attempts delivery to the recipient’s mail system.
- The recipient provider can accept, delay, reject, or bounce the message.
- SES records delivery events and reputation signals.
- The monitoring pipeline can consume those events.
Configuration sets
A configuration set groups sending rules and event-publishing settings that can be applied to email. It is one of the most useful SES features for production systems.
- Sends.
- Deliveries.
- Delivery delays.
- Bounces.
- Complaints.
- Rejects.
- Rendering failures.
- Opens and clicks when engagement tracking is enabled.
SES event architecture
Amazon SES → configuration set → SNS, EventBridge, CloudWatch, or Firehose. For example, bounce and complaint events can flow to SNS or EventBridge, invoke Lambda, and update the application’s suppression table.
Bounces and complaints
Bounce
The recipient mail server cannot deliver the message. A hard bounce should normally cause the address to stop receiving further mail.
Complaint
The recipient marks the message as spam, or the provider reports a complaint. Continuing to send to complainers can damage sender reputation.
Monitor both closely because sender reputation affects the ability to continue sending through SES.
Suppression lists
SES suppression mechanisms help prevent repeated sending to addresses associated with hard bounces or complaints. Account-level suppression lists can suppress addresses for BOUNCE, COMPLAINT, or both. The application should also maintain recipient-quality controls and an unsubscribe or preference model rather than treating SES suppression as the only protection.
Mailbox simulator
The SES mailbox simulator provides special addresses for safely testing delivery, bounce, and complaint scenarios without damaging reputation metrics. It is particularly useful in the sandbox and for notification-workflow testing.
Transactional vs marketing email
| Transactional | Marketing / bulk |
|---|---|
| Password reset | Newsletter |
| Order confirmation | Product campaign |
| Security alert | Promotional announcement |
| Account verification | Opt-in offers |
Both can use SES, but bulk email requires especially careful consent, unsubscribe handling, list hygiene, and reputation monitoring.
Recommended production architecture
Application
|
| IAM role + SES API
v
Amazon SES
|
+----> Recipient mail servers
|
+----> Configuration Set
|
+----> SNS / EventBridge
|
+----> Lambda
|
+----> Update bounce/complaint status
DNS:
DKIM
SPF / custom MAIL FROM
DMARCSES pricing model
SES uses usage-based pricing. Charges depend on the sending method, volume, data transferred, attachments, and optional features. Exact prices vary by Region and can change, so check the current AWS SES pricing page before estimating production cost. SNS, EventBridge, CloudWatch, Lambda, Route 53, and data transfer may create separate charges.
Common SES errors and fixes
| Problem | Likely cause | Fix |
|---|---|---|
| Email address is not verified | Sender identity is not verified in the active Region. | Verify the email or domain in that SES Region. |
| Recipient rejected in sandbox | Recipient is not verified. | Verify the recipient for testing or request production access. |
| SMTP authentication fails | AWS access keys were used instead of SMTP credentials, the Region endpoint is wrong, or TLS settings are incorrect. | Create SES SMTP credentials and use the matching Regional endpoint. |
| Email delivered to spam | Authentication, reputation, content, or recipient-engagement issue. | Check DKIM, SPF, DMARC, list quality, and message content. |
| Message rejected for quota | Daily quota or sending rate was reached. | Throttle sending or request an appropriate quota increase. |
| High bounce rate | Old or invalid recipient list. | Stop sending to hard bounces and improve list validation. |
Deliverability best practices
- Verify and authenticate the sending domain.
- Enable DKIM.
- Use DMARC and monitor reports.
- Configure a custom MAIL FROM domain when the architecture requires SPF alignment.
- Send only to recipients who expect the email.
- Remove hard-bounced addresses immediately.
- Honor complaints and unsubscribe requests.
- Warm sending volume gradually instead of creating a sudden large spike.
- Use consistent sender names and addresses.
- Separate transactional and marketing workloads with identities or configuration sets where useful.
- Monitor reputation metrics continuously.
SES vs SNS
SES sends email. SNS is a publish/subscribe messaging service that can deliver notifications to HTTP endpoints, Lambda, SQS, SMS, and email subscriptions. SNS email subscriptions suit simple operational notifications; SES is better when an application needs fully composed transactional or bulk email.
SES vs Amazon WorkMail
SES is primarily email-sending and receiving infrastructure for applications. Amazon WorkMail is a managed business email and calendar service with end-user mailboxes. SES does not replace an Outlook-like mailbox service.
When should you use SES?
- The application needs reliable transactional email.
- API- or SMTP-based sending is required.
- Custom domains and email authentication are needed.
- Delivery and bounce events must be handled programmatically.
- Email must integrate with Lambda, ECS, EC2, Kubernetes, or SaaS applications.
- A scalable alternative to self-managed SMTP infrastructure is required.
Beginner hands-on lab
- Choose one SES Region.
- Create a verified email identity for testing.
- Use the SES console to send a test message.
- Create a verified domain identity.
- Publish the DKIM records in Route 53 or another DNS provider.
- Test with the SES mailbox simulator.
- Create a small IAM role or user permitted only to send email.
- Send a message with the AWS CLI or an SDK.
- Create a configuration set.
- Publish bounce and complaint events to SNS or EventBridge.
- Request production access only after the sending workflow and recipient handling are ready.
Frequently asked questions
Is Amazon SES a mail server?
It is a managed email service and sending platform. Customers do not manage the underlying outbound mail-server infrastructure.
Can SES send email from my own domain?
Yes. Verify the domain in SES, publish the required DNS authentication records, and send from addresses covered by that identity.
Why can’t I send to any recipient?
The account is probably still in the SES sandbox. Sandbox recipient restrictions apply until production access is approved.
Can I use Gmail or Outlook SMTP credentials with SES?
No. SES has its own Regional SMTP endpoints and SES SMTP credentials.
Should an EC2 or ECS application store SMTP passwords?
Prefer the SES API with an IAM role. If an existing application requires SMTP, store SES SMTP credentials in a secrets service rather than hardcoding them.
Can SES receive email?
SES supports inbound email receiving in supported Regions, but receiving uses a separate architecture from the outbound flow covered here.
Official AWS references
- Getting started with Amazon SES: https://docs.aws.amazon.com/ses/latest/dg/getting-started.html
- Verified identities: https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html
- Request production access: https://docs.aws.amazon.com/ses/latest/dg/request-production-access.html
- Email authentication methods: https://docs.aws.amazon.com/ses/latest/dg/email-authentication-methods.html
- Send email using the SES API: https://docs.aws.amazon.com/ses/latest/dg/send-email-api.html
- Send email using SMTP: https://docs.aws.amazon.com/ses/latest/dg/send-email-smtp.html
- SES configuration sets: https://docs.aws.amazon.com/ses/latest/dg/using-configuration-sets.html
Conclusion
Amazon SES is AWS-managed email-delivery infrastructure for applications. Verify the domain, authenticate it with DKIM, SPF, and DMARC, choose the API or SMTP, move carefully from sandbox to production, and treat bounces, complaints, and recipient consent as core architectural concerns. With those pieces designed correctly, SES is a scalable, cost-efficient foundation for transactional and application email.
Join the discussion
0 CommentsAsk questions, add context, or share what worked.
More from Melochip Editorial
Learn what Playwright testing is, why modern QA teams use it, how testers can get started, and the major types...
7 min read · Sep 19, 2026
Learn how Kubernetes Deployments and ReplicaSets work with practical YAML, scaling, self-healing, rolling upda...
7 min read · Sep 17, 2026
Learn Kubernetes security best practices with RBAC, Secrets, ServiceAccounts, Pod securityContext, NetworkPoli...
6 min read · Sep 17, 2026Related articles
Learn Kubernetes monitoring and logs with kubectl logs, events, metrics-server, top commands, Prometheus, Graf...
5 min read · Sep 17, 2026
Learn how Kubernetes Deployments and ReplicaSets work with practical YAML, scaling, self-healing, rolling upda...
7 min read · Sep 17, 2026
Learn Kubernetes Ingress with controllers, IngressClass, host and path routing, TLS, DNS, annotations, redirec...
8 min read · Sep 17, 2026
Learn Kubernetes ConfigMaps and Secrets with YAML, environment variables, file mounts, update behavior, immuta...
8 min read · Sep 17, 2026Stay in the loop. Get new Melochip articles
Receive Melochip article updates when new articles are available. Explicit opt-in only.
No comments yet. Start the discussion.