Cloud Confusing

How To Easily Add Email To Your Domain

It’s 2018. We live in a world where email is supposedly being replaced by Slack, Hangouts, Microsoft Teams, WhatsApp, and about 100 other services. That said, email is still mission critical for almost every company and if you have a business application with its own domain you almost certainly need an email address associated with it.

It turns out that setting up email for your domain is still a bit of a pain. Here’s the easiest way to handle custom domain emails.

TLDR: Head down to “How To Setup Gmail For Custom Domains”

So here’s the scenario I wanted to solve for — it’s it’s helpful for you, keep reading. I wanted to add email to a website, without any of the messiness of administering an email server. In this case it was a static site hosted on S3.

In this instance it was a small project, which means I needed a single email account, no advanced functions (just send, forward, and receive), and no need for transactional email.

It was also important for me to avoid unnecessary complications from anything like Active Directory. My goal with this email was simply to be fast to setup, free or cheap to run, secure, and zero maintenance. Long story short, of all the projects I put on CloudConfusing, I’d see supporting email as being at or near the bottom of my priority list based on my current development and learning goals.

Just to be clear, there are free ways to do this, specifically with Gmail, but most involve a “send email as” solution, which wasn’t what I wanted. Those emails are sometimes blocked, presumably because of Sender Policy Framework (SPF) issues.

Custom Domain Email Options

Amazon WorkMail

My first idea was to try Amazon WorkMail. I’m deeply integrated into the AWS stack, so why not keep that trend going? At $4/month/user this seemed like a good option, especially given my preference for AWS (mainly for unified billing and support, easy integration with my existing toolset). There is also a web application in case I needed to login to the account.

Ultimately WorkMail wasn’t a good solution for me because it requires use of a directory (such as Microsoft Active Directory, AWS Managed Active Directory, or AWS Simple Active Directory). You can create a new one of these or use an existing one, but either way it’s another thing to setup and maintain. Maybe this would be no big deal, but it was an unnecessary headache for me.

Amazon WorkMail Alternatives

Next up I did a quick check of the other players in the space, Google ($5/month), Zoho ($4/month), ProtonMail ($12/month), FastMail ($5/month), and FlaskMail ($4/month). All of these seemed like reasonable offerings, with similar setups, and featuresets. FastMail in particular seemed reasonably priced and well-suited to the task with their $5/month or $50/year standard plan.

All of these products have paid (as in non-free) plans that support custom domains, webmail, and some basic level of support.

Easy Solution For Custom Domain Email

Ultimately I ended up going with Google. I used their G Suite by Google Cloud option with a $5/month/user plan which included custom domain email, G Suite Gmail, and all the other feature of a corporate Google Apps/G Suite account: up to 1000 users, 30GB storage per user, and up to 30 email aliases per user. 24/7 support is included as well.

The number one perk of the Google route was setup time. I already had a Google Cloud (aka GCP) account, I’m a personal Gmail user so I had the mobile app already setup, and I’m familiar with the toolset. This means billing was taken care of and jumping between email accounts in the Gmail app is totally seamless.

How To Setup Gmail For Custom Domains

The program you want for this is Custom Email with G Suite. You can do this all through G Suite for Domains, but you don’t have to — your domain can be registered and hosted anywhere. If you do use Google Domains you’ll get a thing things few streamlined, automatic Gmail accounts and email protection, specifically DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF).

The main thing you’ll need to do once you have your G Suite account configured is to update the MX record your domain host, for me this was Route 53. The mail exchanger record (MX record) is how the DNS system verifies a mail server against the domain.

You’ll want to add the following (as per Google’s docs) to your domain host:

Priority / Mail Server

• 1 ASPMX.L.GOOGLE.COM.
• 5 ALT1.ASPMX.L.GOOGLE.COM.
• 5 ALT2.ASPMX.L.GOOGLE.COM.
• 10 ALT3.ASPMX.L.GOOGLE.COM.
• 10 ALT4.ASPMX.L.GOOGLE.COM.

Any TTL values can be put at 1 hour (usually input as “3600”).

Give this a few minutes and your email should be up and working. You can send/receive email through gmail.com, the Gmail app, or your email software of choice.

You can also easily add aliases (different accounts for that one mailbox). In addition to account aliases G Suite also supports up to 20 free domain aliases which can be very handy if you support multiple sites.

Disappointingly Simple Solution?

This site is largely about rolling your own solutions to problems using cloud-based tools. I’d say this solution qualifies for that, but I’d understand anyone who sees this as being a non-solution (simply paying a vendor to handle it for you). Normally I’d agree, but when it comes to email, making it someone else’s problem really does seem like the right way to go. AWS WorkMail seems like an OK solution for larger teams, but given that it has no pricing benefit over Google and requires a directory, it doesn’t make sense.

It is possible to configure your own mail server with a VPS and a stack like like Airmail, Postfix, and Dovecot but this is a major undertaking and would not have the reliability I need. Past reliability, the project has little to no benefit from a learning standpoint for me and while the privacy benefits are interesting, I’d go with FastMail, Proton, or a similar provider if that was a major concern.

Sal October 11th, 2018

Posted In: AWS, Google Cloud Platform

Tags: Email, MX Records, WorkMail