Sending Throttling Strategies — Pace Your Volume in AcelleMail

Why throttle#

Receiving servers throttle senders that spike. The math:

• Sustained 5,000/hour for 30 days → normal traffic; clean reputation
• 50,000 in 10 minutes → spike alarm; receivers throttle or temp-block

A throttle = AcelleMail enforces a max-rate on its outbound queue. Each receiving server sees you arriving at a steady cadence rather than a flash.

Configure throttle per-server#

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:

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:

Where the throttle lives#

Same sending-server detail → Configuration section. The Sending limit dropdown caps how many emails AcelleMail will hand to this server per unit of time (per minute / hour / day):

AcelleMail enforces the limit globally — when the rolling-window counter hits the cap, the queue holds back until the window slides. No throttling code in your campaigns; configure once per server.

The dropdown options typically include:

100 emails per 1 minute
500 emails per 1 minute
1,000 emails per 1 minute
500 emails per 1 hour
5,000 emails per 1 hour
50,000 emails per 1 hour
5,000 emails per 1 day
50,000 emails per 1 day
Unlimited

Pick based on volume target + IP maturity.

4 throttling patterns by scenario#

Pattern A: New IP warmup (Day 1)#

Sending limit: 100 emails per 1 hour
Daily ramp:    +50% each day
Target:        Day 30 = full volume

Low rate, steady through the day. Pairs with engaged-segment-first audience selection (see IP warmup schedule).

Pattern B: Mature IP at scale (steady-state)#

Sending limit: 50,000 emails per 1 hour OR Unlimited
Burst:         Spread campaign launches across day (multiple smaller campaigns instead of one mega-blast)
Quota:         Daily cap matches vendor's published quota

At >100k/day, you're past warmup. Throttle still acts as a circuit-breaker — if a runaway campaign accidentally enqueues 1M sends, the per-hour cap prevents the burst from happening all at once.

Pattern C: Multi-vendor split#

Server A (SES):       30,000 emails per 1 hour (long-running)
Server B (Postmark):  10,000 emails per 1 hour (warming)
Server C (Mailgun):    5,000 emails per 1 hour (warming)

AcelleMail's dispatcher rotates across all three, but per-server caps prevent any single one from being overloaded. Combined: 45k/hour aggregate; per-server limits matched to each server's reputation maturity.

Pattern D: Burst-friendly transactional + steady marketing#

Server T (transactional):  Unlimited (login emails, password resets must send immediately)
Server M (marketing):       5,000 emails per 1 hour (steady)

Two separate Plans, one server each. Transactional bypasses throttle (low volume, high priority). Marketing throttled to keep reputation clean.

When to step up vs step down#

Common UI signals + fixes#

Throttle interaction with batch sending#

AcelleMail's send pipeline batches messages. The throttle applies at the per-message level (queue-handler picks a server, rate-limits its own picks).

For example: throttle = 5,000/hour. Campaign with 10,000 recipients:

• 0:00 — first 5,000 dispatched
• 1:00 — second 5,000 dispatched
• Total time: ~1 hour

For 100,000 recipients at 5,000/hour: ~20 hours. Either raise the cap or add a second server.

Multi-server throttle aggregation#

When you have 3 servers in a pool, each with its own cap:

Server A: 5,000/hour
Server B: 5,000/hour
Server C: 5,000/hour

Total throughput = 15,000/hour. Round-robin distribution means each server hits its own cap, then queue fills the next batch.

If one server caps out, the dispatcher routes to the others until they also cap; then everyone waits for the next window. AcelleMail handles this automatically — no manual intervention needed.

// In sending-server admin advanced config (some installs expose this)
'rate_limits_by_domain' => [
    'gmail.com'  => 1000, // per hour
    'outlook.com' => 500,
    'yahoo.com'  => 300,
    'icloud.com' => 200,
    'default'    => 5000,
],

curl -X PATCH "https://acellemail.com/api/v1/admin/sending-servers/{server_uid}" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -d '{
    "sending_limit": 1000,
    "sending_limit_period": "minute"
  }'

# Cron: 09:00 — bump to weekday daytime rate
curl -X PATCH ... -d '{"sending_limit": 20000, "sending_limit_period": "hour"}'

# Cron: 22:00 — cut to overnight rate
curl -X PATCH ... -d '{"sending_limit": 2000, "sending_limit_period": "hour"}'

First 5 minutes:  3000/min (push the first thousand recipients immediately)
Next 15 minutes:  1500/min
After that:       100/min (steady drip)

Marketing campaign: 5,000/hour, sent to engaged-30d segment only
Re-engagement campaign: 1,000/hour, sent to inactive-90d segment only

Related articles#

• Email throttling and rate limits explained
• IP warmup schedule for new sending servers
• Configuring multiple sending servers
• Multi-server rotation pattern