What Is Amazon AWS SES? Email Your App Can Afford

Amazon SES (the full form is Simple Email Service) is AWS's email-sending platform — your application calls an API or connects over SMTP, and AWS delivers the email from infrastructure that Amazon built to serve its own retail empire. But here is the part almost nobody tells you: every new SES account starts locked in a sandbox that caps you at 200 emails per day, 1 email per second, and — the part that really bites — only to verified email addresses you have already confirmed you own. You cannot email a single real customer until AWS reviews your production access request. That gate is the single biggest surprise in the service, and this guide covers exactly how to get through it.

First, a disambiguation that saves people real confusion: if you searched "AWS SES" and landed on Session Manager, that is a completely different service — it lets you SSH into EC2 instances through the AWS CLI without managing keys. If you searched and found SNS (Simple Notification Service), that is also different — it sends push notifications, SMS messages, and can trigger emails, but it is not an email platform. SES is the one that sends actual email from your application. Three services, three jobs, names that collide constantly.

That sandbox is not a bug or an oversight — it is the reason SES can charge $0.10 per thousand emails while full-service email platforms charge $10 or more. AWS is protecting the reputation of the email infrastructure it shares across all SES customers: if any new account could immediately blast millions of unsolicited messages, every inbox provider on earth would start filtering SES traffic into spam. The gate exists so that AWS can verify, before you scale, that you are sending email people actually asked for.

The second thing worth internalizing: SES is an email platform, not an email marketing platform. The distinction matters. Mailchimp, SendGrid, and similar services bundle sending with template design, list management, A/B testing, campaign analytics, and visual editors. SES gives you the sending infrastructure — the API, the SMTP relay, the authentication protocols, the bounce and complaint handling — and leaves the marketing layer to you or to tools you build on top. That division of labor is exactly why SES costs a tenth of what the bundled platforms charge: you are paying for the pipes, not the furniture.

How AWS SES Works: Two Ways In, One Infrastructure Behind

SES gives you two integration paths for sending email, and choosing between them is the first architectural decision:

The SES API. Your application calls SendEmail (or the newer SendBulkEmail) through an AWS SDK — the same authentication, the same IAM roles, the same request-signing as every other AWS service. This is the path for applications already on AWS: no SMTP handshake overhead, credentials managed by IAM, and the tightest integration with the rest of your stack.

The SES SMTP interface. SES exposes standard SMTP endpoints that any mail-capable application can connect to — postfix, sendmail, any library that speaks SMTP in any programming language. You generate SES-specific SMTP credentials (separate from your AWS credentials, and not interchangeable with them) and point your existing email code at the SES endpoint. This is the path for applications you cannot or do not want to modify: if it can send email today, it can send through SES tomorrow.

Behind either path, the same infrastructure: SES receives your message, applies the authentication you configured (DKIM signing, SPF alignment), sends it to the recipient's mail server, and records what happened — delivery, bounce, complaint, open, click — which you can route to CloudWatch, SNS, Kinesis Firehose, or Lambda for handling.

What you can send (and receive)

The documented use cases cover the full spectrum:

• Transactional email — order confirmations, password resets, shipping notifications, receipts. Triggered by user action, one-to-one, time-sensitive. This is SES's home turf.
• Marketing email — special offers, promotional campaigns, newsletters. One-to-many, targeted lists. SES handles the sending; you build or buy the campaign management layer.
• Newsletters and correspondence — regular communications to subscribers. Same infrastructure, same pricing, same deliverability tools.
• Inbound email — SES can also receive email, which enables autoresponders, unsubscribe systems, and applications that generate customer support tickets from incoming messages. Received email can be stored in S3, trigger Lambda functions, or publish to SNS — turning your inbox into an event source for your application.

SES vs. SNS (and Session Manager): Three Services People Constantly Confuse

"AWS SES vs SNS" is one of the most searched SES questions, and the confusion is structural: both are AWS messaging services, both can send notifications, and their names sound like they belong to the same family. They do not. Here is the honest disambiguation:

The key distinction between SES and SNS: SNS can send email as one of its delivery protocols, but it sends simple notification-style emails — not designed email campaigns, not authenticated bulk email, not transactional messages with DKIM signing and bounce management. If you need "tell these 50 systems that a build finished," that is SNS. If you need "send this customer their order confirmation," that is SES.

