Email Throttling & Rate Limits — What's the Difference

Throttle, rate limit, sending limit. Different words, often confused. This guide separates them plainly — who enforces each — and shows the one control you actually set in AcelleMail: the per-server Sending limit.

What this is for

You've heard "throttle," "rate limit," and "sending limit" used like they mean the same thing. They don't. Two are something you set; the rest are decided by other people's servers. This guide draws the line clearly, then shows you the one control you actually have in AcelleMail — the per-sending-server Sending limit.

The two words people mix up

Throttle is your side. You decide to pace how fast AcelleMail hands messages to a sending server — say, no more than 1,000 emails an hour. It's a voluntary cap you set. If you hit it, the rest of your campaign simply waits in the queue and goes out as the window rolls forward. Nothing fails; it just spreads over time.

Rate limit is their side. The receiving mailbox provider (Gmail, Yahoo, a corporate mail server) decides how much mail it will take from you in a given window. You don't set this and you can't see the exact number — it's the provider's call, often tied to your reputation. When you bump into it, the receiving server temporarily defers your mail with a "try again later" style response, and AcelleMail retries on its normal schedule.

The short version:

Term Who sets it What happens when you hit it
Throttle (you, in AcelleMail) You Remaining mail queues, then sends in the next window — no failure
Rate limit (the receiver) Gmail / Yahoo / the recipient's mail server Receiver defers with a temporary "try later" response; AcelleMail retries

Everything else you might have read — vendor daily caps, per-domain throttling scripts — is either your email vendor's own contract limit (you manage that in your vendor's dashboard, not in AcelleMail) or behaviour on the receiving side that no email tool controls. The only knob that lives inside AcelleMail is the throttle, and it's called the Sending limit.

The one control you set: Sending limit

The Sending limit is set per sending server. Two servers can have two different limits — handy when you run a fast transactional server and a paced marketing one.

Open the sending-server detail

In AcelleMail's sidebar, click Sending → Sending servers. The list shows every server connected to this account, with its Sending limit, Status, and Created date:

Customer sending-server list

The Sending limit column tells you each server's current cap at a glance — for example 1,000 / hour, or Unlimited if no cap is set. Click the server name to open its detail page.

Server detail — Connection + Configuration

Set the limit

On the server's detail page, find the Configuration card and the Sending limit dropdown. It offers a short list of presets:

  • Unlimited — no pacing; AcelleMail sends as fast as the server accepts
  • 100 emails per 1 minute
  • 1,000 emails per 1 hour
  • 10,000 emails per 1 day
  • Custom — pick your own number and window

Choose Custom and three more fields appear: Per (the count), Every (how many time units), and Unit (Minute / Hour / Day). So "5,000 every 2 hours" is Per 5000, Every 2, Unit Hour. Click Save configuration.

That's the whole feature. AcelleMail enforces the cap for that server — when the rolling-window count reaches your number, the queue holds the rest until the window slides forward. You don't add anything to your campaigns; you set it once on the server.

When to set a limit (and when not to)

Situation Set a Sending limit?
Warming a brand-new IP or domain Yes — start low and raise it over days
Established server, steady volume Optional — leave it Unlimited, or set a cap as a safety brake
Big one-off campaign blast Yes — pace it so you don't dump everything in one spike
Transactional / password-reset server No — those need to go out immediately; leave it Unlimited
Several servers sharing the load Yes — a per-server cap divides the volume across them

A limit that's too low just makes campaigns crawl for no reason. A limit that's sensible protects a young IP and smooths out spikes. Match the number to what you actually send, not to a number that "feels safe."

Common issues

What you see What it means What to do
A campaign sends far slower than expected The server's Sending limit is set low Open the server → Configuration → raise the Sending limit (or set it to Unlimited)
Sends pause, then resume in bursts Normal — the rolling window filled up, then reset Nothing to fix; raise the limit only if the pace is too slow for you
Mail to one provider keeps getting deferred and retried That receiver is rate-limiting you (their side, not yours) This isn't a Sending limit problem — see the deliverability guides below; check bounces and reputation
The Sending limit column shows Unlimited and you wanted a cap No limit was ever set on that server Set one via the Configuration card and Save configuration

What to do after

  • Decide whether each of your servers should be capped or Unlimited, and set them in Sending → Sending servers.
  • If deferrals are coming from the receiving side, work the deliverability angle instead — start with bounce decoding and an incident runbook.
  • Spreading volume across more than one server? See the multi-server guides below.

Related articles

8 comments

5 comments

  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. emma.whitaker
    the postmaster tools section is gold. most senders don't even know it exists
  3. linhpm.devs
    confirming the Postmaster Tools data lag — sometimes 48 hours, sometimes longer. Dont make decisions on a single day's data
  4. 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 (edited)
      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 👀
  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