> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Run your senders from the Audience → Senders hub

> Manage sender IDs, email sending domains, sending streams, RCS senders, from-address defaults, and inbound email routing from one consolidated dashboard surface.

# The Audience → Senders hub

Every identity you send from — SMS sender IDs, email sending domains, RCS senders, and the fallback from-address — lives under one dashboard surface: **Audience → Senders** (`/audience/senders`). Instead of jumping between settings pages, you register, verify, and audit senders in one place, with a tab per channel type.

<Note>This guide covers the dashboard surface. Compliance and carrier registration requirements for sender IDs live under [Compliance → Sender ID registration](/compliance/sender-id-registration).</Note>

## What the hub consolidates

The hub groups six tabs, each channel-specific:

| Tab                     | What it manages                                                                                                                                      |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sender IDs**          | Alphanumeric sender IDs, registered short codes, and brand IDs for SMS, WhatsApp, and voice channels, with per-channel default toggles.              |
| **Domains**             | Email sending domains tied to your tenant, with DNS (SPF / DKIM / DMARC) status and deliverability history per domain.                               |
| **Sending streams**     | Named reputation and throttle partitions (transactional vs marketing, or per sub-brand) so a complaint spike on one stream never drags down another. |
| **RCS**                 | Verified RCS agents ("bots") that act as the branded sender behind every RCS send, plus the channel's built-in SMS fallback contract.                |
| **From-email defaults** | The per-workspace fallback from-address, from-name, and reply-to used when an email send carries no explicit sender.                                 |
| **Inbound routes**      | Inbound email forwarding rules — map a recipient pattern to a destination URL (SendGrid Inbound Parse / Mailgun Routes parity).                      |

Tabs are URL-synced through `?tab=`, so you can deep-link a teammate straight to a tab — for example `/audience/senders?tab=domains`.

## How to use a tab

The pattern is the same across tabs:

1. Open **Audience → Senders** and pick the tab for the channel type you're working on.
2. Click the tab's add action (**Add sender ID**, **Add sending domain**, **Create stream**, and so on) to open the create dialog.
3. Complete the verification the row asks for — DNS records for a domain, provider registration for a sender ID, or the documented onboarding for RCS.
4. Watch the status badge on the row. Rows move through a lifecycle (e.g. **Pending → Approved / Rejected** for sender IDs, DNS check states for domains); sends stay gated until the row is approved/verified.
5. Use the per-row menu (⋯) to **Edit**, **Set as default**, or **Delete**. Only rows you own are editable — the platform-default sending domain renders at the top of the Domains tab and can't be removed.

### Blank and error states

An empty tab shows a first-run empty state ("Add a custom sending domain", etc.) with the add action — that means zero of your own senders exist, not that something failed. If the list itself can't load, a distinct retryable error banner appears above the cards so a permission or server problem isn't masked as "no senders yet." Not-enrolled channels (RCS disabled by feature flag, for example) render the channel's standard not-enrolled message rather than a broken table.

## Sender ID vs Domain onboarding — which to request

The two requests solve different problems:

* **Sender ID request** — you need a recognizable *name or number* as the `from` on SMS/WhatsApp/voice sends (e.g. an alphanumeric ID like `ACME` where the market requires registration). Use the **Sender IDs** tab and follow [Sender ID registration](/compliance/sender-id-registration) for the market-by-market rules.
* **Domain onboarding** — you need to send *email* from your own domain with correct SPF/DKIM/DMARC. Use the **Domains** tab, add the domain, publish the DNS records shown on the domain detail page, and wait for the DNS checks to pass.

If you operate both SMS and email, you typically need one of each — the hub exists so both live in one list instead of separate settings pages.

### When to add a sending stream

Within email, add a **Sending stream** when you want transactional mail insulated from bulk/marketing mail — each stream carries its own reputation and throttle, so a marketing complaint spike can't degrade password-reset delivery.

## Real examples from the hub

* **Register an SMS sender ID**: Sender IDs tab → **Add sender ID** → choose the channel (SMS / WhatsApp / voice) and enter the alphanumeric value, or attach a registered short code. The row sits at **Pending** until the provider approves it, then flips to **Approved**; a **Rejected** row shows why. Mark it default-for-channel with the row toggle so new sends pick it automatically.
* **Onboard an email domain**: Domains tab → **Add sending domain** → enter `mail.example.com`. Open the domain card to see the exact DNS records to publish and the per-record check status; the same page carries deliverability history and a test send once checks pass.
* **Set the fallback from-address**: From-email defaults tab → set the default address, display name, and reply-to. The address must belong to one of your verified sending domains — the server rejects a fallback that doesn't, so off-list values fail loudly instead of silently dropping sends.
* **Route inbound email**: Inbound routes tab → create a rule mapping a recipient pattern (e.g. `support@example.com`) to a destination webhook URL. The signing secret for verifying forwarded payloads is shown exactly once at creation — store it before closing the dialog.
* **Check your RCS sender**: RCS tab lists each verified RCS agent with its lifecycle classification and the SMS fallback behavior campaigns rely on.

## See also

* [Sender ID registration](/compliance/sender-id-registration) — market rules and required documents
* [Sender pools](/guides/sender-pools) — rotate across several registered senders
* [Import contacts](/guides/import-contacts) — the Audience hub's other entry point