The Session Manager confusion is purely the name: people searching "aws session manager" who mean SES get pointed at a completely unrelated service. If you landed here from that search and you actually want to SSH into an EC2 instance without keys, Session Manager is the tool. If you want to send email, you are in the right place.

Identities: Proving You Own the Address You Send From

Before SES sends anything on your behalf, you verify an identity — the email address or domain you will send from. Verification is DNS-based for domains: SES gives you a TXT record to add, you add it, SES confirms the domain is yours. For individual email addresses, SES sends a confirmation email and you click the link.

Domain verification is the one you want in any real setup, for three reasons:

1. Every address on the domain is verified at once — orders@, support@, no-reply@ — instead of verifying each one individually.
2. Domain verification is what enables DKIM signing for that domain, which is the foundation of email authentication.
3. AWS's own documentation notes that verifying your domain before requesting production access is a best practice that helps get the request approved faster.

After production access, you still have to verify all identities you use as "From," "Source," "Sender," or "Return-Path" addresses — the sandbox restriction on recipients lifts, but the identity verification requirement is permanent.

DKIM, SPF, and DMARC: The Three Protocols That Decide Whether Your Email Arrives

Email authentication — DKIM, SPF, and DMARC — is the technical foundation of deliverability, and it is where SES setups succeed or silently fail into spam folders. Three protocols, each solving a different piece of the "is this email really from who it claims to be from" problem:

DKIM (DomainKeys Identified Mail) — cryptographic signatures on each email, verified against a public key published in your DNS. SES offers Easy DKIM: you add three CNAME records SES generates, and SES automatically signs every email you send through the verified domain. No code changes, no key management — the DNS records are the entire setup. SES also supports BYODKIM (Bring Your Own DKIM) if you want to manage your own key pairs, and S/MIME signing for message-level encryption.

