Amazon Simple Email Service
Developer Guide

Considering Your Use Case for Amazon SES Email Receiving

Before you set up Amazon SES to receive your mail, you might find it helpful to consider the following questions.

Email Content

How do you want Amazon SES to pass you the email content?

Amazon SES can provide you the email content in two ways: it can store the emails in an Amazon S3 bucket that you specify, or it can send you an Amazon SNS notification that contains a copy of the email. Amazon SES delivers you the raw, unmodified email in Multipurpose Internet Mail Extensions (MIME) format. For more information about MIME format, see RFC 2045.

How large of a limit on email size do you need?

If you choose to store emails in an Amazon S3 bucket, the maximum email size (including headers) is 30 MB. If you choose to receive your emails through Amazon SNS notifications, the maximum email size (including headers) is 150 KB.

How do you want to trigger the processing of your mail?

After your mail is delivered, you will want to process it with your own code. For example, your application might convert the base 64-encoded email into a displayable format and then make it available to an end user through an email client. There are a couple of ways you can start the process:

  • If your emails are delivered to Amazon S3, your application can listen for Amazon SNS notifications generated by S3 actions, extract the message ID of the email from the notifications, and then use the message ID to retrieve the email from Amazon S3.

    Alternatively, you can incorporate email processing into your receipt rules by writing a Lambda function. In this case, your receipt rule should first write the email to Amazon S3, and then trigger the Lambda function. Lambda actions can be executed synchronously or asynchronously from within your receipt rules, depending on whether the Lambda function needs to return a result that influences how other actions are executed. We recommend that you use asynchronous execution unless synchronous is absolutely necessary for your use case. For more information about AWS Lambda, see the AWS Lambda Developer Guide.

  • If your emails are delivered through an Amazon SNS notification by using the SNS action, your application can listen for Amazon SNS notifications, and then extract the email messages from the notifications.

Do you want the emails to be encrypted?

Amazon SES integrates with AWS Key Management Service (AWS KMS) to optionally encrypt the mail it writes to your Amazon S3 bucket. Amazon SES uses client-side encryption to encrypt your mail before writing it to Amazon S3. This means that you must decrypt the content on your side after retrieving the mail from Amazon S3. The AWS SDK for Java and AWS SDK for Ruby provide a client that can handle the decryption for you. Amazon SES can encrypt the emails for you only if you choose for your emails to be delivered to an Amazon S3 bucket.

Unwanted Mail

At what point in the email-receiving process do you want to reject unwanted mail?

When a sender tries to send an email to a recipient, the sender's email server exchanges a sequence of commands with the recipient's server. This sequence is called the SMTP conversation.

You can reject incoming email at two points in the email receiving process: during the SMTP conversation, and after the SMTP conversation. You use IP address filters to reject messages during the SMTP conversation, and receipt rules to reject emails after the SMTP conversation.

You can use IP address filters to reject email that originates from specific IP addresses. The benefit of using IP address filters to reject unwanted mail is that we don't charge you for messages that are rejected during the SMTP conversation. The drawback to using IP address filters is that they reject email from the IP addresses you specify without performing any analysis on the actual content of the messages. For more information about IP address filters, see Creating IP Address Filters for Amazon SES Email Receiving.

You can use receipt rules to send a bounce notification to the sender of an email based on the address (or domain, or subdomain) that the message was sent to. The benefit of using receipt rules is that you can perform additional analysis on incoming messages before you send a bounce notification to the sender. For example, you can use AWS Lambda to send bounce notifications only when messages fail DKIM authentication or are identified as spam. The drawback to using receipt rules is that, because receipt rules are processed after the SMTP conversation, we bill you for each message that you receive. You might also be charged if you use Lambda to analyze the content of incoming messages. For more information about receipt rules, see Creating Receipt Rules for Amazon SES Email Receiving. For more information about using Lambda to analyze incoming email, see Lambda Function Examples.

Using Other AWS Services

Have you set up the appropriate permissions?

If you want your mail to be delivered to an Amazon S3 bucket, published to an Amazon SNS topic you don't own, trigger a Lambda function, or use a custom master AWS KMS key, you need to give Amazon SES permission to access those resources. To give Amazon SES access, you create policies on resources from the consoles or APIs for those AWS services. For more information Giving Permissions.

Mail Streams

How do you want to divide your mail stream?

Your domain most likely receives different classes of mail. For example, some of your domain's mail, such as an email to user@example.com, might be intended for a personal inbox. Other mail, such as an email to unsubscribe@example.com, might be better directed to automated systems instead. You can use receipt rules to divide your incoming mail so that it can be processed differently. For information about how to set up receipt rules, see Creating Receipt Rules.