Introducing the Amazon Simple Email Service

Like most technical endeavors, sending email is a lot harder than it looks! The simple solutions that are entirely adequate when you have to send a couple of dozen daily emails simply don't work when you need to send out hundreds, thousands, or even millions of emails over the same time period.

To pick just one issue, let's talk about something that the email pros call deliverability. This is a measure of how well you are doing at actually getting email through to the intended recipients. It is affected by a number of factors and is absolutely crucial to the successful implementation of your email strategy. In order to maximize deliverability, you need to work with multiple Internet Service Providers (ISPs) to ensure that they trust your content, and you need to monitor and control the number of complaints and bounces that you generate. After spending time and money building out an internal hardware platform, negotiating expensive agreements with third-party vendors, learning the ins and outs of SMTP, and becoming familiar with (not to mention gaining control of) all of the factors that affect deliverability, you may find yourself wondering why you wanted to send email in the first place. Amazon's Chris Wheeler (Technical Program Manager for Amazon SES and an industry recognized deliverability expert), told me "You must get your house in order before sending your first piece of mail. Otherwise, your mail will end up in the spam folder, may not be delivered at all, or you may be blocked from sending any more mail."

The new Amazon Simple Email Service (SES) will make it easy for you to send email with minimal setup and maximum scalability. Amazon SES is based on the scalable technology used by Amazon sites around the world to send billions of messages a year.

You'll be able to send email without having to worry about the undifferentiated heavy lifting of infrastructure management, configuring your hosts for optimal sending, and the like. Amazon SES also provides you with access to a number of metrics that will provide you with the feedback needed to tune your email strategy to maximize deliverability.

When you first register, you'll have access to the SES "sandbox" where you can send email only to addresses that you have verified. The verification process sends a confirmation email to the address to be verified; the recipient must click on a link embedded in the email in order to verify the address. You must also verify the email address (or addresses) that will be used to send messages. At this point, with verified addresses in hand, you can send up to 200 messages per day, at a maximum rate of 1 message per second. These limits will allow you to develop and test your application. This address verification process is intended to allow you to develop and debug your application in a controlled environment. It will also help to maintain your reputation as a sender of high quality email.

Once your application is up and running, the next step is to request production access using the SES Production Access Request Form. We'll review your request and generally contact you within 24 hours. Once granted production access, you will no longer have to verify the destination addresses and you'll be able to send email to any address. SES will begin to increase your daily sending quota and your maximum send rate based on a number of factors including the amount of email that you send, the number of rejections and bounces that occur, and the number of complaints that it generates. This will occur gradually over time as your activities provide evidence that you are using SES in a responsible manner. The combination of sandbox access, production access, and the gradual increase in quotas will allow us to help ensure high deliverability for all customers of SES. This is exactly the same process that bulk senders of email, including Amazon.com, use to “season” their sending channels.

Newly verified production accounts can send up to 1,000 emails every 24 hours. The SES team has told me that, while it might vary over time, with responsible use this quota currently can grow to 10,000 daily messages within 3 days and up to 1,000,000 daily messages within a couple of weeks. Similarly, the maximum send rate will start out at 1 email per second, and can rise to 10 per second within 3 days, and all the way to 90 per second within a couple of weeks. These increases are based on usage, and occur automatically as you start to approach your existing limits. You can contact us if you need to send more than 1,000,000 emails per day or at a rate in excess of 90 per second and we'll do our best to accommodate you.

The Simple Email Service will provide you with performance data on your email so that you can track your status and adjust your email sending model if necessary. SES will also provide you with valuable feedback from ISPs in the form of complaints from email recipients.

You can use SES by calling the SES APIs or from the command line. You can also configure your current Mail Transfer Agent to route your email through SES using the directions contained in the SES Developer Guide.

 The SES APIs are pretty simple:

• You use VerifyEmailAddress, ListVerifiedEmailAddresses, and DeleteVerifiedEmailAddress to manage the list of verified email addresses associated with your account.
• You use SendEmail to send properly formatted emails (supplying From, To, Subject and a message body) and SendRawEmail to manually compose and send more sophisticated emails which include additional headers or MIME data.
• You use GetSendQuota and GetSendStatistics to retrieve your sending quotas and your statistics (delivery attempts, rejects, bounces, and complaints).

You can read more about the APIs in the SES API Reference.

I'm confident that you will find SES to be easy to use and that it will save you a lot of time and a lot of headaches as you build and deploy your applications. As always, please feel free to leave me a comment with your thoughts (and plans) for SES.

By the way, if you are planning to use SES, you might also want to investigate Litmus.This AWS-powered email preview tool will let you see how your email will look when it is rendered by 34 separate email clients and devices including four versions of Lotus Notes and five versions of Microsoft Outlook. Litmus runs on Amazon EC2 and stores the rendered images on Amazon S3 (read the Litmus case study for more information).

