Every message SendOps sends — a [Broadcast](/sending-email/broadcasts), a [Drip Workflow](/workflows/overview) send, or a send triggered over the API — runs through the **same consent model** before it goes out. This page is the conceptual map: how mailability is decided, what a topic is, the two consent lanes, and the recommended pattern for onboarding and other lifecycle mail. It's the "why" behind the topic-less warning you see on a broadcast and the `transactional` keyword you can put on a workflow send.

## Membership is not mailability

Being in a List or matching a Segment only decides whether a contact is a **candidate** for a send. Whether they actually receive it is decided separately, at the moment of each send, by two tiers of consent:

- **Account tier — always applies.** Anyone **suppressed** (a hard bounce or a spam complaint) or **globally unsubscribed** is dropped. Nothing bypasses this tier — not even transactional mail.
- **Topic tier.** Anyone who has opted out of the **topic** this send belongs to is dropped.

A send that clears both tiers is **mailable**; the rest are recorded as **filtered**, tagged with the tier and reason, so your [broadcast results](/sending-email/broadcasts#results--who-got-it-and-who-didnt) and [workflow run timeline](/workflows/sends-and-approval) always explain the gap between "the audience was 1,000" and "940 were sent."


  Consent isn't frozen when a contact enters an audience or a workflow — it's evaluated at the instant each message is about to go out. A contact who unsubscribes mid-journey is quietly skipped for the next send while their journey continues.


## Topics are opt-out streams

A **topic** is a named stream of mail a recipient can leave on its own — "Product updates," "Weekly digest," "Onboarding." Topics are what make an unsubscribe **granular**: someone can stop your newsletter without stopping every email you send.

Every marketing send should name a topic. If you send **with no topic**, the unsubscribe link on that message can only do one thing — opt the recipient out of **everything** (an account-wide unsubscribe). One click on one newsletter then silences *all* your future mail to that person, and because there's no granular opt-out it's also worse for deliverability and compliance. SendOps makes you explicitly acknowledge this before it will send a topic-less marketing message.

You can brand and reword the page recipients land on from the [Unsubscribe Page](/sending-email/unsubscribe-page) settings. Topics are managed under [Audience › Topics](/audience/topics) — created in the dashboard, via the API, or as code alongside your other git-backed audience definitions.

## Two consent lanes: marketing and transactional

Not all mail is marketing. A password reset, an order receipt, or a welcome email is **transactional** — the recipient is expecting it as part of using your product, and it shouldn't be gated behind a marketing opt-out. SendOps models this as a send's **consent lane**:

| | **Marketing** (default) | **Transactional** |
|---|---|---|
| What it's for | Newsletters, announcements, re-engagement | Onboarding, receipts, password resets, account notices |
| Topic tier | Enforced — a topic opt-out drops the send | **Exempt** — bypasses the topic and no-topic gate |
| Account tier (suppression / global unsub) | Enforced | **Still enforced** |
| Frequency cap tier (Drip Workflow sends only) | Enforced | **Still enforced — not exempt** |
| Topic-less send | Requires explicit acknowledgement; burns the account-wide unsubscribe | Allowed by design; still carries an always-on unsubscribe link |
| Who sets it | The default for every Broadcast | Only the workflow send path (a step or a template default) |

The important line: **transactional is topic-exempt, not consent-exempt.** A globally unsubscribed or suppressed contact is dropped from a transactional send exactly as from a marketing one, and every transactional message still carries an unsubscribe link. The [frequency cap](/workflows/sends-and-approval#frequency-cap) follows the same rule as the account tier, not the topic tier: it isn't a consent choice, so marking a send transactional doesn't exempt it — a workflow that must never be capped needs its own `frequency cap off`. Broadcasts are always marketing and have no frequency cap; only a Drip Workflow send can be marked transactional or be subject to a frequency cap.


  Don't mark marketing mail as transactional to dodge topic opt-outs. The lane exists for genuinely expected, one-to-one lifecycle mail. Misusing it drives spam complaints — which land in the account tier and suppress the contact for *everything*, transactional included — and puts your SES sending reputation at risk.


## Sending onboarding & transactional mail

In a [Drip Workflow](/workflows/overview), each `send` step chooses its consent lane through a simple precedence ladder, resolved at send time:

1. **`send "welcome" transactional`** — mark the step transactional (topic-exempt lifecycle mail).
2. **`send "digest" via topic "product-updates"`** — send in the marketing lane under a named topic, honoring that topic's opt-outs.
3. **`send "welcome"`** — bare send: inherit the **template's default**. A template with a transactional default sends transactional; otherwise its default topic is used.

```sendflow
workflow "New-signup onboarding" v1 {
  enter on activity.signup

  send "welcome-email" transactional
  wait 3 days
  send "getting-started-tips" via topic "onboarding"
}
```

Binding the lane to the **template** keeps authors from repeating it: set a template's default topic or mark it transactional once, and every bare `send "<that-template>"` inherits it. A bare send of a template that has *neither* a default topic nor a transactional default is a loud misconfiguration — the step fails rather than guessing.


  Welcome emails, verification, receipts, and account notices → **transactional**. Newsletters, announcements, and win-back campaigns → a **marketing topic**. When in doubt, ask whether a reasonable recipient would be surprised *not* to receive it; if they'd expect it, it's transactional.


See the [SendFlow reference](/workflows/flow-reference) for the exact `send` syntax and [Sends, consent & approval](/workflows/sends-and-approval) for how sends move through the pipeline, send windows, and the manual-approval hold.

## Activity ingest creates non-mailable stub contacts

Streaming [Activities](/audience/activities) is a great way to feed SendOps behavioral data — but it is **not** the same as building a mailable, consented audience. When you record an activity for someone SendOps has never seen, it creates a **stub contact** so the signal isn't lost:

- A stub is a lightweight record **stored only inside SendOps** (never pushed to SES) — **no SES contact is created**, no consent choice has been made, and it may have arrived with only an external ID (your own identifier) and no email address at all.
- A stub **counts in Segment rules** (`exists(activity.purchase)` will match it) and shows on the contact timeline — so behavioral targeting works immediately.
- A stub is **not mailable on its own**: a send still runs the full consent model above. A stub with no email address can't be addressed, and one that has never opted into the topic you're sending under won't clear the topic tier.

The takeaway: *"I sent an activity for this person"* does **not** mean *"I can email them."* To turn behavioral signals into mail, the contact still needs a real email address and the right consent — either imported with your roster, upserted through the [Contacts API](https://developers.sendops.dev/api-reference/contacts), or reached with a **transactional** send if the message is genuinely lifecycle mail they expect.


  - [Broadcasts](/sending-email/broadcasts) — one-time bulk sends and how consent is enforced per recipient.
  - [Sends, consent & approval](/workflows/sends-and-approval) — the workflow send pipeline end to end.
  - [Activities](/audience/activities) — recording behavioral signals and using them in rules and triggers.
  - [Unsubscribe Page](/sending-email/unsubscribe-page) — branding the page recipients land on.