How to improve email deliverability with AWS SES
Table of Contents
In our previous article on the fundamentals, we covered why this topic matters for your email strategy. Now let us dive into the technical implementation details that separate successful email programs from those that struggle with deliverability.
The Technical Architecture
When you send emails through AWS SES, you are leveraging Amazon's massive email infrastructure. But with great power comes great responsibility. SES provides the pipes, but you are responsible for what flows through them.
Understanding the Email Lifecycle
Every email you send goes through multiple stages:
- Composition: Your application creates the email
- Submission: The email is sent to SES
- Processing: SES validates and queues the email
- Delivery: SES attempts to deliver to the recipient
- Feedback: The receiving server responds
- Event Processing: You handle bounces, complaints, and other events
Each stage presents opportunities for things to go wrong, and each requires proper handling.
Setting Up Your Infrastructure
Before you can effectively manage your email operations, you need the right foundation.
DNS Configuration
Your domain needs proper DNS records:
SPF (Sender Policy Framework)
``
v=spf1 include:amazonses.com ~all
`
This tells receiving servers that Amazon SES is authorized to send email on your behalf.
DKIM (DomainKeys Identified Mail)
AWS SES provides DKIM signing automatically, but you need to add the CNAME records to your DNS. This cryptographically signs your emails, proving they have not been tampered with.
DMARC (Domain-based Message Authentication)
`
v=DMARC1; p=quarantine; rua=mailto:[email protected]
``
This tells receiving servers what to do with emails that fail authentication checks.
SNS Notifications
AWS SES uses SNS (Simple Notification Service) to send you feedback about your emails. You need to configure notifications for:
- Bounces: When an email cannot be delivered
- Complaints: When a recipient marks your email as spam
- Deliveries: Confirmation that email was accepted (optional but useful)
Handling Bounces
Bounces are emails that could not be delivered. They come in two types:
Hard Bounces
These are permanent failures. The email address does not exist, the domain is invalid, or the recipient has blocked you specifically.
You must stop sending to hard bounced addresses immediately.
Continuing to send to addresses that hard bounce will:
- Damage your sender reputation
- Trigger rate limiting from SES
- Eventually get your account suspended
Soft Bounces
These are temporary failures. The recipient mailbox is full, the server is temporarily unavailable, or there is a transient network issue.
Soft bounces can be retried, but you should:
- Limit retry attempts (3-5 is typical)
- Use exponential backoff
- Convert to hard bounce after repeated failures
Handling Complaints
When a recipient clicks the spam button in their email client, you receive a complaint notification. This is serious.
The 0.1 Percent Rule
AWS SES expects your complaint rate to stay below 0.1 percent. For every 1,000 emails you send, no more than 1 person should mark you as spam.
This sounds easy until you do the math:
- Send 100,000 emails per month
- Allowed complaints: 100
- If you hit 150 complaints: warning
- If you hit 500 complaints: account review
Immediate Suppression
When you receive a complaint, that email address should be immediately added to your suppression list. Never email them again. This is not just best practice, it is required by most email regulations including CAN-SPAM and GDPR.
Monitoring and Alerting
You cannot manage what you do not measure. Set up monitoring for:
Key Metrics
- Bounce rate: Should be under 2 percent
- Complaint rate: Should be under 0.1 percent
- Delivery rate: Should be above 95 percent
- Send volume: Track for anomalies
Alerting Thresholds
Configure alerts when:
- Bounce rate exceeds 1 percent
- Complaint rate exceeds 0.05 percent
- Send volume drops unexpectedly
- SES quota usage exceeds 80 percent
Scaling Considerations
As your email volume grows, new challenges emerge:
Rate Limiting
SES has sending limits. New accounts start at 200 emails per 24 hours. You need to request limit increases as you grow.
Queue Management
At high volumes, you cannot send emails synchronously. You need:
- A message queue (SQS, Redis, etc.)
- Worker processes to send emails
- Rate limiting to stay within SES limits
- Retry logic for failures
A Better Approach
What if this infrastructure was already built and maintained for you? What if bounce handling, complaint processing, and suppression lists were automatic?
This is exactly what purpose-built email platforms provide. Instead of building and maintaining this infrastructure, you focus on what matters: creating content and growing your audience.
See how MailsFly does this automatically: How MailsFly maximizes inbox placement
