🐙 GitHub
Setting Up Cost-Effective Email Solutions on AWS
In this article, I'll show you how to set up email addresses for your AWS domain at almost no cost. I've successfully implemented this technique for my domain, radzion.com, as well as for two of my projects: increaser.org and georgiancitizen.com. This method is straightforward, requiring only a single AWS Lambda function and no additional costs as you add more domains. You can find everything needed to deploy this solution, including both the Terraform infrastructure and the Lambda function source code, in the RadzionKit repository—a comprehensive toolkit designed to jumpstart full-stack projects within a monorepo.
Automating Email Infrastructure with Terraform
To minimize manual operations on the AWS console, we utilize Terraform to automate the infrastructure setup. This approach simplifies adding email solutions for new addresses without requiring much additional effort. Our infrastructure hinges on just four variables:
-
name
: Use this to prefix your resources. Choose something unique and descriptive. -
forward_to
: This should be your personal email address, such as your Gmail, where you wish to receive emails. -
domain
: A JSON list of objects, each containing a domain name and AWS zone ID. -
sentry_key
: Optional. Use this to send error reports to Sentry.
variable "name" {}
variable "forward_to" {}
variable "domains" {
type = list(object({
domain_name : string
zone_id : string
}))
}
variable "sentry_key" {}
To manage the Terraform state effectively, I store it in an S3 bucket. Before executing any Terraform commands, it's essential to set up environment variables. These include AWS credentials, a description of the S3 bucket, and the necessary Terraform variables. All Terraform variables should be prefixed with TF_VAR_
.
export AWS_SECRET_ACCESS_KEY=
export AWS_ACCESS_KEY_ID=
export AWS_REGION=
# optional, only if you want to store terraform state in S3
export TF_VAR_remote_state_bucket=
export TF_VAR_remote_state_key=
export TF_VAR_remote_state_region=
export TF_VAR_name=
# e.g. john@gmail.com
export TF_VAR_forward_to=
# a JSON string, e.g.
# '[{"domain_name":"radzion.com","zone_id":"A1026834LOTQUY1CVV2S"},{"domain_name":"increaser.org","zone_id":"Z1QT1BOR8JUIVM"}]'
export TF_VAR_domains=
export TF_VAR_sentry_key=
With the environment variables set, we can proceed to initialize the Terraform project and apply the infrastructure changes. Since I use an S3 backend for storing Terraform state, it is necessary to specify the bucket name, key, and region in the terraform init
command.
terraform init \
-backend-config="bucket=${TF_VAR_remote_state_bucket}" \
-backend-config="key=${TF_VAR_remote_state_key}" \
-backend-config="region=${TF_VAR_remote_state_region}"
terraform apply
Establishing SES Domain Identity and Email Reception
First, we need to set up the SES domain identity, which is essential for proving ownership of your domain to AWS. This step is crucial as it allows you to manage email sending and receiving capabilities securely under your domain's name. This verification is accomplished by iterating over each domain in the domains
variable, creating an aws_ses_domain_identity
resource for each. Subsequently, a aws_route53_record
resource is configured with a verification token from domain_identity
to verify the domain.
provider "aws" {
}
terraform {
backend "s3" {
}
}
resource "aws_ses_domain_identity" "domain_identity" {
for_each = { for idx, domain in var.domains : idx => domain }
domain = each.value.domain_name
}
resource "aws_route53_record" "amazonses_verification_record" {
for_each = { for idx, domain in var.domains : idx => domain }
zone_id = each.value.zone_id
name = "_amazonses.${each.value.domain_name}"
type = "TXT"
ttl = 600
records = [aws_ses_domain_identity.domain_identity[each.key].verification_token]
}
resource "aws_route53_record" "amazonses_receiving_record" {
for_each = { for idx, domain in var.domains : idx => domain }
zone_id = each.value.zone_id
name = each.value.domain_name
type = "MX"
ttl = 600
records = ["10 inbound-smtp.${data.aws_region.current.name}.amazonaws.com"]
}
resource "aws_s3_bucket" "emails_storage" {
bucket = "tf-${var.name}-emails-storage"
}
data "aws_caller_identity" "current" {}
data "aws_region" "current" {}
data "archive_file" "local_zipped_lambda" {
type = "zip"
source_dir = "${path.module}/lambda"
output_path = "${path.module}/lambda.zip"
}
resource "aws_s3_object" "zipped_lambda" {
bucket = aws_s3_bucket.lambda_storage.id
key = "lambda.zip"
source = data.archive_file.local_zipped_lambda.output_path
}
resource "aws_s3_bucket" "lambda_storage" {
bucket = "tf-${var.name}-storage"
}
resource "aws_lambda_function" "ses_forwarder" {
function_name = "tf-${var.name}"
s3_bucket = aws_s3_bucket.lambda_storage.bucket
s3_key = "lambda.zip"
handler = "src/index.handler"
runtime = "nodejs20.x"
timeout = 50
memory_size = 1600
role = aws_iam_role.ses_forwarder.arn
environment {
variables = {
SENTRY_KEY = var.sentry_key
FORWARD_TO = var.forward_to
EMAILS_BUCKET = aws_s3_bucket.emails_storage.bucket
}
}
}
resource "aws_iam_role" "ses_forwarder" {
name = "tf-${var.name}"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Principal = {
Service = "lambda.amazonaws.com"
}
Effect = "Allow"
Sid = ""
}
]
})
}
resource "aws_cloudwatch_log_group" "ses_forwarder" {
name = "tf-${var.name}"
}
resource "aws_iam_policy" "ses_forwarder" {
name = "tf-${var.name}"
path = "/"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
]
Resource = "arn:aws:logs:*:*:*"
},
{
Effect = "Allow"
Action = "ses:SendRawEmail"
Resource = "*"
},
{
Effect = "Allow"
Action = [
"s3:GetObject",
"s3:PutObject"
]
Resource = "arn:aws:s3:::${aws_s3_bucket.emails_storage.bucket}/*"
}
]
})
}
resource "aws_iam_role_policy_attachment" "ses_forwarder" {
role = aws_iam_role.ses_forwarder.name
policy_arn = aws_iam_policy.ses_forwarder.arn
}
data "aws_iam_policy_document" "emails_storage" {
statement {
sid = "GiveSESPermissionToWriteEmail"
effect = "Allow"
principals {
identifiers = ["ses.amazonaws.com"]
type = "Service"
}
actions = ["s3:PutObject"]
resources = ["${aws_s3_bucket.emails_storage.arn}/*"]
}
}
resource "aws_s3_bucket_policy" "emails_storage" {
bucket = aws_s3_bucket.emails_storage.id
policy = data.aws_iam_policy_document.emails_storage.json
}
resource "aws_lambda_permission" "allow_ses" {
statement_id = "AllowExecutionFromSES"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.ses_forwarder.function_name
source_account = data.aws_caller_identity.current.account_id
principal = "ses.amazonaws.com"
}
resource "aws_ses_receipt_rule_set" "rule_set" {
rule_set_name = "tf-${var.name}-rule-set"
}
resource "aws_ses_active_receipt_rule_set" "rule_set" {
rule_set_name = aws_ses_receipt_rule_set.rule_set.rule_set_name
}
locals {
domain_names = [for domain in var.domains : domain.domain_name]
}
resource "aws_ses_receipt_rule" "receipt_rule" {
name = "tf-${var.name}-rule"
rule_set_name = aws_ses_receipt_rule_set.rule_set.rule_set_name
recipients = local.domain_names
enabled = true
scan_enabled = true
s3_action {
bucket_name = aws_s3_bucket.emails_storage.bucket
position = 1
}
lambda_action {
function_arn = aws_lambda_function.ses_forwarder.arn
invocation_type = "Event"
position = 2
}
}
This Terraform resource, aws_route53_record
named "amazonses_receiving_record", configures MX records for each domain specified in the domains
variable to enable email receiving. It sets the mail exchange server to AWS's SMTP interface, specifying the AWS region dynamically, ensuring that emails directed to your domain are correctly routed to AWS for processing.
The Terraform resource aws_s3_bucket
named "emails_storage" creates an S3 bucket to store all incoming emails, ensuring they are securely archived in AWS.
Configuring AWS Lambda for Email Forwarding
Once an email is received and stored in the S3 bucket, an AWS Lambda function, ses_forwarder
, notifies and forwards the email to a personal address specified in the forward_to
variable. Initially, a placeholder ("dummy") Lambda function code is uploaded using the aws_s3_object
resource to store it in the "lambda_storage" bucket. This setup allows us to establish the infrastructure without the final Lambda code. Later, we replace the dummy code with the actual functionality. The dummy code, located in lambda/index.js
within our Terraform module, is prepared by archiving it locally with the archive_file
before uploading to S3.
Setting Permissions and Receipt Rules for Email Handling
In the Lambda policy we grant it access for making logs, sending an email and reading/writing to the S3 bucket. We also allow SES to write emails to the S3 bucket by creating an IAM The Lambda function is granted permissions to log actions, send emails, and read/write to the S3 bucket via a Lambda policy. Additionally, an IAM policy document allows SES to store incoming emails directly in the S3 bucket. To ensure the Lambda function triggers upon receiving an email, the aws_lambda_permission
resource allows SES to invoke the function. Finally, the aws_ses_receipt_rule
resource establishes a receipt rule for each domain listed in the domains
variable, directing the handling of incoming emails to the specified S3 bucket and Lambda function.
Final Steps and Troubleshooting the Email Setup
We've covered the setup of the infrastructure needed for handling emails via AWS. It's common to encounter errors when applying Terraform changes, particularly with Lambda deployments. If an error occurs, deploying the Lambda function manually and re-running terraform apply
should resolve the issue. Additionally, you must manually add your forward_to
email address to the SES identities. This step isn't automated through Terraform because it requires verification by clicking a link in an email sent to that address, which ensures the security and ownership of the email account.
Understanding the Lambda Function Code and Environment Management
Now, let's examine the Lambda function code in the lambda.ts
file. We begin by setting up Sentry for error tracking to ensure any issues are promptly reported and handled. The function processes each record in the SES event by iterating over them and forwarding the emails to the specified address using the processSesEventRecord
function.
import { AWSLambda } from "@sentry/serverless"
import { SESEvent } from "aws-lambda"
import { processSesEventRecord } from "./processSesEventRecord"
import { getEnvVar } from "./getEnvVar"
AWSLambda.init({
dsn: getEnvVar("SENTRY_KEY"),
})
export const handler = AWSLambda.wrapHandler(async (event: SESEvent) => {
await Promise.all(event.Records.map(processSesEventRecord))
})
In my projects, I incorporate the getEnvVar
function to manage environment variables effectively. This function checks for the presence of required environment variables and throws an error if any are missing, preventing runtime issues due to misconfiguration.
type VariableName = "SENTRY_KEY" | "FORWARD_TO" | "EMAILS_BUCKET"
export const getEnvVar = (name: VariableName): string => {
const value = process.env[name]
if (!value) {
throw new Error(`Missing ${name} environment variable`)
}
return value
}
Detailed Workflow of the Lambda Email Processing Function
The processSesEventRecord
function executes a series of steps to handle each SES event record. If an error occurs during this process, it calls the reportError
function, passing the problematic record and a detailed explanation to Sentry for more effective troubleshooting and context.
import { SESEventRecord } from "aws-lambda"
import { reportError } from "@lib/lambda/reportError"
import { getEmailFromStorage } from "./getEmailFromStorage"
import { formatEmail } from "./formatEmail"
import { getEnvVar } from "./getEnvVar"
import { forwardEmail } from "./forwardEmail"
export const processSesEventRecord = async (record: SESEventRecord) => {
console.log("Processing SES event record", { record })
try {
const {
mail,
receipt: { recipients },
} = record.ses
const message = await getEmailFromStorage(mail.messageId)
if (recipients.length > 1) {
throw new Error("Multiple recipients are not supported")
}
const [recipient] = recipients
const formattedEmail = formatEmail({
message,
recipient,
forwardTo: getEnvVar("FORWARD_TO"),
})
return forwardEmail({
forwardTo: getEnvVar("FORWARD_TO"),
message: formattedEmail,
sendFrom: recipient,
})
} catch (err) {
reportError(err, { record, msg: "Error processing SES event record" })
}
}
The first step in processSesEventRecord
involves retrieving the email from the S3 bucket using the getEmailFromStorage
function. This function initializes an S3 client and executes a GetObjectCommand
with the provided messageId
to fetch the email. If the email cannot be found, the function throws an error. Additionally, since the returned Body
from S3 is a blob, it is converted into a string for further processing.
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3"
import { getEnvVar } from "./getEnvVar"
export const getEmailFromStorage = async (messageId: string) => {
const s3 = new S3Client({})
const command = new GetObjectCommand({
Bucket: getEnvVar("EMAILS_BUCKET"),
Key: messageId,
})
const { Body } = await s3.send(command)
if (!Body) {
throw new Error(`Email ${messageId} not found`)
}
return Body.transformToString()
}
Next, the function checks the recipients of the email. I operate under the assumption that emails with multiple recipients are likely to be spam, and therefore, I throw an error in such cases. If you prefer to handle emails with multiple recipients, you can set an environment variable containing a list of your domains. The function can then check if any recipient address matches one of your domains and forward the email accordingly.
Once the recipient is determined, the formatEmail
function processes the email to prepare it for forwarding. This function ensures SES compliance by reformatting headers: it updates the "From" header to a verified domain, sets the "To" header to the intended recipient, and manages the "Reply-To" setting. Additionally, it removes headers like "Return-Path" and "DKIM-Signature" that could cause delivery issues.
import { ErrorWithContext } from "@lib/utils/errors/ErrorWithContext"
type FormatEmailInput = {
message: string
recipient: string
forwardTo: string
}
export const formatEmail = ({
message,
recipient,
forwardTo,
}: FormatEmailInput): string => {
const parsedMessage = message.match(/^((?:.+\r?\n)*)(\r?\n(?:.*\s+)*)/m)
if (!parsedMessage) {
throw new ErrorWithContext("Failed to parse email", {
message,
})
}
let header = parsedMessage[1]
const body = parsedMessage[2]
// Add "Reply-To:" with the "From" address if it doesn't already exists
if (!/^reply-to:[\t ]?/im.test(header)) {
const [, from] =
header.match(/^from:[\t ]?(.*(?:\r?\n\s+.*)*\r?\n)/im) || []
if (from) {
header = `${header}Reply-To: ${from}`
}
}
// SES does not allow sending messages from an unverified address,
// so replace the message's "From:" header with the original
// recipient (which is a verified domain)
header = header.replace(
/^from:[\t ]?(.*(?:\r?\n\s+.*)*)/gim,
(_, from) =>
`From: ${from.replace("<", "at ").replace(">", "")} <${recipient}>`
)
// Replace original 'To' header with a manually defined one
header = header.replace(/^to:[\t ]?(.*)/gim, () => `To: ${forwardTo}`)
// Remove the Return-Path header.
header = header.replace(/^return-path:[\t ]?(.*)\r?\n/gim, "")
// Remove Sender header.
header = header.replace(/^sender:[\t ]?(.*)\r?\n/gim, "")
// Remove Message-ID header.
header = header.replace(/^message-id:[\t ]?(.*)\r?\n/gim, "")
// Remove all DKIM-Signature headers to prevent triggering an
// "InvalidParameterValue: Duplicate header 'DKIM-Signature'" error.
// These signatures will likely be invalid anyways, since the From
// header was modified.
header = header.replace(/^dkim-signature:[\t ]?.*\r?\n(\s+.*\r?\n)*/gim, "")
return `${header}${body}`
}
Finally, the forwardEmail
function sends the processed email to our personal address using the recipient's address. This function creates an SES v2 client and executes the SendEmailCommand
, which requires the destination address (forwardTo
), the email content, and the FromEmailAddress
(the verified sender address).
import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2"
type ForwardEmailInput = {
forwardTo: string
message: string
sendFrom: string
}
export const forwardEmail = ({
forwardTo,
message,
sendFrom,
}: ForwardEmailInput) => {
const client = new SESv2Client({})
const command = new SendEmailCommand({
Destination: {
ToAddresses: [forwardTo],
},
Content: {
Raw: {
Data: new TextEncoder().encode(message),
},
},
FromEmailAddress: sendFrom,
})
return client.send(command)
}
Deploying and Building the Lambda Function
Now we can deploy our lambda by building the project, packaging it into a zip file, and uploading it to S3. After uploading, we update the Lambda function's code using the AWS CLI to point to the new package in the S3 bucket.
yarn build
cd dist
BUCKET=tf-radzion-email-storage
BUCKET_KEY=lambda.zip
FUNCTION_NAME=tf-radzion-email
zip -r ./$BUCKET_KEY *
aws s3 cp $BUCKET_KEY s3://$BUCKET/$BUCKET_KEY
aws lambda update-function-code --function-name $FUNCTION_NAME --s3-bucket $BUCKET --s3-key $BUCKET_KEY
cd ..
The project's build process starts with the clean
script that removes any previous build artifacts from the dist
directory and deletes the lambda.zip
file. Then, the transpile
script uses esbuild
to bundle, minify, and transpile the lambda.ts
file into index.js
, targeting Node.js environments and storing the output in the dist
directory.
{
"scripts": {
"transpile": "esbuild lambda.ts --bundle --minify --sourcemap --platform=node --target=es2020 --outfile=dist/index.js",
"build": "yarn clean & yarn transpile",
"clean": "rm -rf ./dist lambda.zip"
}
}
Testing Email Reception and Configuring Outbound Settings
With the infrastructure and Lambda function configured, you're now ready to test sending emails to your domain. For example, with the radzion.com
domain, you could send emails to addresses like help@radzion.com
or radzion@radzion.com
. Our setup is designed to handle all variations, ensuring that each email is correctly processed and forwarded.
Now that you've configured receiving emails, the next step is to set up the ability to send emails from your domain using your email provider. For Gmail users, navigate to "Settings," then "See all settings," and click on the "Accounts and Import" tab. Here, select "Add another email address." This process requires SMTP server details, a username, and a password, which you will retrieve from AWS SES.
In the AWS SES console, under SMTP settings, create SMTP credentials. This will provide you with the necessary server name, port, and SMTP credentials to enter in Gmail's setup, allowing you to send emails as if from your domain.
Top comments (0)