DEV Community

AWS Community Builders profile image Ayman Aly Mahmoud
Ayman Aly Mahmoud for AWS Community Builders

Posted on

$1.50/Month Email Infrastructure That Beats Your $20 SendGrid Plan

Stop Paying $20/Month for Email You Could Run for $1.50

Most teams handle programmatic email one of two ways.

The first: sign up for SendGrid or Mailgun, grab an API key, and start sending. It works great — until you hit 50K emails and the bill jumps to $20/month, then you add inbound parsing and it's another plan tier, then you need bounce webhooks and suddenly you're deep in a third-party dashboard you barely understand, paying for features you don't use.

The second: use Google Workspace's catch-all rule to funnel everything into one inbox. Free-ish, but completely dumb — no processing, no routing, no automation. Every contact form submission and support@ email lands in the same pile for a human to sort manually.

There's a better way that most AWS developers walk right past. Amazon SES catches the mail, S3 stores it, Lambda processes it. The logic lives in your codebase, the infrastructure is fully in your AWS account, and the bill last month was $1.48.

Let me show you exactly how it works.

The idea in one diagram

ses

That's it. SES stores the raw email in S3, then fires Lambda. Lambda rewrites the headers and re-sends via SES. Your team gets the email; they hit Reply; it goes back to whoever sent it.

The S3 step isn't optional — it's actually the smart part. Every email is durably stored before Lambda touches it. Parser bug? Replay from S3. Need an audit trail? It's there, with 30-day auto-expiry built in.

This is not a replacement for Google Workspace or AWS WorkMail

Worth saying clearly before going further.

Google Workspace and AWS WorkMail are mailbox products — your team logs in, reads emails, manages a calendar, sends from their phone. That's a completely different problem from what this stack solves.

SES + Lambda + S3 Google Workspace / WorkMail
Who uses it Your code Your people
Interface API / SDK Gmail, Outlook, mobile apps
Use case Contact forms, alerts, forwarding, automation Human inboxes, calendar, collaboration
Handles attachments Yes, programmatically Yes, in a UI
IMAP / POP3 No Yes
Shared calendars No Yes
Price ~$1–50/month flat $6–12/user/month

The honest recommendation: run both. Keep Workspace or WorkMail for your team's human mailboxes. Use this stack for everything your application touches — the support@ alias that should file a ticket, the contact@ that should notify Slack, the noreply@ that sends password resets.

They're not competing. They solve different problems.

Why not just use SendGrid / Postmark / Mailgun?

Nothing wrong with them. But look at the math for a typical small company:

10K emails/month 500K emails/month
SES + Lambda + S3 ~$1.50 ~$55
Postmark $15 ~$650
SendGrid Essentials $19.95 $89.95+
Mailgun $35 $90+
Self-hosted VPS ~$15 + your time same + more time

SES is $0.10 per 1,000 emails. That rate has not changed since 2011. At 500K sends, you're paying $50 while Postmark charges $650 for the same volume. The gap is real.

The catch: SES is infrastructure, not a product. No drag-and-drop campaign builder, no deliverability dashboard (unless you pay extra for VDM). If you want someone to hold your hand through email, pay for managed. If you're comfortable in AWS, this stack is hard to beat.

Keep Google Workspace or Microsoft 365 for your human mailboxes. This pattern is for the email your code handles — contact forms, support@ aliases, alerts, password resets.

What the deploy actually creates

One SAM template provisions everything:

  • S3 bucket — stores raw emails under inbox/, auto-deletes after 30 days
  • SES identity — verifies your domain with DKIM signing enabled
  • Route 53 records — MX, SPF, DMARC, and all 3 DKIM CNAMEs, created automatically
  • Lambda + IAM — reads from S3, forwards via SES
  • Receipt rule — catches all mail at your domain, stores then invokes Lambda
  • Custom resource — activates the rule set automatically so you don't have to 
sam build
sam deploy --guided \
  --parameter-overrides \
    EmailDomain=yourcompany.com \
    ForwardTo=team@yourcompany.com \
    ForwardFrom=relay@yourcompany.com \
    HostedZoneId=ZXXXXXXXXXXXXX
