Amazon SES Deliverability: A Complete Guide for Engineering Teams

Amazon Simple Email Service (SES) is one of the most reliable and cost-effective mailer services available. However, while AWS manages the physical servers and network performance, you are responsible for your own sender reputation and inbox placement. If you treat Amazon SES as a simple black-box API, your critical notifications and campaigns can easily end up in the spam folder.

Keeping your sending health high requires understanding how email sent from your infrastructure is evaluated by receiving ISPs. This guide provides a detailed technical reference for engineering and DevOps teams managing Amazon SES deliverability at scale.

What SES Deliverability Actually Means

To build a reliable email architecture, you must distinguish between your delivery rate and your inbox placement rate.

• Delivery Rate (what SES measures): This is the percentage of messages that do not result in a hard or soft bounce. If Amazon SES hands the message to Gmail's incoming servers and Gmail accepts it, SES marks the message as "Delivered."
• Inbox Placement (what SES does not measure): This is where your message actually lands after it is accepted. It could land in the primary inbox, the promotions tab, or the spam folder.

AWS SES cannot tell you if your message went to spam. ISPs like Google and Microsoft do not send back a receipt saying "accepted but routed to junk." To understand your actual inbox placement, you must combine SES metrics with external signals like Google Postmaster Tools, which provide domain-specific insights into how spam filters view your traffic. Understanding what are esps (Email Service Providers) and how they protect users from junk is the first step in mastering this distinction.

Authenticate Every Message: SPF, DKIM, and DMARC

Every domain sending mail through SES must be properly authenticated. Without explicit authentication, your messages lack cryptographic proof of ownership, leading to issues like outlook mail not sending or messages getting flagged immediately.

SPF (Sender Policy Framework)

An SPF record is a TXT record on your DNS that defines which IP addresses are authorized to send mail for your domain.

• The Trap: A common mistake is configuring an spf record a record pointing directly to your web servers while forgetting to include the AWS SES mechanisms.
• SES Implementation: When sending through SES, your envelope-from domain (Mail-From) defaults to amazonses.com. To achieve SPF alignment, you must configure a custom Mail-From domain (e.g., mail.yourdomain.com) in your SES console and add the corresponding MX and SPF records pointed at AWS.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to the message headers, verifying that the body and key headers have not been altered in transit.

• Easy-DKIM vs. Custom DKIM: We strongly recommend using Easy-DKIM in AWS SES. It automatically handles key rotation using three CNAME records provided by AWS.
• Key Strength: Always use 2048-bit DKIM keys. Legacy 1024-bit keys are increasingly deprecating across major inbox providers.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together. It tells receiving servers what to do if a message fails SPF or DKIM checks.

• Alignment: For DMARC to pass, either your SPF or your DKIM domain must match the "From" header domain visible to the recipient.
• The Progression: Do not jump straight to a strict policy. Start with monitoring and progress slowly:

1. p=none (Monitor mode: monitor reports for 2 to 4 weeks to identify legitimate legacy systems or third-party integrations).
2. p=quarantine (Soft fail: suspect messages are routed to spam; run for 2 to 4 weeks).
3. p=reject (Hard fail: unauthorized messages are completely blocked).

BIMI (Brand Indicators for Message Identification)

BIMI displays your official brand logo next to your emails in supported inboxes. To deploy BIMI, you must have a DMARC policy of p=reject or p=quarantine (at 100% pct), and you generally need a Verified Mark Certificate (VMC) from an approved certificate authority.

Warm Up New Sending Identities

ISPs are suspicious of sudden spikes in email volume from new domains or IP addresses. If you send 50,000 emails on day one from a fresh domain, spam filters will flag your activity as a potential typo email campaign or malicious botnet activity.

Domain vs. IP Warm-up

• Domain Warm-up: Focuses on building reputation for your sending domain. This is critical even if you use shared IPs.
• IP Warm-up: Specifically designed to build reputation for a dedicated IP address. If you use the standard shared SES IP pool, you do not need to warm up the physical IPs, but you still must ramp up your domain-level volume.

Recommended Volume Ramp Schedule

If you have a clean list of active users, use this conservative day-by-day volume target to warm up your sending identity:

If you ramp too fast, you will experience temporary deferrals (rate limiting) or find your emails routed directly to the spam folder.

Shared vs. Dedicated IPs in SES

When sending through AWS SES, you must choose between using the shared IP pool, dedicated IPs, or Managed Dedicated IPs.

• Shared IPs: Highly cost-effective and pre-warmed. They are ideal for senders with low volumes (under 100,000 emails per month) or highly inconsistent sending schedules. However, your reputation is shared with other AWS customers.
• Dedicated IPs: Best for high-volume senders (over 300,000 emails per month) who want complete control over their IP reputation. You are responsible for the initial warm-up and maintaining consistent daily volume to prevent the IP from cooling down.
• Managed Dedicated IPs: An SES feature that automates IP warming and scale-out logic. AWS manages the warm-up process and dynamically allocates dedicated IPs based on your current sending volume.

Configuration Sets Are Not Optional

A configuration set in Amazon SES is a group of rules that you apply to your emails to track events. Sending without a configuration set means you are running blind, unable to associate bounce or complaint events back to specific campaigns, users, or codepaths.

