Amazon WorkMail can be used similarly to Microsoft Exchange or with the IMAP protocol. If you can use the former, use that one as it is faster and feels more reliable (I lost some emails while transferring between IMAP folders).
We need to add or create 4 things to start sending mail: an organization, users, aliases and domains.
Go to the WorkMail console. The first page you'll see shows a list of all your organizations. Click Add organization to add your first (or additional).
Choose Quick setup.
Enter your Organization name and click Create.
Now you can go to your organization by clicking the Alias.
In the WorkMail dashboard of your organization we start by adding a domain. This is the domain we registered or transferred in the previous part. Go to Domains in the menu and click the Add domain button.
Choose the domain by clicking in the Domain name text box. You can only choose domains that have a hosted zone in Route 53.
You will now get a list of DNS records you should add to your hosted zone. AWS will add them automatically, so after a few minutes they should all get the status
Verified. Refresh manually if necessary.
It can take a while, but in the mean time you can continue with the next steps. You can always come back to this screen by clicking the domain.
Go to users through the menu and Create user.
Enter the users name(s).
Create the email address, select the main domain and set an initial password.
Add address details, phone number, title and company
Read the AWS docs for configuration of your email client. At the moment of writing they have a manual for Microsoft Outlook (exchange), Mobile Devices (Android and iOS), Windows 10 Mail App, macOS Apps and IMAP clients.
We can now receive and manually send email. To send emails through our applications, we need to setup SES, the simple email service. SES gives us an SMTP address to send those emails through.
AWS has a lot of checks and limits in place to make it hard for people to use their service for sending spam. This is quite annoying sometimes, but it's understandable. It will filter out a lot of malicious people who would otherwise also ruin your reputation, by getting AWS' IP addresses grey- or blacklisted.
First we have to get our domain(s) verified. This will decrease the chance that our email will be send directly to a users spam folder. This is done by adding a few TXT-type records in your hosted zone. AWS will do it for you if you use Route 53.
Go to the SES dashboard. Click Domains in the menu and click the Verify a New Domain button.
Enter your domain, select the Generate DKIM option and click the Verify This Domain button.
A list of DNS records is shown to add to your hosted zone. If you use Route 53, you can have them entered automatically. Otherwise you have to copy them manually to your DNS. Remember you have to do this for every domain, so it can get quite tedious.
After adding the DNS records it might take a while before your email address is verified. For me it took up to a day for some.
AWS only allows sending email from verified addresses. So every address we want to use has to be validated. Let's do one.
Go to Email Addresses in the menu and click Verify a New Email Address.
Enter the Email Address and click Verify The Email Address.
The address will be added and an email is send to the address for verification.
Click the link in the email and you will be guided to a page that says: "Congratulations!". Now repeat for each email address you (your application) are using to send emails.
To actually send our emails we need to send them through an SMTP server. In Europe there are two options: Ireland (eu-west-1) and Frankfurt (eu-central-1). In this example we'll take Ireland, but the process is the same.
Go to SMTP settings in the SES menu and click Create My SMTP Credentials. The server information to connect to are also shown on this page.
You're redirected to IAM to create an IAM User Name. I named mine
ses-smtp-user.MessagingAPI. It reflects the AWS service
ses-smtp and the application
MessagingAPI we use it for.
Download the credentials and save them somewhere safe.
The user will be added in your IAM user list.
When creating an SES "account", AWS puts your account in the sandbox environment. This prevents your account from sending emails to non-verified email addresses, i.e. you can only email yourself.
As I already have our account in production mode, I can't show you how to do this. It is a bit cryptic, as you have to request a Sending Limit Increase. So stop looking for "Switch to Production Mode" or something.
In the previous image you could also see some sending statistics. As there is a limit to the amount of emails you can send per second and per day, it is good to keep an eye on this when your company grows.
More important though is your reputation. You can also see in the SES metric how many emails are rejected or bounced and how many complaints AWS received. This is aggregated into your "Account status".
For now we only created a single WorkMail user with aliases. In the future we are going to split them into separate users and group them (developers, marketing, finance,...). Using one address is obviously cheaper, but it also means all mail is in the same mailbox (no privacy).
SES has an email template option. I haven't looked into it in detail, but it looks interesting. At this moment we have an application that "builds" our emails and sends them. Building the emails could probably be offloaded to SES by using these templates. In that scenario our application only has to send the variables.
I had set up SMTP and sending in the
eu-west-1 region. The same region that offers the WorkMail service. However, our main region,
eu-central-1, also has the SMTP/SES service. Should we use that? The service is "only" sending email, so latency is no issue. We can use both sites in parallel to effectively double the sending rate. You have to verify your domains and email (sending) addresses in each region separately.
If you are concerned about your sending reputation, you can set alarms in CloudWatch. This can only be done when at least one complaint or bounce is received.
That's it for email. In the next part we're going to setup S3 so we can store our application files, blog images and backups.