# Sending Throttling Strategies — Pace Your Volume in AcelleMail

> Blast 500k emails at once and you'll throttle yourself: receiving servers tar-pit you, your IP reputation drops, complaint rate spikes. AcelleMail's per-server sending limit lets you pace. This guide walks the UI + 4 throttling patterns by scenario.

- Canonical URL: https://acellesend.com/kb/articles/sending-throttling-strategies
- Author: Lena Hart, Email Deliverability Editor
- Category: Sending & Deliverability — SMTP setup, bounce handling, sender reputation, IP warmup, throttling
- Content type: tutorial · Difficulty: intermediate
- Tags: Acellemail
- Published: 2026-07-04 · Last updated: 2026-08-15
- Reading time: 7 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb

---

## 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:

![Customer sending-server list](https://acellesend.com/plugins/acelle/landing/images/help/kb/sending-servers/01-customer-server-list.png)

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](https://acellesend.com/plugins/acelle/landing/images/help/kb/sending-servers/02-server-detail-full.png)

### 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):

![Sending limit dropdown — 5,000 emails per 1 hour](https://acellesend.com/plugins/acelle/landing/images/help/kb/sending-servers/02-server-detail-full.png)

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](https://acellesend.com/kb/articles/ip-warmup-schedule-for-new-sending-servers)).

### 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

| Signal | Action |
|---|---|
| Day-after bounce rate <2%, sustained 7 days | Step up sending-limit by ~25% |
| Bounce rate creeping 3-4% | HOLD current cap; investigate before stepping up |
| Bounce rate >5% | Step DOWN cap by 50%; investigate root cause |
| Complaint rate <0.05% sustained | Cap acceptable; can step up |
| Complaint rate >0.15% | Step down cap; audit content + consent |
| Daily cap hit by noon every day | Cap too low for traffic; raise OR add second server |
| Daily cap never hit, sends complete at midnight | Cap too high relative to actual traffic; either fine OR reduce for safety |

## Common UI signals + fixes

| Symptom | Likely cause | UI fix |
|---|---|---|
| Campaigns queue but don't send during the day | Sending limit hit; rest is rate-paced into next window | Expected behavior; raise cap if too restrictive |
| Burst of 5,000 takes 30 minutes to dispatch | Throttle is working as designed | Lower per-minute cap if you want even slower; raise if you want faster |
| Sub-second between sends in tracking log | No throttle configured (Unlimited) | If reputation is concern, set a per-minute or per-hour cap |
| Daily cap shows 5,000 but campaign is queueing more | Multiple campaigns sharing the server pool; aggregate exceeded daily cap | Stagger campaign launches; OR raise daily cap |
| Single subscriber gets duplicate emails | NOT a throttle issue; usually retry-loop or queue bug | Investigate separately — see [Why is my campaign stuck](https://acellesend.com/kb/articles/why-is-my-acellemail-campaign-stuck-in-sending-status) |

## 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.

<details>
<summary><strong>Advanced: per-domain throttling, custom rate limits via API, and time-of-day patterns</strong></summary>

The server-level sending-limit applies to all outbound traffic. For per-recipient-domain throttling (e.g. "no more than 1000/hour to gmail.com specifically"), customize via:

**Per-domain limits in sending-server config:**

```php
// 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,
],
```

When the dispatcher needs to send to a domain that's hit its per-domain cap, it queues those addresses until the window slides.

**Custom rate-limit via API:**

For programmatic adjustment (e.g. when CloudWatch detects a reputation issue):

```bash
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"
  }'
```

Effects immediately on the next batch.

**Time-of-day pattern** — sending more during recipient business hours, less at night:

```bash
# 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"}'
```

For US-based audience: send during US business hours; cut volume during EU/APAC night-time. Result: highest-engagement windows get full volume.

**Burst-on-launch + steady-after pattern** — for campaign launches, the typical curve:

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

Get the engaged subscribers first (they open within minutes), then trickle the rest. Improves attribution + click-through optics in analytics.

**Per-segment throttling** — combine throttle with segment scope:

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

Different urgencies, different paces, different audience risk levels. Combined: clean reputation, predictable performance.

**Vendor-aware throttle alignment:**

| Vendor | Default cap | Recommended throttle |
|---|---|---|
| Amazon SES (production, default quota) | 50,000/day, 14/sec | Set to 12/sec to stay under |
| Postmark | 100,000/mo on free; varies on paid | Match to plan limits |
| SendGrid Free | 100/day | Set 50/day to stay safe |
| SendGrid Essentials | 50,000/mo | Match plan |
| Mailgun Flex | 5,000 free / scale paid | Match account quota |

Why under-shoot the vendor cap? Vendor enforces hard limits; AcelleMail's throttle is the soft layer. If vendor's hard limit hits, you get throttle errors from the vendor (delays + retries). If your AcelleMail-level cap hits first, you get clean queue-paced delivery.

</details>

## Related articles

- [Email throttling and rate limits explained](https://acellesend.com/kb/articles/email-throttling-and-rate-limits-explained)
- [IP warmup schedule for new sending servers](https://acellesend.com/kb/articles/ip-warmup-schedule-for-new-sending-servers)
- [Configuring multiple sending servers](https://acellesend.com/kb/articles/configuring-multiple-sending-servers)
- [Multi-server rotation pattern](https://acellesend.com/kb/articles/multi-server-rotation-pattern)

---

## Related articles

- [Feedback Loops (FBL) — Setup + Wire in AcelleMail](https://acellesend.com/kb/articles/feedback-loops-fbl-setup): When a recipient clicks "Mark as Spam" on a Microsoft / Yahoo / AOL / Comcast mailbox, those ISPs send you the complaint via Feedback Loop. AcelleMail processes it automatically — unsubscribes the complainer, updates the complaint stats. This guide walks the setup.
- [How to Set Up Amazon SES with AcelleMail](https://acellesend.com/kb/articles/configuring-amazon-ses-with-acellemail): Create an IAM user and access key in AWS, connect Amazon SES to AcelleMail, share your verified domains with users, and let them verify their own.
- [Amazon SES Sending Limits — Cookbook for AcelleMail Operators](https://acellesend.com/kb/articles/ses-sending-limits-cookbook): SES starts at 200/day sandbox, scales to 50k+/day in production, $0.10 per 1,000 emails. This guide is the practical cookbook: how to grow from sandbox to scale, region-by-region orchestration, what AcelleMail does at each tier.
- [Multiple Sending Servers in AcelleMail — Add, Mix, Route](https://acellesend.com/kb/articles/configuring-multiple-sending-servers): Spread your volume across several SMTP and API senders for failover, reputation isolation, and headroom past any single vendor's cap. This guide walks the real screens: the type picker, the connect form, the per-campaign "Use all servers" toggle, and the admin pool view.
- [Hard Bounce vs Soft Bounce — Reading the Bounce Log](https://acellesend.com/kb/articles/understanding-email-bounce-types): A hard bounce is permanent; a soft bounce is temporary. AcelleMail records them in the campaign bounce log and treats them differently — hard bounces blacklist the address, soft bounces are left alone for the receiving server to retry. This guide walks the bounce log, the DSN codes, and what each type means for your list.