Setting Up Event Destinations

You must configure your configuration set to forward events to a downstream service:

• Amazon SNS (Simple Notification Service): Best for real-time alerting and immediate webhooks.
• Amazon Kinesis Data Firehose: Best for streaming granular event data directly to an S3 bucket or an external data warehouse.
• Amazon CloudWatch: Best for high-level metric tracking and dashboarding.

At a absolute minimum, configure your configuration set to publish SEND, DELIVERY, BOUNCE, and COMPLAINT events. Ensure your applications attach this configuration set header to every single API request.

Monitor Bounce and Complaint Rates

AWS SES maintains strict limits for bounces and complaints. Exceeding these limits will result in AWS putting your account under review or suspending your sending capabilities entirely.

Infrastructure Safeguards

To prevent hitting these limits, you must understand your active suppression landscape. Review the AWS SES suppression list limitations to understand how account-level suppression behaves.

Because AWS will not warn you until you are close to the threshold, you should build an automated SNS alerting pipeline that alerts your engineering team long before AWS takes action. For a deep dive into setting up this pipeline, read our guide on how to fix AWS SES bounce and complaint rates and configure your team's AWS SES email alerting rules.

Virtual Deliverability Manager (VDM)

Virtual Deliverability Manager (VDM) is an optional, native SES capability designed to help you optimize email delivery. While standard SES dashboards only show broad account-level rates, VDM provides detailed visibility into campaign and message-level delivery statistics.

• What VDM Tracks: It offers automated advice on configuration issues (such as SPF/DKIM misalignment), highlights ISPs that are actively throttling or blocking your mail, and provides aggregate open and click metrics without requiring you to build a custom tracking redirect engine.
• Is it worth it? For high-volume senders, the operational insights easily offset the small per-message fee. For smaller teams, VDM data is a helpful starting point, though it lacks the custom programmatic action triggers that external systems offer.

List Hygiene

No mailer service can save you from a dirty list. You must maintain clean recipient data to protect your sender reputation.

• Hard Bounces: If a mailbox does not exist, remove the address from your active records immediately. Never retry a hard bounce.
• Soft Bounces: Temporary failures (e.g., mailbox full). Implement a policy to suppress the address if it soft-bounces more than three consecutive times within a 14-day window.
• Unsubscribe Compliance: Provide a clear, one-click unsubscribe footer in all marketing and automated messages. Process these unsubscribes programmatically within 24 hours to comply with CAN-SPAM and GDPR regulations.
• Inactive Subscribers: Regularly run re-permissioning campaigns or sunset subscribers who have not opened an email in over 180 days.

Segment Your Traffic

Never send transactional emails (like password resets) and marketing emails (like newsletters) from the same IP address or domain identity. If a marketing campaign triggers a high complaint rate, your password reset emails will land in spam, blocking users from logging in.

The Subdomain Strategy

Isolate your sending reputations by separating your domains:

• Transactional: notify.yourdomain.com (using a high-priority configuration set and shared or high-reputation IP pools).
• Marketing/Campaigns: news.yourdomain.com or mail.yourdomain.com (using marketing-specific configuration sets and dedicated IPs if volume permits).

This separation ensures that a sudden drop in marketing deliverability has zero impact on your critical product alerts.

SES Sending Limits and Production Access

All new AWS SES accounts start in the sandbox environment. While in the sandbox, you can only send to verified email addresses, your daily volume is limited to 200 messages, and your sending rate is restricted to 1 message per second.

Requesting Production Access

To move to production, you must submit an SES production access request via the AWS Support Center. In your ticket, explicitly detail your sending practices, how you compile your recipient list, how you handle bounces and complaints, and how users opt in.

To prevent an unexpected AWS account review or sending pause:

• Request limit increases at least 7 days before any expected high-volume event.
• Proactively monitor your current sending limits using the SES dashboard or API to ensure your application code never hits a rate-limiting throttle error.

Reading SES Reputation Signals

To stay on top of your deliverability, keep a close eye on the following dashboards and telemetry systems:

• SES Console Reputation Dashboard: Your primary view for account-level bounce and complaint rates.
• AWS Personal Health Dashboard: Where AWS publishes official notifications regarding service degradations or impending account reviews.
• Google Postmaster Tools: The absolute gold standard for tracking domain reputation, IP reputation, and spam rate metrics specifically for Gmail recipients.

Common SES Deliverability Failures: Diagnostic Table

If your deliverability takes a hit, use this table to quickly diagnose and fix the issue:

A Code-First Approach to SES Operations

Maintaining a healthy Amazon SES setup requires constant vigilance, from managing configuration sets to monitoring suppression lists and processing unsubscribes. While setting up custom AWS Lambda functions and CloudWatch alarms can keep things operational, it often leads to an ongoing maintenance burden for engineering teams.

For a complete understanding of what you should monitor, check out our guide on AWS SES observability. If you prefer to stop building manual SES monitoring pipelines and want a full email marketing and operations platform that runs on top of your existing AWS account, learn how SendOps Observability can manage the operational layer for you, keeping your engineering team focused on your core application code.