Amazon SES + AcelleMail — Setup, Sandbox, Production Mode

Amazon SES is the cheapest reliable sending option at scale — $0.10 per 1,000 emails. This guide walks the AWS-side setup (verify domain, request production), the AcelleMail-side config, and the gotchas (sandbox mode, region pinning, dedicated IP option).

Why SES (and when not)

Pros Cons
$0.10 per 1,000 emails (cheapest reliable option) Sandbox-by-default; production mode is a request away
Solid deliverability with proper config Per-region quota; cross-region orchestration needed for global scale
Native AWS — easy IAM + VPC + CloudWatch Email-only; no built-in landing-page hosting like ConvertKit/Klaviyo
Dedicated IP option at $24.95/mo per IP Initial 200/day sandbox cap is the slowest of all major ESPs

Use SES if: large volume (>1M/mo), already on AWS, willing to do the sandbox-to-production workflow. Skip if: <50k/mo (Postmark's free tier is easier), or you need a managed all-in-one platform (Mailchimp/Klaviyo).

Setup overview — 4 phases

[AWS side]                          [AcelleMail side]
1. Verify domain (DNS records)
2. Request production mode
                                     3. Add SES sending server
                                     4. Test + go live

Total time: 1-2 hours active + 24h waiting for AWS production approval.

Phase 1: Verify your domain in AWS

Log into the AWS Console → SES (in your chosen region, e.g. us-east-1 / eu-west-1):

  1. Configuration → Verified identities → Create identity
  2. Choose Domain
  3. Enter your sending domain (e.g. mail.example.com)
  4. AWS shows DNS records: 3 CNAME records for DKIM + (optional) MX for Easy DKIM
  5. Add these CNAMEs at your DNS host
  6. AWS polls; once propagated (~5-30 min) status flips to Verified

Per AWS region. If you'll send from multiple regions, repeat in each region.

Phase 2: Request production mode

By default SES is in sandbox mode: only sends to verified addresses, 200 emails/day cap. Production mode = unlimited (within quota): any recipient, default 50k/day.

  1. SES → Account dashboard → Request production access
  2. Form: use case description, expected volume, complaint/bounce handling process
  3. AWS reviews in 24-48 hours

Be honest about volume + use case. AWS rejects requests that look like spam (e.g. "buy a list and send marketing without unsubscribe").

Phase 3: Add the server to AcelleMail

Open the sending-server detail

In AcelleMail's sidebar, click Sending → Sending servers. The list shows every server connected to this account with its status chip, sending limit, and last activity:

Customer sending-server list

Click into the row you want to configure. The detail page surfaces Connection settings (host / credentials), Configuration (server name, default from, sending limit, bounce + FBL handler), and the Test connection / Send test email buttons in the toolbar:

Server detail — Connection + Configuration

For the SES setup specifically:

Pick the SES type

Type selector:

Type selector

Choose either:

  • Amazon SES (API) — uses SES SendEmail API (recommended; faster, better tracking)
  • Amazon SES (SMTP) — uses SES SMTP relay (compatible with vendor-neutral setups)

Most installs pick API mode.

Fill the SES config

The Amazon SES (API) create form:

Amazon SES API create form — Access Key + Secret + region

For SMTP-typed SES (the alternative integration), the form looks like:

Amazon SES SMTP create form

Either way, the create form asks for:

Field Where to get it
AWS Access Key ID IAM → Create user → AmazonSESFullAccess policy (or custom restricted)
AWS Secret Access Key Generated alongside Access Key
AWS Region The region you verified your domain in (e.g. us-east-1)
Default from email An address on your verified domain

Save. AcelleMail probes the credentials immediately — see Active badge or inline error.

Verify the SPF/DKIM/DMARC chips

After saving, the server detail page shows the auth status:

Sending server with auth chips

  • SPF should be Green if your domain's SPF record includes include:amazonses.com
  • DKIM should be Green if your AWS-side CNAME records are propagated (Phase 1 step 5)
  • DMARC should be Green if your domain publishes a DMARC policy (separate from SES — set up at your DNS host)

If any chip is Red, click Verify domain in the toolbar for the DNS-fix wizard.

Phase 4: Test send + go live

Run the diagnostic from the toolbar:

Send test modal

Sends a real message via SES to whatever address you specify. Check your own inbox — message arrives within seconds. If sandbox-mode-still-pending, the test will fail with "Email address not verified."

After successful test, attach the SES server to your plan and launch a small campaign. Validate metrics in the campaign report:

Campaign tracking log

Region pinning for global sends

If your audience is global, choose region(s) based on recipient locations:

Audience region SES region recommendation
US-heavy us-east-1 (Virginia) — best AWS-global integration
EU-heavy eu-west-1 (Ireland) or eu-central-1 (Frankfurt) — GDPR data residency
APAC-heavy ap-southeast-1 (Singapore) or ap-northeast-1 (Tokyo)
Truly global Multi-region setup — verify domain in 3 regions, add 3 sending servers in AcelleMail, route per recipient via custom logic

Common UI signals + fixes

Symptom Likely cause UI fix
New SES server status Testing indefinitely Wrong region selected Edit credentials → match the region where you verified your domain
Test send fails "Email address not verified" SES still in sandbox mode Request production mode at AWS → wait 24h
Production approved but still 200/day cap Per-account quota; AWS raises gradually Send daily at the cap for a week; AWS auto-raises if metrics clean
DKIM chip Red after 1 hour DNS CNAMEs not propagated yet Wait up to 24h; if still red, verify CNAMEs at your DNS host
Bounce rate high (5%+) on first day SES is sensitive to bounce — auto-suspends accounts above 5% Pause; clean list; resume slowly
Complaint rate >0.1% SES auto-pauses accounts at 0.1% Pause; audit consent + content; SES sends recovery instructions
All emails arrive but tracking shows opens at 0% SES open tracking requires Configuration Set Enable via AWS Console → Configuration → Configuration Sets
Advanced: dedicated IP pool, Configuration Sets, and IAM least-privilege

Dedicated IP setup:

For >5M emails/month, dedicated IP gives full control over reputation:

  1. AWS SES → Dedicated IPs → Request new dedicated IP ($24.95/mo per IP)
  2. Wait ~1-2 days for provisioning
  3. AcelleMail-side: no config change needed; SES automatically routes your sends via the dedicated IP

For dedicated IP pools (multiple IPs for rotation), use SES Configuration Sets:

Configuration Set: "production-marketing"
  Dedicated IP pool: [ip1, ip2, ip3]
  Tracking: enabled (open + click)
  CloudWatch destination: enabled

Configuration Set: "production-transactional"
  Dedicated IP pool: [ip4]
  Tracking: disabled (transactional doesn't need engagement tracking)

In AcelleMail, set the SES Configuration Set in the server's advanced config (admin-side only). Different campaigns automatically use different IP pools.

IAM least-privilege policy:

The default "AmazonSESFullAccess" policy is overkill. Restricted alternative:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ses:SendEmail",
      "ses:SendRawEmail",
      "ses:GetSendQuota",
      "ses:GetSendStatistics"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "ses:FromAddress": "noreply@example.com"
      }
    }
  }]
}

