The 5 terms (clear definitions)#
| Term |
Where it's enforced |
What it does |
| Throttle |
AcelleMail-side |
You pace your outbound rate to receiving servers — e.g. 5000/hour. Soft cap, voluntary. |
| Rate limit |
Receiving server-side |
The receiver enforces a max rate per source IP/domain — typically 4.7.0 / 4.5.3 codes |
| Sending limit |
AcelleMail-side, configured per-server |
The specific UI setting that implements throttle in AcelleMail |
| Quota |
Vendor-side |
Daily/monthly cap your ESP imposes (e.g. SES = 50k/day production-default) |
| Tar-pit |
Receiving server-side |
Slow-down tactic: receiver accepts your connection but transmits slowly, slowing your overall throughput |
How they interact#
[AcelleMail]
│
│ Throttle (your sending limit, configured)
│ → applies to each outbound message
↓
[Vendor (SES/SendGrid/Mailgun)]
│
│ Quota (your contract with vendor)
│ → hard limit, can't exceed
↓
[Receiving servers]
│
│ Rate limit (per-IP, per-domain caps)
│ Tar-pit (intentional slow-down)
↓
[Recipient mailbox]
If you exceed AcelleMail's throttle: messages queue (no harm; sent next window).
If you exceed vendor quota: vendor rejects with 4.5.3 / quota-exceeded; AcelleMail retries until eligible.
If you trigger receiver rate limit: 4.7.0 / "try later"; AcelleMail retries.
If receiver tar-pits: throughput drops but messages still go through; might affect campaign completion time but not deliverability.
Where to set each in 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:

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.
| Term |
AcelleMail UI location |
| Throttle (sending limit) |
Sending server detail → Configuration → Sending limit |
| Quota |
Per-server, set to match the vendor's contract (e.g. 50k/day for SES) |
| Rate limit (receiver-side) |
NOT controllable in AcelleMail — receiver enforces |
| Tar-pit |
NOT controllable — receiver enforces |
Symptoms + what they mean#
| Symptom |
Cause |
Action |
| Campaign sends very slowly |
Throttle set too low |
Raise sending limit |
| All-or-nothing failures with 4.5.3 |
Vendor quota exceeded |
Wait for quota window OR upgrade vendor plan |
| Sustained 4.7.0 to one domain |
That receiver rate-limiting you |
Reduce send rate to that domain; possibly per-domain throttle |
| Mid-campaign slowdown |
Tar-pitting from a receiver |
Wait it out; usually self-resolves |
| All sends fail immediately on launch |
Throttle = 0 OR server disabled |
Check sending limit; check server status chip |
| Burst of 5000 → 100/sec then 0 |
Throttle window slid; cap hit |
Expected — wait for next window |
When to throttle vs not#
| Scenario |
Throttle? |
| New IP warmup |
YES — start very low, ramp daily |
| Established IP, normal traffic |
OPTIONAL — throttle as circuit-breaker |
| Burst marketing campaigns |
YES — pace launches to avoid spikes |
| Transactional/login emails |
NO — these need immediate send |
| Multi-vendor pool |
YES — per-server caps allocate volume |
| Compliance (GDPR-bound region) |
Sometimes — depending on data-residency throttle |
Common misuses#
| Mistake |
Fix |
| Throttle set arbitrarily low ("just to be safe") |
Match throttle to actual volume + vendor cap; aggressively-low slows campaigns unnecessarily |
| Same throttle on transactional + marketing servers |
Use separate servers, separate throttle policies |
| Throttle ignores vendor quota |
Even with throttle set, the vendor's quota is the harder limit; align them |
| Manual throttle adjustments based on customer complaints |
Tactical; not strategic. Use signals (bounce, complaint) to drive automation. |
Advanced: receiver-side rate-limit detection + adaptive throttling
You can't control receiver-side rate limits, but you can detect them and adapt.
Detecting receiver rate-limit:
-- Mining bounce log for rate-limit signals (last 7 days)
SELECT
SUBSTRING_INDEX(SUBSTRING_INDEX(email, '@', -1), '.', -2) AS domain,
COUNT(*) AS limit_signals
FROM bounce_logs
WHERE created_at >= NOW() - INTERVAL 7 DAY
AND (reason LIKE '%4.7.0%' OR reason LIKE '%try later%' OR reason LIKE '%4.5.3%')
GROUP BY domain
HAVING limit_signals > 100
ORDER BY limit_signals DESC;
If yahoo.com shows 500 limit signals while gmail.com shows 0, Yahoo is rate-limiting you specifically.
Adaptive throttling:
For domains showing rate-limit signals, dynamically adjust per-domain send rate:
#!/bin/bash
# Daily script: identify rate-limited domains + auto-reduce their send rate
for domain in $(get_rate_limited_domains_yesterday); do
current=$(get_acelle_domain_rate $domain)
new=$((current * 3 / 4))
set_acelle_domain_rate $domain $new
echo "Reduced $domain send rate: $current → $new"
done
Per-domain throttling is a custom feature; some installs expose it via admin UI, others via config file (config/sending-server.php).
Adaptive ramp-up:
For domains with clean signals, slowly raise the per-domain cap:
- Domain bounce rate < 1% in last 7 days → raise per-domain cap 20%
- Bounce rate 1-3% → hold cap
- Bounce rate >3% → reduce 25%
Run as a daily cron. Self-tuning across recipient domains.
Vendor quota alignment:
Match per-server sending-limit to vendor quota explicitly:
// Per-vendor quota mapping (illustrative — adjust to your contracts)
return [
'amazon-ses-api' => ['daily' => 50000, 'per_second' => 14],
'sendgrid-api' => ['daily' => 100000, 'per_second' => 30],
'postmark-api' => ['monthly' => 100000],
'mailgun-api' => ['monthly' => 10000, 'per_hour' => 500],
];
AcelleMail's per-server config should match the vendor's cap to avoid surprise 4xx errors mid-campaign.
Combined throttle + queue strategy:
For systems sending >1M emails/day across multiple vendors:
1. AcelleMail throttle: 30k/hour per server
2. Server-side queue: deep enough to hold 6 hours of full-speed sends
3. Worker count: scaled to match throttle (don't run 20 workers if cap is 5k/hr)
4. Vendor quota: 50k/day SES, 100k/day Postmark = 150k/day combined
5. Monitor: per-server hourly utilization; alert if any server hits cap consistently
Self-balancing system: throttle prevents bursts, queue absorbs spikes, workers stay busy without exceeding caps, vendor quotas don't get hit.
Related articles#