Enter fullscreen mode Exit fullscreen mode

One command. Everything wired up.

The code

template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Serverless email infrastructure (SES + S3 + Lambda)

Parameters:
  EmailDomain:
    Type: String
    Description: Domain configured to receive email (e.g. yourcompany.com)
  ForwardTo:
    Type: String
    Description: Address to forward incoming mail to
  ForwardFrom:
    Type: String
    Description: Verified sender used as the From on forwards
  HostedZoneId:
    Type: String
    Description: Route 53 Hosted Zone ID for the domain

Resources:

  # -------------------------------------------------------
  # S3 — raw email storage
  # -------------------------------------------------------
  EmailBucket:
    Type: AWS::S3::Bucket
    Properties:
      LifecycleConfiguration:
        Rules:
          - Id: ExpireRawEmails
            Status: Enabled
            ExpirationInDays: 30

  EmailBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref EmailBucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Sid: AllowSESPuts
            Effect: Allow
            Principal:
              Service: ses.amazonaws.com
            Action: s3:PutObject
            Resource: !Sub '${EmailBucket.Arn}/*'
            Condition:
              StringEquals:
                AWS:SourceAccount: !Ref AWS::AccountId

  # -------------------------------------------------------
  # Lambda — parse and forward
  # -------------------------------------------------------
  ProcessEmailFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: app.lambda_handler
      CodeUri: ./src/
      MemorySize: 256
      Timeout: 30
      Environment:
        Variables:
          FORWARD_TO: !Ref ForwardTo
          FORWARD_FROM: !Ref ForwardFrom
          BUCKET_NAME: !Ref EmailBucket
          BUCKET_PREFIX: inbox/
      Policies:
        - S3ReadPolicy:
            BucketName: !Ref EmailBucket
        - Statement:
            - Effect: Allow
              Action: ses:SendRawEmail
              Resource: '*'

  ProcessEmailFunctionSESPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !GetAtt ProcessEmailFunction.Arn
      Principal: ses.amazonaws.com
      SourceAccount: !Ref AWS::AccountId

  # -------------------------------------------------------
  # SES — identity, receipt rule set and rule
  # -------------------------------------------------------
  SESEmailIdentity:
    Type: AWS::SES::EmailIdentity
    Properties:
      EmailIdentity: !Ref EmailDomain
      DkimAttributes:
        SigningEnabled: true

  ReceiptRuleSet:
    Type: AWS::SES::ReceiptRuleSet
    Properties:
      RuleSetName: !Sub '${AWS::StackName}-rules'

  ReceiptRule:
    Type: AWS::SES::ReceiptRule
    DependsOn:
      - EmailBucketPolicy
      - SESEmailIdentity
    Properties:
      RuleSetName: !Ref ReceiptRuleSet
      Rule:
        Name: store-and-process
        Enabled: true
        ScanEnabled: true
        Recipients:
          - !Ref EmailDomain
        Actions:
          - S3Action:
              BucketName: !Ref EmailBucket
              ObjectKeyPrefix: inbox/
          - LambdaAction:
              FunctionArn: !GetAtt ProcessEmailFunction.Arn
              InvocationType: Event

  # -------------------------------------------------------
  # Route 53 — all DNS records created automatically
  # -------------------------------------------------------
  DkimRecord1:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "${SESEmailIdentity.DkimDNSTokenName1}"
      Type: CNAME
      TTL: 300
      ResourceRecords:
        - !Sub "${SESEmailIdentity.DkimDNSTokenValue1}"

  DkimRecord2:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "${SESEmailIdentity.DkimDNSTokenName2}"
      Type: CNAME
      TTL: 300
      ResourceRecords:
        - !Sub "${SESEmailIdentity.DkimDNSTokenValue2}"

  DkimRecord3:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "${SESEmailIdentity.DkimDNSTokenName3}"
      Type: CNAME
      TTL: 300
      ResourceRecords:
        - !Sub "${SESEmailIdentity.DkimDNSTokenValue3}"

  MXRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "${EmailDomain}."
      Type: MX
      TTL: 300
      ResourceRecords:
        - !Sub "10 inbound-smtp.${AWS::Region}.amazonaws.com"

  SPFRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "${EmailDomain}."
      Type: TXT
      TTL: 300
      ResourceRecords:
        - '"v=spf1 include:amazonses.com -all"'

  DMARCRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZoneId
      Name: !Sub "_dmarc.${EmailDomain}."
      Type: TXT
      TTL: 300
      ResourceRecords:
        - !Sub '"v=DMARC1; p=none; rua=mailto:dmarc@${EmailDomain}"'

  # -------------------------------------------------------
  # Custom resource — activates the rule set automatically
  # -------------------------------------------------------
  ActivateRuleSetFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: index.handler
      InlineCode: |
        import boto3, cfnresponse
        def handler(event, context):
          try:
            if event['RequestType'] in ('Create', 'Update'):
              boto3.client('ses').set_active_receipt_rule_set(
                RuleSetName=event['ResourceProperties']['RuleSetName']
              )
            cfnresponse.send(event, context, cfnresponse.SUCCESS, {})
          except Exception as e:
            cfnresponse.send(event, context, cfnresponse.FAILED, {'Error': str(e)})
      Policies:
        - Statement:
            - Effect: Allow
              Action: ses:SetActiveReceiptRuleSet
              Resource: '*'

  ActivateRuleSet:
    Type: AWS::CloudFormation::CustomResource
    DependsOn: ReceiptRuleSet
    Properties:
      ServiceToken: !GetAtt ActivateRuleSetFunction.Arn
      RuleSetName: !Ref ReceiptRuleSet