SPF (Sender Policy Framework) — a DNS TXT record listing which mail servers are authorized to send email for your domain. Inbox providers check the record; email from servers not on the list is suspicious. For SES, the SPF setup includes SES's servers in your domain's record — and if you use a custom MAIL FROM domain (a subdomain you designate for SES's envelope sender), SPF can align with your domain, which is what DMARC wants to see.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — the policy layer on top of DKIM and SPF. Your DMARC record tells inbox providers what to do when authentication fails: monitor (report only), quarantine (send to spam), or reject. DMARC also gives you aggregate reports showing who is sending email as your domain — including spoofers you did not authorize.

The Sandbox and How to Escape It: Requesting Production Access

The sandbox is the gate, and knowing exactly what it restricts — and what the escape process asks of you — is the difference between a smooth approval and a rejected request followed by a second attempt days later.

What the sandbox restricts

All new SES accounts start in the sandbox, per-region. While sandboxed:

• You can only send to verified email addresses and domains — or to the SES mailbox simulator for testing. This is the restriction that makes the sandbox feel like a cage: your application cannot email an actual customer.
• Maximum 200 messages per 24-hour period.
• Maximum 1 message per second.
• Sending authorization delegates are under the same restriction.
• Account-level suppression list bulk actions are disabled.

You can use every SES feature inside the sandbox — the API, SMTP, DKIM, templates, the mailbox simulator. What is restricted is scale and audience, not capability.

The production access request, step by step

1. Open the SES console (console.aws.amazon.com/ses).
2. In the navigation panel, choose Account dashboard.
3. In the sandbox warning box at the top, choose View Get set up page, then Request production access.
4. Select the radio button that best describes the majority of your mail: Marketing (one-to-many, promotional content) or Transactional (one-to-one, triggered by user action).
5. In Website URL, enter the URL of your website — this helps AWS understand the kind of content you plan to send.
6. In Additional contacts, provide up to 4 email addresses for account communications.
7. Choose your preferred contact language (English or Japanese).
8. In Acknowledgement, check the box confirming you will only send email to individuals who have explicitly requested it, and that you have a process for handling bounce and complaint notifications.
9. Choose Submit request.

The AWS Support team provides an initial response within 24 hours. Approval is not guaranteed — AWS reserves the right to decline requests whose use cases do not align with their policies.

What gets requests approved (and what gets them rejected)

• A real website at the URL you provide — not a parked domain or a placeholder. AWS checks.
• A clear description of your use case — "transactional order confirmations for our e-commerce store at [URL], approximately 5,000 per day" is a request AWS can evaluate. "We need to send lots of emails" is not.
• Realistic volume estimates — inflated numbers that do not match a brand-new account raise flags.
• The bounce and complaint handling acknowledgment — you need a genuine process: SNS notifications routed somewhere you will actually see them, and a plan to remove bouncing addresses from your list.

What gets requests rejected or delayed: vague use cases, websites with no email-related purpose, volume claims wildly disproportionate to the account's apparent maturity, and any hint of purchased or scraped lists.

The EC2 port 25 detail

One trap documented in the SES setup path: if you are sending email from an Amazon EC2 instance through the SMTP interface, port 25 (the standard SMTP port) is throttled by default on EC2. The fix is a separate request to AWS Support to remove the port 25 throttle — or, the simpler route, connect on an alternative port (587 or 2587 for STARTTLS) which SES supports without the throttle.

AWS SES Pricing: $0.10 per 1,000 Emails ($0.0001 per Email)

SES pricing is pay-as-you-go based on email volume — no contracts, no upfront commitments. The headline: $0.10 per 1,000 emails on the à la carte plan, which works out to $0.0001 per email. A million emails costs $100. Ten million costs $1,000. That is the arithmetic that makes SES "email your app can afford."

But the full pricing picture has two models now, plus a tail of additional charges worth knowing:

The new pricing plans (introduced 2026)

SES now offers three bundled plans — Essentials, Pro, and Enterprise — that package sending with deliverability features:

The plans include Virtual Deliverability Manager, dedicated IPs (managed, on Pro and above), email validation, and other deliverability features that cost extra on à la carte. New SES accounts start on the Essentials plan as of July 21, 2026 — but you can switch to à la carte at any time.

À la carte pricing (the classic model)

• Outbound email: $0.10 per 1,000 emails.
• Attachments: $0.12 per GB of attachment data sent.
• Inbound email: $0.10 per 1,000 received, plus $0.09 per 1,000 incoming email chunks when processed through Mail Manager.
• Dedicated IP addresses: $24.95 per month per IP (standard); $15/month per account plus a per-email fee (managed).
• Virtual Deliverability Manager: per-email fees starting at $0.07/1,000, plus query fees.
• Email Validation: $0.01 per validation.

A real cost comparison

100,000 emails per month — a mid-sized newsletter or a busy e-commerce site's transactional volume:

• SES à la carte: $10.00 in sending fees. Total: about $10/month.
• SES Essentials plan: $16.00 in sending fees, with deliverability features included.
• A typical full-service ESP at ~$10 per 1,000: $1,000/month for the same volume.

That two-orders-of-magnitude gap is the entire pitch. For budgeting at larger volumes, the AWS Pricing Calculator includes SES — search for "Simple Email Service" in the calculator and model your expected volume against the tiered rates.

SES Rate Limits and Sending Quotas: How They Grow

Out of the sandbox, your account has two sending quotas per region:

• Sending quota: the maximum number of emails per 24-hour period. Default out of the sandbox starts at 200 per 24 hours and 1 per second.
• Sending rate: the maximum emails per second SES will accept.

One counting subtlety: quotas are based on recipients, not messages. An email with 10 recipients counts as 10 against your quota. The documented recommendation is to call SendEmail once per recipient rather than sending to multiple recipients in a single call — if a multi-recipient call fails, the entire email is rejected.

How quotas grow: automatically, if you behave

The remarkable part of SES quota growth is that AWS often increases it before you need to ask. The documented conditions:

1. You send high-quality content that recipients want to receive — and you stop sending to customers who do not open.
2. You send actual production content — not test messages, not internal-only traffic.
3. You send near your current quota — daily volume should regularly approach the maximum without exceeding it.
4. You have low bounce and complaint rates — high bounces and complaints hurt your quotas and your deliverability.

When automatic growth is not keeping pace, request quota increases through the AWS Service Quotas console: open it, select the region, navigate to AWS services → Amazon Simple Email Service (SES), choose the quota, and follow the directions. The documented SLA is up to 24 hours.

The SES Suppression List: Your Bounce Firewall

SES maintains a suppression list — a list of email addresses that SES refuses to deliver to, because those addresses have previously hard-bounced or generated complaints. When you try to send to a suppressed address, SES rejects the send without attempting delivery, protecting your bounce rate and your sender reputation.

How it works in practice:

• Account-level suppression list — SES automatically adds addresses that hard-bounce (permanent failures like nonexistent mailboxes) to this list. Once on it, future sends to that address are blocked.
• You can also manually add addresses to the suppression list — useful for known-bad addresses from other systems.
• You can remove addresses if they were added in error (for example, a mailbox was temporarily full and has since been fixed).
• In the sandbox, suppression list bulk actions and API calls are disabled — another reason the sandbox feels restrictive.

The suppression list is your friend: it is SES automatically doing the list hygiene that would otherwise be your job. Let it work. If you are migrating from another email service, export your known-bouncing addresses and add them to the SES suppression list proactively — starting clean is easier than recovering from a bounce-rate problem.

SES Error Codes: What the Errors Actually Mean

When SES rejects a send or an operation fails, the error carries a code. Here are the ones you will actually see:

For SMTP connections, errors arrive as standard SMTP response codes (5xx for permanent failures, 4xx for temporary) with SES-specific messages in the response text. The full error-code list is in the SES documentation under "Email sending errors."

The Deliverability Toolkit: VDM, Dedicated IPs, and Email Validation

Getting email into inboxes — not spam folders — is the persistent challenge of bulk sending, and SES provides a growing toolkit:

Virtual Deliverability Manager (VDM) is the umbrella: a set of deliverability analytics and optimizations. The SES-deliverability tier includes engagement tracking, advice, and automatic optimizations; the Global-deliverability tier adds campaign analytics, inbox placement tests, and blocklist monitoring.

Dedicated IP addresses isolate your sender reputation from other SES customers. On shared infrastructure (the default), your reputation is influenced by the aggregate behavior of everyone sharing the IPs; with dedicated IPs, you own your reputation entirely. Standard dedicated IPs are $24.95/month each; managed dedicated IPs (included in the Pro and Enterprise plans) add AWS-managed warmup and pooling. The trade: dedicated IPs start with no reputation and must be warmed up by gradually increasing volume.

Email Validation checks whether an address is deliverable before you send to it — catching typos, disposable addresses, and known-bad mailboxes at $0.01 per validation. The Auto Validation variant checks addresses at $0.01 per 1,000 as part of the sending flow.

Configuration sets tie it together: per-sending-event routing of metrics and notifications to CloudWatch, SNS, Firehose, or Kinesis — so your application can react to bounces, complaints, opens, and clicks programmatically.

Can SES Receive Email? Yes — and Nobody Talks About It

Everyone knows SES sends. Fewer know it receives — and the inbound capability enables architectures that pure outbound services cannot touch.

The mechanism: you point your domain's MX records at SES, and SES accepts email sent to that domain. From there, the Mail Manager layer routes it: rules can store received email in an S3 bucket, trigger a Lambda function with the parsed message, publish to an SNS topic, or relay to another destination.

What that enables, per the documentation:

• Email autoresponders — incoming mail triggers a Lambda function that sends a reply.
• Unsubscribe systems — unsubscribe requests arrive by email and are processed automatically.
• Customer support ticket generation — support@ emails become tickets in your system, with the parsed content attached.
• Mail archiving — inbound email stored in S3, optionally encrypted with KMS, as a durable record.

Inbound pricing: $0.10 per 1,000 emails received, plus $0.09 per 1,000 incoming chunks processed by Mail Manager rules — cents at the scale most inbound use cases operate.

SES vs. SendGrid, Mailgun, Postmark, and Resend: The Honest Comparison

The email-sending market has a spectrum: SES at the infrastructure end, full-service marketing platforms at the other, and API-first services (SendGrid, Mailgun, Postmark, Resend) in the middle:

The honest recommendation: if your application runs on AWS and sends transactional email, SES is nearly always the right answer — the price is unbeatable, the integration is native, and transactional email needs exactly the infrastructure SES provides. Resend specifically has gained traction as a developer-friendly SES alternative with a generous free tier, but at scale the pricing math still favors SES by a wide margin.

When SES Is the Wrong Choice (The Honest Section)

You need a marketing platform, not email infrastructure

If the request is "we need to design newsletters, segment our list, run A/B tests, and see campaign analytics in a dashboard" — and there is no engineering capacity to build that on SES — the bundled platforms are the honest answer.

Your team has no one to own deliverability

SES gives you the tools — DKIM, SPF, DMARC, VDM, dedicated IPs — but someone has to configure and monitor them. On a team with zero email-operations capacity, a managed service that handles authentication and reputation behind the scenes may cost more and deliver less friction.

You are sending cold outreach or purchased lists

Do not. Beyond being against SES's acceptable-use policy, cold email to unengaged recipients produces the bounces and complaints that get your account throttled and your emails filtered.

Troubleshooting: When SES Is Not Working

Problem 1: Email lands in spam despite DKIM/SPF/DMARC being set

Cause: Authentication is necessary but not sufficient — inbox providers also weigh sender reputation, engagement history, and content. A brand-new domain with no sending history starts with neutral reputation.

Fix: Warm up your sending: start with low volume to engaged recipients and gradually increase. Monitor VDM's engagement metrics.

Problem 2: Bounce rate suddenly spikes

Cause: A stale list, or a batch of invalid addresses from a new source.

Fix: Configure SNS bounce notifications to something you actually monitor, remove hard-bounced addresses immediately, and use Email Validation before sending to new or old lists.

Problem 3: SMTP connection fails from EC2

Cause: The EC2 port 25 throttle.

Fix: Connect on port 587 or 2587 (STARTTLS), which SES supports without the throttle.

Problem 4: DKIM verification fails — domain stays pending

Cause: The CNAME records are wrong, not propagated, or duplicated.

Fix: Verify the exact record values in the SES console against what is actually published in DNS. Common errors: trailing periods in the hostname, copying only part of the value, or adding the records to the wrong zone.

Problem 5: Production access request rejected

Cause: The request did not make the case.

Fix: Address the specific feedback, then resubmit with a clearer, more specific request. Verify your domain first.

Problem 6: "Is AWS SES down?" — checking for outages

When email suddenly stops sending and your configuration is unchanged, check the AWS Health Dashboard (health.aws.amazon.com) for SES service events in your region before assuming your configuration broke. Regional SES incidents happen — elevated error rates, delayed processing — and during those windows, retries and patience are the fix. CloudWatch metrics for SES (if you have them configured) will show the anomaly at the same timestamp as the health dashboard event, confirming the platform-side cause.

Frequently Asked Questions

What is AWS SES?

Amazon SES (Simple Email Service) is AWS's email-sending platform. It lets you send and receive email using your own addresses and domains — transactional email like order confirmations, marketing email like newsletters, and inbound processing like autoresponders — through an API or SMTP interface.

What is the full form of AWS SES?

Simple Email Service. The name is literal — it is a service for sending email, kept simple by handling the infrastructure (servers, IP reputation, bounce processing) while you handle the content and recipients.

Is AWS SES free?

No — SES has no free tier for email sending. You pay $0.10 per 1,000 emails ($0.0001 per email) from the first message on à la carte pricing. The sandbox lets you test at no cost to verified recipients, but production sending is billed from email one.

How much does AWS SES cost?

$0.10 per 1,000 emails on à la carte pricing — $0.0001 per email. The bundled plans (Essentials, Pro, Enterprise) charge $0.11-$0.23 per 1,000 depending on plan and volume tier, but include deliverability features. Attachments add $0.12 per GB.

What is the difference between AWS SES and SNS?

SES is an email platform — it sends and receives actual email with authentication, bounce handling, and deliverability tools. SNS is a notification service — it publishes messages to subscribers via multiple protocols (push, SMS, simple email, Lambda, SQS). Use SES when your application sends email to users; use SNS when you need to fan out event notifications to multiple systems or people.

Can AWS SES receive email?

Yes. Point your domain's MX records at SES, and Mail Manager rules route inbound email to S3 storage, Lambda triggers, SNS topics, or other destinations. This enables autoresponders, unsubscribe systems, and support-ticket applications.

What is the SES sandbox and how do I get out of it?

Every new SES account starts in the sandbox: 200 emails per day, 1 per second, and only to verified addresses. To escape, request production access from the SES console (Account dashboard → Request production access) with your use case, website URL, and contact information. AWS responds within 24 hours. Verifying your domain first speeds approval.

Does SES work with SMTP?

Yes — SES provides a standard SMTP interface. Generate SES-specific SMTP credentials, point your application at the SES SMTP endpoint, and send. Ports 587 and 2587 use STARTTLS and avoid the EC2 port 25 throttle.

How do I set up DKIM in SES?

Use Easy DKIM: verify your domain in SES, add the three CNAME records SES generates to your DNS, and SES automatically signs every email sent through that domain. No code changes needed.

What is the SES sending limit?

Default out of sandbox: 200 emails per 24 hours, 1 per second, per region. Quotas grow automatically when you send high-quality email near your limit with low bounce rates, or request increases through the Service Quotas console (24-hour SLA).

What is the SES suppression list?

A list of email addresses SES refuses to deliver to, because they previously hard-bounced or generated complaints. SES adds addresses automatically on hard bounces; you can also add and remove addresses manually. It protects your bounce rate and sender reputation.

Why are my SES emails going to spam?

Common causes: incomplete DKIM/SPF/DMARC authentication, a new domain with no sending reputation, high bounce or complaint rates, or spam-trigger content. Fix authentication first, then warm up volume gradually.

Is AWS SES down? How do I check?

Check the AWS Health Dashboard (health.aws.amazon.com) for SES service events in your region. If SES is having a regional incident, retries and patience are the fix — your configuration is fine. If the health dashboard is clear, the problem is on your side (credentials, permissions, network).

What is Virtual Deliverability Manager in SES?

A set of deliverability analytics and optimization tools: a health dashboard, an advisor flagging issues, engagement tracking, and (on the Global tier) campaign analytics and inbox placement tests. Included in Pro and Enterprise plans.

Can I use SES without AWS?

You need an AWS account to use SES, but your application does not need to run on AWS. The SMTP interface works from any server anywhere, and the API is reachable over the public internet.

What are the best alternatives to AWS SES?

For API-first email: SendGrid, Mailgun, Postmark, and Resend (newer, developer-friendly). For full marketing platforms: Mailchimp, HubSpot. For Azure: Azure Communication Services. For GCP: there is no direct equivalent — most GCP users integrate SES or a third-party service.

Wrapping Up: The Pipes, Cheaper Than You Thought

Amazon SES is email infrastructure at infrastructure prices — the sending and receiving platform behind an API, backed by the reputation Amazon built sending billions of its own emails, at $0.10 per thousand where the bundled platforms charge $5-$50 for the same volume. The trade is that you bring the engineering: the templates, the list management, the deliverability monitoring are yours to build or buy.

The three things to take away: first, the sandbox is the gate — plan for the production access request, verify your domain first, and make the case honestly. Second, authentication is the foundation — Easy DKIM plus SPF plus DMARC are three DNS configurations that decide whether your email arrives. Third, the limits grow with you — send well, near your quota, with clean lists, and AWS raises your ceiling before you ask.

If this is your first step into AWS services and the ecosystem feels vast, it is — and that is exactly why the free plain-English AWS series on this site exists: every core service explained in the order that makes sense, with prices included, so you build vocabulary before you build architecture.

Jake wired the repair shop's invoice system to SES one weekend — order confirmations to customers, restock alerts to himself — and got dinged by the sandbox on day one when he tried to email a customer whose address was not verified. Ethan's verdict: "The gate exists because AWS is protecting the reputation you are about to benefit from. Prove you belong, and the same infrastructure that sends Amazon's order confirmations sends yours — for about a nickel a week."

Revision note. Written September 2026, covering Amazon SES. If you just learned that the email your application sends can cost a tenth of what you are paying — and that the only gate between you and that price is an honest conversation with AWS about what you send — that knowledge is worth more than the migration it motivates, and the fact that you read the fine print before the first bill puts you ahead of every team discovering the sandbox on launch day.Happy learning!