Amazon SES Basics

Last chapter you sent email through a service that was built to be friendly. This one's about Amazon SES, the email building block that Amazon Web Services (AWS) offers, and what changes when you work one level closer to the raw plumbing.

What Amazon SES Is#

Amazon SES stands for Amazon Simple Email Service. AWS describes it as "an email platform that provides an easy, cost-effective way for you to send and receive email using your own email addresses and domains."

You can use it for the same kinds of email your app already needs, like order confirmations, password resets and newsletters. It can also receive email, which lets developers build things like autoresponders or support ticket systems out of incoming messages.

The big word here is building block. SES is one service inside AWS, and it's designed to plug into other AWS services. Bounce and complaint notifications can flow into Amazon SNS. Access is controlled through AWS Identity and Access Management, usually shortened to IAM. Sending events can get published to Amazon CloudWatch. That flexibility is the whole point of SES... and it's also why there's more to set up.

How SES Differs From Friendlier Email Services#

A developer-focused email service tries to hide the moving parts. You sign up, add a domain, copy an API key and send. SES hands you more of those parts directly.

Here's what you take on with SES that a friendlier service usually handles for you.

Area	What SES expects from you
Account	An AWS account, which covers far more than email
Access	IAM credentials instead of a single API key
Location	Picking an AWS Region and setting things up inside it
Starting limits	Getting your account out of the sandbox before you can email real users
Feedback	Handling bounce and complaint notifications yourself

None of it is hard once you've done it once. It's just MORE steps, and they're scattered across a bunch of AWS screens instead of one dashboard.

The Sandbox#

Every new SES account starts out in what AWS calls the sandbox. It exists, in AWS's words, "to help prevent fraud and abuse, and to help protect your reputation as a sender."

While your account is in the sandbox you can use every SES feature, but the official sandbox page lists these restrictions.

• You can only send mail to verified email addresses and domains, or to the Amazon SES mailbox simulator.
• You can send a maximum of 200 messages per 24-hour period.
• You can send a maximum of 1 message per second.
• For sending authorization, neither you nor the delegate sender can send email to non-verified email addresses.
• For account-level suppression, bulk actions and SES API calls related to suppression list management are disabled.

That first rule is the one that catches beginners off guard. In the sandbox you can't email your real users AT ALL, only addresses you've proven you own. It's a safe spot to test, and launching from it just isn't possible.

Requesting Production Access#

To email anybody, you ask AWS to move your account out of the sandbox and into production. You do that from the SES console by opening the account dashboard, heading to the Get set up page and choosing Request production access.

The form asks you a few things.

Step 1. Pick Your Mail Type#

Choose Marketing or Transactional, whichever describes most of the mail you'll send. Transactional means one-to-one messages triggered by something the user did, like a password reset.

Step 2. Add Your Website#

Enter your website URL so AWS can get a feel for what kind of content you plan to send.

Step 3. Confirm How You Will Behave#

You tick a box agreeing to only email people who explicitly asked for it, and confirming you've got a process for handling bounce and complaint notifications.

Step 4. Wait for Review#

AWS says its support team "provides an initial response to your request within 24 hours." If they need more info it can take longer. AWS also points out that verifying your domain first is a best practice that helps your request get approved faster.

Even after you're out of the sandbox, every address you send from still has to be verified. Production access only removes the limit on who you can send TO.

Regions#

AWS runs its services in lots of Regions, which are physical locations around the world with codes like us-east-1 or eu-west-1. SES is available in a long list of them, shown on the SES endpoints page.

For SES, the Region matters more than you'd expect.

• Your identities live in one Region. AWS says that to send from the same domain or address in more than one Region, "you must create and verify a separate identity for each Region."
• The sandbox status is separate in each Region.
• Your code has to talk to the same Region where you set everything up.

The simple beginner rule? Pick one Region and do everything there.

What It Costs#

AWS says that with SES "you pay based on the volume of emails sent and received." The SES pricing page lists the current rates and plans.

That page lists pay as you go pricing alongside several monthly plans, and it describes AWS Free Tier credits that new AWS customers can put toward SES. The plans changed recently, so we won't quote numbers here.

When to Pick SES#

SES is a good fit in these situations.

• Your app already runs on AWS, or you're comfortable in the AWS console.
• You expect to send a LOT of email and want per-email pricing from AWS.
• You want to wire email into other AWS services, like SNS for bounce notifications.

A friendlier service is often the better first pick in these cases.

• You want to send your first email today with as few steps as possible.
• You don't have an AWS account, or you don't want one.
• You'd rather not babysit IAM credentials, Regions and the sandbox.

There's no wrong answer here. Plenty of apps start on a friendly service and move to SES later, once the volume or the AWS setup makes the extra work worth it.

TL;DR#

• Amazon SES is an AWS building block for sending and receiving email with your own domains.
• It asks you to handle more yourself, including IAM credentials, Regions and bounce handling.
• New accounts start in the sandbox, where you can only send to verified addresses and the documented daily and per-second limits apply.
• You leave the sandbox by requesting production access, and AWS gives an initial response within 24 hours.
• Identities and sandbox status are separate in each Region, so pick one Region and stay there.
• Pricing is based on volume. Check the official pricing page for current rates and plans.

What's Next?#

In the next lesson you'll verify a domain, set up DKIM, SPF and DMARC, create safe credentials and send your very first email from Node.