Outputs:
  BucketName:
    Description: S3 bucket storing raw incoming emails
    Value: !Ref EmailBucket
  RuleSetName:
    Description: Active receipt rule set
    Value: !Ref ReceiptRuleSet
  LambdaFunction:
    Description: Email processing function
    Value: !GetAtt ProcessEmailFunction.Arn
Enter fullscreen mode Exit fullscreen mode

src/app.py

The key insight here is to mutate the original message in-place rather than building a new MIME object from scratch. This preserves attachments, encoding, and HTML content without any extra parsing. The critical step is stripping the headers that would cause DKIM verification to fail on the re-sent message.

import os
import email
import logging

import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

s3  = boto3.client("s3")
ses = boto3.client("ses")

FORWARD_TO    = os.environ["FORWARD_TO"]
FORWARD_FROM  = os.environ["FORWARD_FROM"]
BUCKET_NAME   = os.environ["BUCKET_NAME"]
BUCKET_PREFIX = os.environ["BUCKET_PREFIX"]  # "inbox/"

# These headers are tied to the original message signature.
# Keeping them causes DKIM failure on the forwarded copy.
HEADERS_TO_REMOVE = [
    "DKIM-Signature",
    "Sender",
    "Return-Path",
    "Message-ID",
]


def lambda_handler(event, context):
    for record in event["Records"]:
        mail    = record["ses"]["mail"]
        receipt = record["ses"]["receipt"]

        msg_id     = mail["messageId"]
        recipients = receipt["recipients"]
        s3_key     = f"{BUCKET_PREFIX}{msg_id}"

        logger.info("Processing %s for recipients %s", msg_id, recipients)

        raw = s3.get_object(Bucket=BUCKET_NAME, Key=s3_key)["Body"].read()
        msg = email.message_from_bytes(raw)

        original_from    = msg.get("From", "unknown")
        original_subject = msg.get("Subject", "(no subject)")

        for header in HEADERS_TO_REMOVE:
            if header in msg:
                del msg[header]

        # Rewrite From so SES accepts the send
        if "From" in msg:
            msg.replace_header("From", FORWARD_FROM)
        else:
            msg["From"] = FORWARD_FROM

        # Reply-To preserves the original sender — your team hits Reply
        # and it goes back to the person who sent it, not to your relay address
        if "Reply-To" in msg:
            msg.replace_header("Reply-To", original_from)
        else:
            msg["Reply-To"] = original_from

        # Subject prefix tells you which alias received it
        original_recipient = recipients[0] if recipients else ""
        new_subject = f"[{original_recipient}] {original_subject}"
        if "Subject" in msg:
            msg.replace_header("Subject", new_subject)
        else:
            msg["Subject"] = new_subject

        if "To" in msg:
            msg.replace_header("To", FORWARD_TO)
        else:
            msg["To"] = FORWARD_TO

        ses.send_raw_email(
            Source=FORWARD_FROM,
            Destinations=[FORWARD_TO],
            RawMessage={"Data": msg.as_bytes()},
        )
        logger.info("Forwarded %s → %s → %s", msg_id, original_recipient, FORWARD_TO)

    return {"statusCode": 200}
