Email Server Rate Limits
Each email server has an emails per hour limit that caps how many messages Broadcast will send through it in a rolling one-hour window. This protects your provider account from exceeding its allowance and helps maintain deliverability. When a server reaches its limit, Broadcast holds the remaining emails and sends them when the hour has room again. Some of the limit is kept for transactional emails and sequences (see below). For the whole picture, see How Sending Works.
Use a separate server for broadcasts
We recommend that you use one email server for broadcasts, and a separate email server for transactional emails and sequences.
A large broadcast uses the hourly limit of its server. It also affects the reputation of that server, because a newsletter gets more unsubscribes and spam complaints than a password reset does. If your login codes, password resets and receipts go through the same server, they can wait behind the broadcast until the hour has room again. They can also go to spam because of complaints about the newsletter. Email providers keep these two kinds of email apart for the same reason. For example, Postmark sends transactional and broadcast email on separate infrastructure.
To set this up:
- Open Settings → Email Servers.
- On the first server, under Email Types, tick only Broadcasts (manual campaigns).
- Add a second server. Under Email Types, tick Transactional emails and Automated sequences (Drip style emails).
- Give each server its own emails per hour value.
Each server in Broadcast has its own hourly limit, so a broadcast cannot use up the limit of the transactional server.
At your provider, put the two servers on separate streams or sub-accounts when the provider supports it. For example, use a separate Postmark server or message stream, or a separate AWS SES configuration set. Both servers can use the same provider account if the provider does not offer this.
Which email goes first
Broadcast sends three types of email, in this order of priority:
- Transactional emails
- Sequences
- Broadcasts
The order applies to which job runs first, and to the hourly limit. One worker is always kept for transactional email, so a large broadcast cannot hold up a password reset.
Room kept for transactional emails and sequences
On a server that sends more than one type of email, a broadcast does not use the full hourly limit. Broadcast keeps some of the limit for the types of email that come first. A server keeps room only for the email types it sends.
| The server sends | Broadcasts stop at | Sequences stop at | Transactional emails stop at |
|---|---|---|---|
| Broadcasts, sequences and transactional emails | 80% of the limit | 90% | 100% |
| Broadcasts and transactional emails | 90% | 100% | |
| Broadcasts and sequences | 90% | 100% | |
| Sequences and transactional emails | 90% | 100% | |
| One type only | 100% | 100% | 100% |
For example, a server with the default limit of 200 emails per hour that sends all three types:
- Broadcasts send up to 160 emails in the hour.
- Sequences can send at least 20 more, up to 180.
- Transactional emails can send at least 20 more, up to 200.
A server that sends only broadcasts keeps no room, so broadcasts can use the full limit. This is the main reason to use a separate server for broadcasts. The email server form and the server page show these numbers for your own limit.
How a large broadcast is sent
A broadcast that fits in the room left in the hour sends at full speed.
A broadcast that is larger than the room left sends what fits. Then it waits, and it continues by itself as room becomes free in the hour. It never goes above the limit, also when several broadcasts share one server. While it waits, its page shows Waiting for room on the email server and the time of the next send.
Transactional emails at a full limit
When a server is at its full hourly limit, a transactional email waits:
- Broadcast tries to send it again every minute.
- At the first wait, Broadcast sends the
email.send_delayedwebhook event. - After 30 minutes of waiting, every page of the channel shows a notice.
- After 24 hours, Broadcast stops. It marks the email as failed with the reason “Email server at hourly limit: no room for 24 hours, giving up”, and sends the
email.failedwebhook event.
A transactional email waits only when the server is at 100% of its limit. Broadcasts and sequences stop earlier, so they do not cause this wait on their own.
A sequence step that meets a full limit waits too. It tries again every minute, and it does not count as a failed step. The enrollment shows Waiting for room on the email server since a time.
Viewing the rate limit
Open Settings → Email Servers and select a server. The Rate Limiting section of its detail page shows the configured hourly limit, how many emails have been sent in the current window, how much of the limit each email type can use, and the broadcasts that are waiting for room on this server.

To change the hourly limit itself, edit the email server and update its emails per hour value.
Resetting the rate limit
If a server has hit its limit and you need sending to resume right away (for example, after your provider raises your allowance, or you’ve confirmed it’s safe to continue) click Reset rate limit. You’ll be asked to confirm.
Resetting moves the counting window forward to now, so only emails sent after the reset count toward the limit. A broadcast that is waiting for room on this server starts sending again at once. Your historical send records are preserved: the reset only changes where the hourly count starts from.
Note: Resetting the rate limit doesn’t raise the limit or change your provider’s own throttling. If you regularly hit the cap, raise the server’s emails per hour value (within your provider’s allowance) instead of resetting repeatedly.