The Amazon SES team is pleased to announce that you can now use SES to receive email!
For the past four years, SES has strived to make your life easier by maintaining a fleet of SMTP servers ready to send mail when you want it. There's no need to worry about scaling, ensuring message delivery, or navigating relationships with countless email service providers.
However, you'd still need to manage a fleet of SMTP servers if you wanted to receive mail. As with sending mail, receiving mail comes with its own set of headaches: scaling for traffic spikes, blocking malicious senders, filtering out spam and viruses, and ultimately routing mail to your application, to name a few.
As of today, the SES team would like to invite you to say goodbye to these hassles, and rely on SES to simply receive your mail just as you rely on us to simply send your mail.
Why should I use SES to receive mail?
SES is ideally suited for servicing mail that is programmatically actionable. The following are a handful of common use cases that you can now leverage SES to solve:
- Automatically create support tickets from customer email.
- Implement an email auto-responder.
- Process email list unsubscribe requests.
- Process email bounces and complaints.
- Create an email archival solution.
- Update correspondence in tickets, forums, etc. by email.
- Receive files from customers via email.
You can also use SES to manage your organization's entire mail stream, directing mail destined to personal inboxes to Amazon WorkMail and processing customer service mail, etc. programmatically with SES.
How does it work?
Think of SES as an email gateway to the AWS ecosystem. After onboarding your domain onto SES, we will receive mail on your behalf, and allow you to consume it through a variety of different AWS services. For example, you can configure SES to deliver all of your mail to an Amazon S3 bucket, and process it directly using AWS Lambda.
SES empowers you to make decisions about how your mail is processed through the concept of a rule set. Every account that receives mail using SES has a single active rule set that you customize to dictate to SES what you'd like done with your mail across all of your SES-managed domains.
A rule set is simply an ordered list of rules, and a rule is a combination of a matching condition and an ordered list of actions. A condition is something like "All mail to firstname.lastname@example.org" or "All mail to example.com and all subdomains." Actions are things like "Encrypt my mail using my AWS KMS key, write it to my S3 bucket, and notify me of the delivery via Amazon SNS" or "Asynchronously execute my Lambda function that updates my mailing list based on unsubscribe emails" or "Send me a SNS notification containing the email." A more thorough discussion of rule sets, rules, and actions can be found in our developer guide.
Your rule set is sequentially evaluated for every message SES receives, and only the actions that apply to the message are executed. This enables you to write rules that route mail differently based on individual message characteristics. You can have a rule that drops mail that SES flags as spam across all of your domains, another that writes mail to a.example.com to one S3 bucket, another that writes mail to b.example.com to a different bucket and then executes a Lambda function but only when the email contains a specific header value, and so on.
The system was designed to be both highly customizable and convenient to use. Our goal is to minimize the amount of custom email routing or parsing logic that your application needs to do, and, if you capitalize on our Lambda integration, you may not even need an application at all!
How do I get started?
The best place to start is the SES developer guide. It provides detailed instructions on how to onboard a domain onto SES to receive mail, as well as walks you through the process of setting up rules to govern your mail flows. Then, head over to the SES console to set up your domains to begin receiving mail!