Enter fullscreen mode Exit fullscreen mode

Deploying it

Prerequisites: AWS CLI configured, SAM CLI v1.129+, a domain in Route 53.

1. Get your hosted zone ID

aws route53 list-hosted-zones \
  --query "HostedZones[?Name=='yourcompany.com.'].{Id:Id,Name:Name}"
Enter fullscreen mode Exit fullscreen mode

2. Build and deploy

sam build
sam deploy --guided \
  --parameter-overrides \
    EmailDomain=yourcompany.com \
    ForwardTo=team@yourcompany.com \
    ForwardFrom=relay@yourcompany.com \
    HostedZoneId=ZXXXXXXXXXXXXX
Enter fullscreen mode Exit fullscreen mode

SAM will ask a few questions on first run — accept the defaults, confirm the changeset. The deploy creates everything: S3, Lambda, SES identity, all DNS records, and activates the rule set automatically.

3. Request production access

New SES accounts are sandboxed — you can only send to verified addresses until you request production access. Go to SES Console → Account dashboard → Request production access, describe your use case in two sentences. AWS typically responds within 24 hours.

4. Test it

Send an email to any address at your domain and watch the logs:

aws logs tail /aws/lambda/YOUR_STACK_NAME-ProcessEmailFunction \
  --follow \
  --region us-east-1
Enter fullscreen mode Exit fullscreen mode

You should see the message ID logged, then a forwarded confirmation within a couple of seconds.

If domain verification stays Pending

After deploy, SES verifies your domain by polling the DKIM CNAME records. It usually completes within 5–10 minutes. If it's been 30+ minutes and still shows Pending, check that DNS is actually resolving:

# Replace with one of your actual DKIM token values
nslookup -type=CNAME abc123._domainkey.yourcompany.com 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

If that resolves correctly, nudge SES to recheck immediately rather than waiting for its next polling cycle:

aws ses verify-domain-identity \
  --domain yourcompany.com \
  --region us-east-1

# Then check status
aws ses get-identity-verification-attributes \
  --identities yourcompany.com \
  --region us-east-1
Enter fullscreen mode Exit fullscreen mode

If DNS isn't resolving at all, the CNAME records weren't created cleanly — check the CloudFormation events for any Route 53 errors during deploy.

A few gotchas learned the hard way

SES only allows one active rule set per region per account. If you have multiple environments in the same region, they share this single slot. The solution is one rule set with multiple rules — one rule per domain — rather than multiple rule sets competing for the active slot.

New accounts start in sandbox mode. You can only send to verified addresses until you request production access. Do it on day one — AWS usually approves within 24 hours and there's no reason to wait.

Not every region supports inbound. Stick to us-east-1, us-west-2, or eu-west-1. Pick your region before pointing your MX record.

Watch your bounces. SES will throttle your account if you keep sending to addresses that bounce. Enable Account-Level Suppression in the SES console — it's free and it protects you automatically.

Want to go further?

This same stack is the backbone for a contact form endpoint — a Lambda Function URL receives the POST, validates the fields, and calls ses.send_email. Same verified domain, same IAM, a few dozen extra lines. Add a honeypot field and you get basic bot protection for free.

You can also extend the forwarder to route different aliases to different people (support@ → helpdesk, billing@ → finance) by checking recipients[0] in the Lambda and maintaining a simple routing table in the code or in DynamoDB.

The foundation is solid. Build on it.

Top comments (0)