AWS Simple Email Service (SES) is a genuinely powerful tool for sending high-volume transactional email. If you need to blast a million marketing emails or deliver password resets at scale, SES is excellent. But for receiving and routing incoming mail to your team? It's often severe overkill — requiring a half-dozen AWS services just to get a single alias working.
The Real Cost of SES for Incoming Email
When most developers hear "SES," they picture a simple SMTP relay. But setting up inbound email routing through AWS SES is a very different beast. Here's what a production-grade incoming mail setup actually requires on AWS:
- Domain verification via DKIM and SPF — You must add TXT and DKIM records and wait for propagation before SES will accept mail.
- An S3 bucket — SES does not process emails inline. It drops raw email blobs (including headers, MIME parts, attachments) into an S3 bucket. You pay for storage per GB.
- A Lambda function — You write custom code to parse the raw email, extract recipients, and implement your forwarding logic. This Lambda must handle edge cases: multi-part MIME, attachments over 10 MB, bounce addresses, thread headers.
- SNS notifications — Bounce, complaint, and delivery events come through an SNS topic that your Lambda or another endpoint must subscribe to.
- IAM roles and policies — Lambda needs permission to read from S3, SES needs permission to write to S3, and everything needs the right trust relationships.
- Ongoing monitoring and maintenance — Lambda cold starts, S3 lifecycle rules, SES sending quota limits, and CloudWatch alarms for failed deliveries are your problem.
Experienced AWS engineers can build this system in a day. But then you own it forever: debugging MIME parsing issues at 2am, handling the occasional Lambda timeout, and keeping up with AWS regional availability for SES.
The True Monthly Cost
On paper, AWS SES pricing looks cheap. But add up all the components for a modest 10,000 emails/month setup:
| Component | AWS SES Approach | Forward |
|---|---|---|
| Inbound email receiving | $0.10 / 1,000 chunks | Included |
| S3 storage (raw messages) | ~$0.023/GB/month | Not needed |
| Lambda invocations | ~$0.20 / 1M requests | Not needed |
| Lambda duration | Depends on message parse time | Not needed |
| Dev + maintenance time | Several days/yr minimum | Zero |
| Alias management UI | None (manual AWS Console) | Full dashboard |
| Team collaboration | Not built-in | Built-in |
| Effective monthly cost | $15–50+ (including eng time) | $0–19/month |
What Forward Does Instead
Forward handles the entire inbound email infrastructure for you. You add your domain, verify ownership with a single DNS TXT record, create aliases, and start receiving forwarded mail within minutes. No S3 buckets. No Lambda. No IAM policies. No MIME parsers.
Under the hood, Forward operates its own SMTP ingest servers, parses incoming messages, and delivers them to your configured destinations — whether that's a personal Gmail, a team inbox, a Slack channel email address, or a webhook.
When to use Forward: Incoming email routing, alias management, catch-all addresses, and team forwarding — especially for teams that don't want to own AWS infrastructure.
Step-by-Step: Migrating from SES Inbound to Forward
If you already have an SES inbound setup, here's how to migrate cleanly without downtime:
- Sign up and add your domain to Forward. Navigate to the Dashboard → Domains → Add Domain. Enter your domain name.
-
Add MX records. Forward will give you MX records to
add to your DNS provider. For example:
Do not remove your existing SES MX records yet — add the Forward ones at a lower priority first to verify.
Priority 10: inbound.forward.redsols.com - Verify via TXT record. Add the domain verification TXT record Forward provides. This usually propagates in under 5 minutes.
-
Create your aliases. For each alias you had in SES
receipt rules (e.g.,
support@yourdomain.com,sales@yourdomain.com), create matching aliases in the Forward dashboard and point them to your destination email addresses. - Test with a lower-priority MX. Send a test email to each alias. Once you confirm delivery works, swap the MX priority so Forward becomes the primary receiver.
- Remove SES receipt rules and S3 bucket. Once confident in Forward, clean up your AWS resources to stop incurring charges.
- Keep SES for outbound if needed. If you use SES for transactional sending, you can continue to do so. Forward handles inbound only; outbound is still managed by your application directly through SES, SendGrid, or any other provider.
Common Questions
Can I use Forward alongside my existing SES sending setup?
Yes. MX records control inbound routing and are separate from SPF/DKIM records used for outbound sending. You can route inbound mail through Forward while still sending transactional email via SES without any conflict.
What about large attachments?
Forward handles standard email attachments. Extremely large attachments (50 MB+) may be subject to limits on the receiving end (your Gmail or Outlook inbox), which is the same limitation you'd face with SES Lambda processing anyway.
Can I replicate SES's catch-all behavior?
Yes — Forward supports catch-all aliases per domain. Any email to an unconfigured address on your domain can be collected by a wildcard alias, which is exactly what SES receipt rules with a wildcard recipient condition achieve.
The Bottom Line
For inbound email routing, the SES approach trades simplicity for flexibility. If your team's core competency isn't AWS infrastructure, the maintenance overhead of an SES inbound stack rarely pays off. Forward gives you the same outcome — emails arrive at the right destination — with zero infrastructure to manage and a clean UI for your whole team.