Amazon SES deliverability: sandbox, reputation metrics, IP warm-up

Amazon SES is cheap, fast and almost entirely unopinionated, which means the deliverability work that other platforms do for you is yours. Four things decide how SES sending goes: getting out of the sandbox correctly, authenticating so DMARC aligns, keeping bounce and complaint rates under the thresholds AWS acts on, and recording events before you need them.

The sandbox

Every new SES account starts in the sandbox, where you can only send to verified addresses or domains, at a capped rate — on the order of 200 messages per 24 hours and about one message per second. This is not a bug to work around; it exists so you cannot damage a domain's reputation while testing.

To leave it, open the SES console, go to *Account dashboard*, and request production access. The form asks for your use case, your list-acquisition method and how you handle bounces and complaints. Answer it precisely — vague answers get rejected, and "we purchased a list" gets rejected outright. Request access per AWS Region: SES reputation, quotas and sandbox status are per-Region, so moving from us-east-1 to eu-west-1 starts you over.

Authentication that aligns

Verify the domain, not individual addresses. In *Verified identities*, create a domain identity and enable Easy DKIM; SES gives you three CNAME records to publish, and it rotates the underlying keys for you. If you need to sign with your own keys, use Bring Your Own DKIM instead, and know that the rotation is then your job.

The step most SES setups skip: a custom MAIL FROM domain. By default the envelope sender is an Amazon domain, so SPF authenticates amazonses.com, not you, and SPF cannot contribute to DMARC alignment — only DKIM can. Set a MAIL FROM subdomain such as bounce.yourdomain.com on the identity, publish the MX record SES specifies for that subdomain plus the SPF TXT record, and you get both mechanisms aligned. The MX is required: SES uses that subdomain to receive bounce notifications.

Then publish DMARC on the organisational domain, starting at p=none with rua=, and read the reports before tightening.

The metrics AWS acts on

SES shows a bounce rate and a complaint rate on the *Account dashboard*, calculated across your recent representative volume rather than per campaign. The published thresholds: 5% bounce and 0.1% complaint put the account under review, and continued deterioration can lead to a sending pause. There is no appeal queue that moves at campaign speed, so treat these as hard operational limits:

SES also maintains an account-level suppression list of addresses that bounced or complained, so repeat sends are dropped before they reach the receiver. You can view, add and delete entries, and override the behaviour per configuration set. Check it before concluding that mail "disappeared" — a suppressed send looks like nothing happened.

Configuration sets and event destinations

This is the SES-specific trap: events are not recorded retroactively. If you send without a configuration set that has an event destination attached, the only data you keep is the aggregate on the dashboard. Set this up on day one:

1. Create a configuration set per stream — one for transactional, one for marketing, one per client if you run several.
2. Attach an event destination (SNS, Kinesis Data Firehose or CloudWatch) and subscribe to sends, deliveries, bounces, complaints, rejects and deliveryDelays.
3. Specify the configuration set on every send (the X-SES-CONFIGURATION-SET header over SMTP, or the API parameter).
4. Process bounces and complaints automatically. Hard bounces must be removed from your source system, not just suppressed in SES.

Virtual Deliverability Manager, if you enable it, adds an advisor that flags authentication and configuration problems plus per-ISP placement insight. It is billed separately; the dashboard metrics and event destinations are not.

Dedicated IPs and warm-up

SES's default shared pool is well maintained and right for most senders. A dedicated IP only makes sense with high, consistent volume — enough every single day to keep the IP's reputation fresh. If your volume is spiky, a dedicated IP will perform worse than the shared pool.

Two flavours exist. Managed dedicated IPs handle the ramp for you, moving traffic between shared and dedicated capacity as the IPs warm. Standard dedicated IPs give you the IP and an automatic warm-up mechanism with per-day limits; you can disable it and ramp manually if you are migrating an IP that is already warm elsewhere. Either way, register the IP with Microsoft SNDS and the JMRP, because that data is only available to the IP owner.

What not to do

• Do not send your first production campaign the day production access is granted. Ramp the domain over days.
• Do not ignore deliveryDelay events. Those are 4xx deferrals, the earliest warning that a receiver is throttling you.
• Do not share one configuration set across transactional and marketing mail — you lose the ability to tell which stream caused a complaint spike.
• Do not run SES in multiple Regions for redundancy without warming each one. Each Region is a separate sending identity to receivers.
• Do not use SES for cold prospecting lists. The bounce and complaint profile of cold data collides with the 5% and 0.1% thresholds, and the AWS acceptable use policy expects consent-based recipients.

MailPilot connects to SES over SMTP, so warm-up traffic takes the same path and carries the same DKIM signature as your production mail. It checks SPF, DKIM and DMARC on the sending domain, including MAIL FROM alignment, measures real inbox placement per provider through its seed network, and tracks reputation per mailbox daily — which is the signal SES's own dashboard cannot give you, because it stops at acceptance.