# Email Server Rate Limits

> Understand the per-hour sending rate limit on an email server, why broadcasts belong on their own server, and how to reset the rate-limit window so sending can resume.

Source: https://sendbroadcast.net/docs/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](https://sendbroadcast.net/docs/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:

1. Open **Settings → Email Servers**.
2. On the first server, under **Email Types**, tick only **Broadcasts (manual campaigns)**.
3. Add a second server. Under **Email Types**, tick **Transactional emails** and **Automated sequences (Drip style emails)**.
4. 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:

1. Transactional emails
2. Sequences
3. 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:

1. Broadcast tries to send it again every minute.
2. At the first wait, Broadcast sends the `email.send_delayed` webhook event.
3. After 30 minutes of waiting, every page of the channel shows a notice.
4. 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.failed` webhook 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.

![The Rate Limiting section of an email server showing emails per hour, emails sent in the current window, a rate-limit-reached note, and a Reset rate limit button](https://sendbroadcast.net/assets/docs/email-servers/email-server-rate-limit-2c4b6ba2.png)

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.