What Broadcast is and how sending works

Before you install anything, it helps to know which jobs Broadcast does and which jobs it hands to other services. After this lesson you can explain where your email goes after you click Send, and why some email arrives before other email.

Broadcast manages, your provider delivers

Broadcast is the software you run on your own server. It keeps your subscribers, builds your emails, runs your automations, and records what happens to each message. It does not deliver mail to inboxes itself.

For delivery, you connect an email provider, such as Amazon SES, Postmark, SendGrid or Mailgun, or any SMTP server. Broadcast hands each message to that provider, and the provider delivers it. Broadcast calls each connection an email server.

This split matters for two reasons:

1. Your sending reputation lives with your provider account and your domain, not with Broadcast. If you change tools later, you keep it.
2. Your cost to send is your provider’s price. Broadcast adds no per-email fee.

The choose an email provider guide compares the options. You connect one in lesson 5.

Channels hold everything

Inside Broadcast, the main unit is the channel. Other tools call this a list. Each channel has its own subscribers, email servers, sender details, templates, forms and reports. Nothing leaks from one channel to another.

One installation can run many channels. A common setup is one channel per newsletter or per brand. You create your first channel the first time you open the dashboard. See Channels for the details.

Three types of email

From a channel you send three types of email:

1. Transactional emails: one email to one person, sent through the API. A login code, a password reset or a receipt.
2. Sequences: automated emails sent step by step to each subscriber who enrolls. A welcome series is the classic example.
3. Broadcasts: one email sent to many subscribers at once. A newsletter.

Broadcast also sends a few emails of its own through your email servers, such as opt-in confirmation emails and test sends.

The priority order

The three types always go out in the same order: transactional emails first, sequences second, broadcasts last.

The reason is what each email costs you when it is late. A login code that arrives after ten minutes is a support ticket. A newsletter that arrives after ten minutes is fine. So when several sending jobs wait, a worker takes the one with the highest priority first. Broadcast also keeps one worker thread for transactional email only, so a login code never waits behind a long broadcast job.

The hourly limit

Every email server has an emails per hour limit. The default is 200 and the lowest value is 15. You set it in Settings → Email Servers. Set it to your provider’s real quota: too low makes broadcasts slow, too high lets the provider refuse your mail.

The hour is a rolling window. Broadcast counts the emails the server sent in the last 60 minutes, and it never sends above the limit. Every email counts, including tests and confirmation emails.

When a server sends more than one type of email, the lower-priority types stop before the full limit. On a server that sends all three types, broadcasts stop at 80% of the limit and sequences at 90%. The rest is kept for the email that matters most. At the default of 200, a broadcast sends up to 160 emails in the hour.

What happens to a large broadcast

Say you send to 1,000 subscribers through that server. Broadcast sends the 160 that fit. Then the broadcast waits. It does not hold a worker while it waits, and it stays in the Sending status. As old emails leave the hourly window, it sends again, until everyone has it. You do not need to do anything.

If a server is full, its email waits for room on that server. Broadcast does not move it to another server. This is why the docs recommend two servers: one for broadcasts, and one for transactional email and sequences. Then a newsletter never uses the room your login codes need.

Each recipient gets a broadcast once

Immediately before Broadcast hands an email to the provider, it records that this recipient’s send has started. Every later attempt checks that record. So a restart, a retry or a crash in the middle of a send cannot mail anyone twice. After a restart, a broadcast continues from where it stopped.

The full rules, with the reserve table and the Pause and Resume behaviour, are in How sending works.

What you learned

• Broadcast manages your list and your email. Your email provider delivers it.
• A channel holds its own subscribers, servers and settings.
• Transactional email goes first, then sequences, then broadcasts, inside each server’s hourly limit.
• A large broadcast sends what fits, waits for room, and continues by itself without duplicates.