-- Jeff;

PS - There's a secret message embedded within the SES "hero graphic" on the AWS home page! Can you figure out what it says? If you are having trouble reading it, use your browser's zoom function (press the Control and + keys on Firefox). If that isn't good enough for you, here's a slightly larger version of the graphic.

Comments

[Brian]

Congratulations, Jeff! You have made many developers happy today!

[Josh]

Seriously.
JAAAAAAAAAAAY!
We're implementing this right now. Didn't even read the whole announcement I just hope that this is what I am guessing from the headline. Postmarkapp from Amazon! Nice Job guys!!!!

[Arik Fraimovich]

Re. the secret message: if the secret message is in the binary code on the stamp, than it's too small to be readable... if the stamp is just a distraction, then clever move :)

[Shane]

I agree with Arik. I started with the first line and got .z^. Probably too small for me to read accurately, too. ;)

[Shane]

Indeed, I will take bacon any day over spam.

Thanks Jeff. :)

[Arik Fraimovich]

Bacon is indeed better than spam.
Ah, if I knew they are going to post a higher res image, I wouldn't gone out of my house for so long ;)

[Openid]

Can somebody write something will expose a basic SMTP interface to my EC2 instances and then talk to this new service so I don't have to integrate what is basically a custom email interface? My apps already talk to SMTP directly so this would be simple to integrate if I had the middle piece.

[Andy]

Will there be a capability to receive email in future? Something like Mailgun?

[Chris]

A HUGE shortcoming appears to be that SES generates actual bounced emails back to the sender. This is a problem for large lists-- we want the sender inbox to be clean for humans to handle replies only, and don't want to manually wade through hundreds of bounce messages. (large lists (250,000+) will generate hundreds of bounces just from email account churn week-to-week). Even worse, oftentimes a single bounced email generates several bounce messages as ISPs retry the email.

I see that we can set a ReturnPath value for bounces, but that still leaves me with an inbox somewhere full of non-standard bounce messages. Are we supposed to process this pile by hand? Is there any plan for an automated and standardized way of notifying an AWS account about a bounce? It would be great if SES could just send me a standardized notice, like hitting a callback URL on my site, or dropping a message to me in SQS, when an email bounces. Short of that, is there an API call that will return the actual bounce emails (and the associated bounce message) to me?

Thanks!

[peter honeyman]

011000010110001011110000011011100110111100100000011110100111101001111010

[Ben Meadowcroft]

reverse(rot13(bintochar(http://awsmedia.s3.amazonaws.com/ses_hero_lg.png)))

[Jeff Schneider]

Hey Jeff,
Like Beanstalk, I couldn't help but notice that there's no WSDL for SES - instead preferring the use of the "AWS Query" notation. Is this a longterm trend or coincidental?
Jeff

[JM]

Secret message? Here is what it said:
.zncf anug erggro fv abpno

[Rajeshj]

Jeff,

This is great. We send email using Java Mail API. Could you provide documentation (similar to the ones for sendmail and postfix) to integrate this with the Java Mail API?

[Mark]

Wonderful news! Finally we can stop using third party solutions and do it all under the AWS roof.

[Alex]

very cool, any plans on also extending the api for apps that what to handle incoming mails?

[Trillatext]

Are there any functions to remove bounces, rejects, etc..? Or at least retrieve the email that bounced so it can be removed?

[Mahesh Khambadkone]

Is there any information on how the service helps prevent your mails getting into user's Spam boxes, as compared to other services like SendGrid or AuthSMTP?

For example, easy handling of Do Not Mail requests from end users, getting the SMTP servers approved by the top mail providers' Postboxes like Yahoo and MSN?

[Jeff Barr]

Trillatext, those bounces and rejects will be returned to you via email (see the ReturnPath in the docs at http://docs.amazonwebservices.com/ses/latest/APIReference/API_SendEmail.html ).

[Jeff Barr]

Jeff, regarding WSDL, I am trying to find out what's going on.

[Trillatext]

Thanks and sorry. Lol, went through the documentation before asking and simply missed that

[Jeff Barr]

RajeshJ: The newest version of the AWS SDK for Java includes a JavaMail provider for SES. Read more at http://aws.amazon.com/sdkforjava/ .

[Rajeshj]

Thanks!

[Joe Negron]

Thanks, Jeff. I love all the new stuff you guys are releasing. I think I spoke with Tal about this when I was at your office. We've been using 3rd party tools and relaying through an external smtp. Hopefully this makes life easier. Now it's time to play with the new SDK...

[Pankratiev]

I've made Python API for Amazon SES http://tagmask.com/vladimir/posts/26