Skip to main content

​
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.
This guide covers the dashboard surface. Compliance and carrier registration requirements for sender IDs live under Compliance → Sender ID registration.

​
What the hub consolidates

The hub groups six tabs, each channel-specific: 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 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