Amazon SES email receiving concepts and use cases

When you use Amazon SES as your email receiver, you tell the service what to do with your mail. The primary method, receipt rules, gives you fine-grained control over your email receiving by utilizing recipient-based control to specify a set of actions to take based on the recipient. The other method, IP address filters, provides a broad level of IP-based control to block or allow mail based on the originating IP address or range of addresses.

Both of these methods are described in this section along with an overview of how Amazon SES processes received email, and use cases to help you consider how you want to receive, filter, and process your email when setting up rules and filters.

Recipient-based control using receipt rules

The primary way to control your incoming mail is to specify how mail is handled through an ordered list of actions for any of your verified identities which includes domains, sub-domains, or email addresses - note that email addresses have to belong to one of your verified domain identities. These actions are defined and ordered in receipt rules that you create within a rule set.

As an option, you can also add recipient conditions as a way to specify that the actions only be taken if the recipient to whom the incoming mail is addressed matches a recipient identity specified in the condition. For example, if you own example.com, you can specify that mail for user@example.com should bounce, and that all other mail for example.com and its subdomains should be delivered.

Otherwise, if you do not add any recipient conditions, the actions will be applied to everything - all email addresses, domains, and sub-domains that belong to your verified domains. The following actions are available to be applied to your receipt rules:

Receipt rules are grouped together into rule sets. If you don't have an existing rule set, you'll first have to create a rule set before you start creating receipt rules. You can define multiple rule sets for your AWS account, but only one rule set is active at any time. The following figure shows how receipt rules, rule sets, and actions relate to each other.

IP-based control using IP address filters

You can control your mail flow by setting up IP address filters. IP address filters are optional and enable you to specify whether to accept or block mail originating from an IP address or range of IP addresses. Your IP address filters can include block lists (IP addresses from which you want to block incoming mail) and allow lists (IP addresses from which you want to always accept mail).

IP address filters are useful for blocking spam. Amazon SES maintains its own block list of IP addresses known to send spam including those listed in Spamhaus. However, you can choose to receive mail from those IP addresses by adding them to your allow list. Since there are no logs that show which IP addresses are being blocked, the sender who is being blocked will need to inform you. This is also a good opportunity to help the sender determine if their IP address is on a block list, such as Spamhaus, and recommend they request to be unlisted. Doing so will be beneficial to both you and the sender in that you won't have to maintain an IP address filter for them and they will improve their email deliverability.

Email-receiving process

When Amazon SES receives an email for your domain, the following events occur:

Use cases and restrictions for Amazon SES email receiving

This section goes over some general considerations and use cases for Amazon SES email receiving. Presented in question and answer format, are commonly asked questions and facts to help determine if it would be beneficial for using Amazon SES to receive and manage email on behalf of one or more of the verified domains that you own.

Regional availability

Does Amazon SES support email receiving in your Region?

Amazon SES only supports email receiving in certain AWS Regions. For a complete list of Regions where email receiving is supported, see Amazon Simple Email Service endpoints and quotas in the AWS General Reference.

POP or IMAP based email clients

Can Microsoft Outlook be used to receive incoming email?

Amazon SES doesn't include POP or IMAP servers for receiving incoming email. This means that you can't use an email client such as Microsoft Outlook to receive incoming email. If you need a solution that can both send and receive email by using an email client, consider using Amazon WorkMail.

Using other AWS services

Have you set up the appropriate permissions?

If you want your mail to be delivered to an S3 bucket, published to an Amazon SNS topic you don't own, trigger a Lambda function, or use a customer managed 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 permission.

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 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 are the emails that you'll be receiving?

If you store emails in an S3 bucket, the maximum email size (including headers) is 40 MB. If you 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:

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 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 S3 bucket.

Unwanted mail

At what point in the email-receiving process do you want to block 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 block 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 block messages during the SMTP conversation, and receipt rules to block emails after the SMTP conversation.

You can use IP address filters to block email that originates from specific IP addresses. The benefit of using IP address filters to block unwanted mail is that we don't charge you for messages that are blocked during the SMTP conversation. The drawback to using IP address filters is that they block 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 Create IP address filters console walkthrough.

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 console walkthrough. For more information about using Lambda to analyze incoming email, see Lambda function examples.

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.

Email-receiving authentication and malware scanning

Amazon SES authenticates each received email and optionally scans the email’s content for spam and malware. SES doesn’t take any actions on received email based on the results of the email authentication or content scanning; however, the results of these operations are provided to you as attributes that you can use in SES receipt rule actions such as Amazon SNS notifications or as headers in a message delivered to Amazon S3.

Email authentication

Amazon SES authenticates each received email using SPF, DKIM and DMARC. The results of each authentication mechanism is provided in the Amazon SNS notifications that SES dispatches as part of evaluating the rules in the active receipt rule set. In addition, if you chose to receive a copy of the email in Amazon S3, the result of the email authentication is captured in the Authentication-Results header that SES adds to the email’s header section:

Authentication-Results: example.com;
spf=pass (spfCheck: 10.0.0.1 is permitted by domain of example.com) client-ip=10.0.0.1; envelope-from=example@example.com; helo=10.0.0.1;
dkim=pass header.i=example.com;
dkim=permerror header.i=some-example.com;
dmarc=pass header.from=example@example.com;

The Authentication-Results header is described in RFC 8601

Email content scanning for spam and malware detection

Amazon SES scans received email content for malware depending of the value of the ScanEnabled (API) or Spam and virus scanning (console) attribute of the receipt rule that matched the email. By default SES scans received email content for malware. To disable content scanning for received emails that match a specific receipt rule, you would need to set the receipt rule’s ScanEnabled flag to false if using the API, or clear the Spam and virus scanning checkbox if using the console. If the receipt rule that matched an email is scan enabled, the result of the content scanning is provided in the Amazon SNS notifications that SES dispatches as part of evaluating the rules in the active receipt rule set. In addition, if you chose to receive a copy of the email in Amazon S3, the result of the content scanning is captured in the X-SES-Spam-Verdict and the X-SES-Virus-Verdict headers that SES adds to the email’s header section.

X-SES-Spam-Verdict: PASS
X-SES-Virus-Verdict: FAIL

The possible values for the headers above are listed in:

Now that you have an understanding of the email receiving concepts, how it works, and it's use cases, you can get started by going to Setting up email receiving.