Transactional mail with AWS Simple Email Service

Why Choose AWS SES?

AWS SES is not only cost-effective—with no monthly fees and charges of roughly 10 cents per thousand messages after the first 3,000 free emails each month—but it also integrates seamlessly with other AWS services, enhancing security and simplifying operations. This integration is particularly beneficial if you’re already using AWS for other services, keeping all your operations streamlined and under one roof.

Setting Up AWS SES for Transactional Mail

As we’re focusing here on transactional mail, we won’t be looking at most of the features, such as templating, as we purely want to send messages from applications.

Getting started is simple:

• Create a New Identity: Go to the SES section in your AWS console to create a new identity for your domain.
• Verify with DKIM: ou will receive DKIM keys to add to your DNS records. This step is essential as it authenticates AWS’s authority to send emails on behalf of your domain and confirms your authorization to use SES for this domain.
• Sandbox Environment: Initially, your account will be in a sandbox environment, allowing you to test SES functionalities without accidentally sending emails to external addresses.

Using SES with SMTP

Simple Mail Transfer Protocol (SMTP) is the standard protocol for sending and receiving emails.

1. Setup SMTP Connection: The SMTP connection settings are consistent across all accounts but vary by region.
2. Create SMTP Credentials: Click on “Create SMTP credentials” in your SES console, which leads to the creation of an IAM user with a specific policy for email sending:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "ses:SendRawEmail",
         "Resource": "*"
       }
     ]
   }

3. Access Keys You will then receive a username and password for SMTP, which correspond to the IAM user’s Access Key ID and Secret Access Key.

Enhancing Security

Rotating Keys Under the hood the SMTP user a standard IAM user, with the policy you specified, and a pre-generated access key.
The Access Key Id is the username for smtp, the password is the secret access key - knowing this you can rotate these your self later as needed.

Restricting identities to send from
The default policy above allows the user to send email with SES on any resource. This user can send mail on behalf of any of the identities you configured, this is probably not what you want.
Specifying the identity is obvious, just specify the resource(s)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ses:SendRawEmail",
      "Resource": "arn:aws:ses:us-east-1:123456789:identity/my-identity"
    }
  ]
}

Restricting sender address
What we can also do is lock down the sending address.
This is particularly useful when sending on behalf of domains which are also used for other purposes (for example staff email addresses), it prevents those credentials for being used to send from anything other than the whitelisted addresses.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ses:SendRawEmail",
      "Resource": "arn:aws:ses:us-east-1:123456789:identity/my-identity",
      "Condition": {
        "StringEquals": {
          "ses:FromAddress": "no-reply@example.com"
        }
      }
    }
  ]
}

There are other conditions you can filter on, for example Sender Name, or recipients - see them all here.