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 comentarios

7 comentarios

  1. 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.
  2. 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.
  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 (editado)
      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 (editado)
      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 (editado)
      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