AWS SES – email capture and forwarding

SES Rules for Receiving Emails

If we are using SES to receive emails, (rather than a 3rd party) we use the SES console (Oregon region for Australia) and configure “Email receiving” rules.

Go to SES > Configuration > Email receiving and click on default-rule-set. Click on “Create rule”.

You can click on the default-rule-set at any time later to edit or disable rules.

The diagram below shows how we make a rule to capture admin@mydomain.com. We can add other addresses as well. Or, we can use the domain name to capture any addresses. The rule is given any name. We use the pop-down menu as shown to choose an existing S3 bucket to put the emails into, or better still, we request the menu to create a new bucket for us, which will choose Oregon, and set the bucket permissions correctly for our account. If you previously created a bucket, as per our prior notes, you would have to have added the permissions manually. As a note, later when we add Lambda functions to the same rule, (to check for spam and do forwarding) it will ask us to grant permissions to those functions, so we say yes.

Here is an example where I chose an existing bucket, but it would have been better to let SES create a bucket.

The diagram shows “Object key prefix – optional”. This is where you can request emails go into a sub-folder. For instance, you could say “.ses/” with the forward slash. I use “.ses/” as a hidden directory as I also run crontab shell scripts that process the emails for archiving in a more complex manner where I found it helpful to have hidden directories. I’ll add this scripting elsewhere as an optional tool. My Lambda scripts also make use of my nominated .ses sub-folder.

Add and test an email

We now add an email address and test it. It is helpful to add admin@mydomain.com. Our previous example uses this address.

As we are in sandbox mode, create the email address identity, then go to the S3 bucket and see if the email is there (or in the sub-directory nominated).

The domain identity must be verified and not in a pending state. I can’t go into problem solving here, but if an issue, check your spelling and completeness of records in your DNS, and confirm they are seen in the dns checker website. Amazon must also have sent yu an email saying the domain and dmarc is verified. If things get really our of whack (whatever that is) you can delete the domain and re-add it.

Assuming all is ok:

Go to SES (Oregon) > Configuration > Identities > “Create identity” to create an identity.

Click on the email button rather than the domain button.

Do not add a new “Mail From domain” or any other records on the summary screen. Simply add admin@mydomain.com

The SES identity page will then show the address is pending. This is where we now check the S3 bucket. You can download the email and extract the verification URL or add .eml to the filename and open it in your PC browser.

If it is not in the bucket, check all your configurations. There is no error logging at this point. We can check for errors in the Lambda functions that we add later, but not as to whether an email goes into the bucket or not.

If the email is present, click on download up the top of the page. This admin@ address is particularly important when you need to get an email received for a paid SSL.

We still cannot send other email addresses to SES from your PC email client as we are in sandbox mode. You could add other addresses if you wish to have those in your testing.

Next we add Lambda functions (Oregon) to forward emails. The address(es) you forward to must be verified as an email identity as well, due to sandbox mode, so please add those now. For instance me@gmail.com