Email Throttling & Rate Limits Explained — What's the Difference

Throttling, rate limiting, sending limit, quota. Different terms, sometimes overlap. This guide separates them: who enforces each, where AcelleMail applies them, what each is good for.

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:

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

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

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

8 コメント

コメント 5 件

  1. sofia.costa.pt
    This is the clearest IP warmup schedule I've found. The volume table at the top is what I'm referencing daily.
  2. linhpm.devs
    confirming the Postmaster Tools data lag — sometimes 48 hours, sometimes longer. Dont make decisions on a single day's data
  3. d.cohen.tlv
    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
      we tested this with up to 1M subscribers on a $40/mo VPS. Past that you start needing query optimization. Below that, the defaults are fine.
    2. admin (編集済み)
      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 👀
  4. emma.whitaker
    the postmaster tools section is gold. most senders don't even know it exists
  5. ravi.kumar.del…
    Bookmarked. Going to share with the team — we've been winging warmup and it shows in the numbers.
    1. admin
      thanks for the kind words. we try to keep these source-grounded so they age well...

More in Sending & Deliverability