A **broadcast** is a one-time bulk email — a newsletter, an announcement, a product update — sent to a [List](/audience/lists) or a [Segment](/audience/segments) at a moment you choose. Unlike the transactional mail your app sends one message at a time, a broadcast goes to a whole audience at once, with consent enforced for every recipient.

Broadcasts live in the **Broadcasts** area of the SendOps dashboard.

## What a broadcast ties together

Every broadcast brings three things together:

- **Audience** — the [List or Segment](/audience/lists) you're sending to. When the send begins, SendOps **freezes the audience to a snapshot**, so the send goes to exactly who matched at that moment — later changes to the List or Segment don't affect a send already under way.
- **Template** — the email to send, pinned to a specific **version** so the same broadcast always renders the same way. The broadcast owns the **subject**; the template owns the body.
- **Merge data** — the per-recipient values the template fills in (a recipient's first name, say), plus **defaults** for anyone who's missing a value.

### How merge data resolves

Each placeholder in your template fills in **by name**:

- If the placeholder's name matches one of your [contact attributes](/audience/attributes) (for example `first_name`), each recipient gets their own value.
- Where a contact has no value, the broadcast's **default template data** fills the gap.
- Anything still unresolved renders blank.

The **Preview** panel shows this before you send: for every placeholder it tells you how many recipients resolve from their attributes, how many fall back to a default, and how many would render blank — plus a sample render. Previewing changes nothing; it's a dry run over your real audience.



## Consent is enforced at send

Membership is not the same as mailability. A contact can be in your audience and still not receive a broadcast, because SendOps applies your **consent rules** at send time:

- **Account-level** — anyone suppressed (a hard bounce or complaint) or globally unsubscribed is dropped.
- **Topic-level** — anyone who opted out of this broadcast's **topic** is dropped.

These drops are recorded, so your [results](#results-who-got-it-and-who-didnt) explain the gap between "the audience was 1,000" and "940 were sent."


  A **topic** is the opt-out stream a broadcast belongs to — "Product updates," "Weekly digest," and so on. It lets a recipient leave **one** kind of email without leaving them all.

  If you send a broadcast with **no topic**, its unsubscribe link can only do one thing: opt the recipient out of **everything** you send (an account-wide unsubscribe). One person clicking "unsubscribe" on a single newsletter then stops *all* your mail to them — and because there's no granular opt-out, it's also worse for **deliverability and compliance**. SendOps makes you explicitly acknowledge this before a topic-less send. Wherever you can, give the broadcast a topic instead. You can brand and reword the page recipients land on from the [Unsubscribe Page](/sending-email/unsubscribe-page) settings.


## Sending and scheduling

A broadcast moves through a few states:

| State | Meaning |
|---|---|
| **Draft** | Being composed. Editable. |
| **Scheduled** | Set to fire at a future time. Still cancellable. |
| **Sending** | The send is in progress. |
| **Sent** | Every recipient was handed off to SES successfully. |
| **Partially failed** | The send finished, but one or more recipients failed. This is a normal outcome, not an error — open the results to see which, and why. |
| **Cancelled** | A draft or scheduled broadcast you cancelled before it sent. |

You can **send now** or **schedule** a broadcast for later; a scheduled broadcast fires automatically at its time. A send in progress can't be cancelled mid-flight.

### Test send

Before committing to the whole audience, use **Test send** to deliver the real, fully-rendered email to a handful of addresses you name. A test send uses the exact template, merge, and delivery path the real send uses — so what you see is what your audience will get — but it ignores the audience and the consent filter (you're sending to yourself on purpose) and never changes the broadcast's counts or state.

## Results — who got it, and who didn't

Once a broadcast sends, its detail page reports the outcome per recipient:

- **Sent** — accepted by SES for delivery.
- **Failed** — SES rejected it, with a reason.
- **Filtered** — dropped by the consent filter before send, tagged with the tier (account-level suppression/unsubscribe, or topic opt-out) and the reason.

The **summary** makes the funnel explicit: the audience size, the **mailable** count (those who passed consent), and the sent / failed / filtered split. The filtered rows are what explain the difference between how big the audience was and how many were actually sent.




  Broadcasts aren't dashboard-only: with an API key, an integration can **create and send** a broadcast as well as read one. It picks a List or Segment audience, supplies the content as either a SendOps **template** (plus merge data) or **raw inline HTML**, and sends now or on a schedule — and SendOps still applies your tracking, suppression, consent filtering, and unsubscribe handling exactly as it does for a dashboard send. This is how external tools (the first is **Adze**, which drafts product-update emails from your GitHub releases) send through SendOps. See the [Broadcasts API reference](https://developers.sendops.dev/api-reference/broadcasts).