Limits AcelleMail's IAM user to send-only operations from a specific from-address. If the credentials leak, the blast radius is contained.

CloudWatch + bounce/complaint webhooks:

AWS publishes bounces + complaints to SNS topics. Subscribe:

  1. SNS → Create topic "ses-bounces"
  2. SES → Configuration Sets → [your set] → Event destinations → Add SNS
  3. SNS → Subscriptions → Add HTTP endpoint pointing to AcelleMail's bounce webhook

AcelleMail receives bounce + complaint events in real-time, updates subscriber statuses immediately, removes hard-bounced addresses automatically.

SMTP vs API decision tree:

Want native bounce/complaint webhook from AWS?      → API
Want minimum config, vendor-neutral?                → SMTP
Sending from Wordpress / WHM / non-Acelle?         → SMTP (works without AWS SDK)
High volume, want CloudWatch metrics?               → API
Want to use Configuration Sets?                     → API

For AcelleMail specifically: API. The SDK gives full event-stream access; SMTP is more limited.

Multi-region orchestration:

If you've verified in us-east-1 + eu-west-1 + ap-southeast-1:

  1. Add 3 sending servers in AcelleMail, one per region
  2. Use subscriber tags to mark recipient region (tag:us, tag:eu, tag:apac)
  3. Create 3 Plans, each scoped to a single regional server
  4. Assign campaigns to the right plan based on segment

End result: US recipients send from us-east-1 (lowest latency to US ISPs), EU from eu-west-1 (GDPR data residency), APAC from ap-southeast-1.

Related articles

13 comments

7 comments

  1. v.petrova.ru
    This is the clearest IP warmup schedule I've found. The volume table at the top is what I'm referencing daily.
  2. phuong.mai.hn
    We hit a Spamhaus listing once. Self-service delisting was actually fast (< 24h) but the reputation recovery took weeks. Not the listing itself that hurt — the user complaints that caused it.
  3. tranminh.devop…
    bookmarked. Going to share with the team — we've been winging warmup and it shows in the numbers.
  4. hung.nguyen.it
    Does engagement-based segmentation help during warmup? E.g. only sending to the most-engaged 20% during week 1? anyway
    1. admin
      Good question — and one that comes up often enough we should add an FAQ section. Short answer: yes for the common case; the exception is when you're running custom plugins that override the default behavior
  5. cmendoza.mx
    We warmed up a dedicated IP last fall. The 2-week ramp this article describes is on the aggressive side — Gmail in particular punishes anything faster than ~3-4 weeks. We did 4 weeks and had a clean ramp.
    1. admin
      thanks for the numbers. worth pulling into a follow-up post on volume-tier sizing.
    2. admin (edited)
      Solid case study material here. If you're open to it, we'd love to write this up as a blog post — happy to credit you anonymously or otherwise.
    3. admin (edited)
      Useful context. The fact that it took 3 weeks end-to-end is realistic; we sometimes get pushed to say 1-week timelines and theyre not honest.
  6. linhvu.dev
    confirming the Postmaster Tools data lag — sometimes 48 hours, sometimes longer. Don't make decisions on a single day's data.
  7. bos.devops
    For very low-volume senders (< 5k/month), does warmup even matter? Or just send and let the provider's shared pool absorb the trickle?
    1. admin
      honest answer: it depends on your provider. SES handles it gracefully; Mailgun is stricter. We'll add a provider-by-provider table in the next revision.
    2. admin (edited)
      For your specific case, I'd recommend testing with `--dry-run` first. The behavior under high load isn't 100% deterministic and we want you to see your own pattern before committing

More in Sending & Deliverability