Skip to main content

​
The Audience → Senders hub

Every identity you send from lives under one dashboard surface: Audience → Senders (/audience/senders). Sender IDs, email sending domains, sending streams, RCS agents, the fallback from-address, and inbound email routes share a tab-per-channel registry with URL-synced deep links, so you can register a sender, watch its verification state, and point a teammate at the exact row.
This guide covers the dashboard surface. Regulatory pre-registration requirements for sender IDs (where a market requires registration and which documents it demands) live under Compliance and are yours to meet as the sending tenant — the hub is where you hold and operate the registered senders, not where market rules are decided.

​
What the senders hub holds

The hub groups six tabs. The two you touch most — the unified sender registry for messaging and the email domain registry — come first: The remaining four tabs close out the surface: Sending streams (streams) partitions email reputation (transactional insulated from bulk), RCS (rcs) lists verified RCS agents with their SMS fallback contract, From-email defaults (from-email-defaults) sets the per-workspace fallback address, and Inbound routes (inbound-routes) maps recipient patterns to webhook destinations. Tabs are URL-synced through ?tab=, so a deep link resolves directly — send an operator straight to /audience/senders?tab=domains instead of narrating clicks.

​
Registering an email domain sender

The Domains tab is the registry. Registering a sender is a two-step handshake — claim the domain in Orbit, then prove you own its DNS:
  1. Open Audience → Senders → Domains and click Add sending domain. Enter the domain you’ll send from (a subdomain such as mail.example.com keeps marketing mail off your corporate root).
  2. Open the new domain’s card. The per-domain page shows the exact DNS records to publish — SPF, DKIM, DMARC, and the return-path record — with a per-record check status that polls as DNS propagates.
  3. Publish the records at your DNS provider, then return to the card. The row moves to Verified when the SPF/DKIM/DMARC triad resolves. If DNS is green but the provider hasn’t accepted the domain yet (a Provider setup incomplete warning appears), the card surfaces an inline Verify now action that re-point checks registration without leaving the list.
  4. Once verified, add the from-addresses you actually send as. One verified domain supports several senders (noreply@, support@, sales@) — each renders as its own card with its own default toggle, so you can address recipients from a role address instead of a bare domain.
  5. Mark the card Set as default when you want new sends to pick it up automatically.
The full DNS handshake — record types, propagation timing, warm-up, and what to check before your first send — is covered end to end in the Email channel lifecycle guide. The platform-default domain (orbit.devotel.io) renders at the top of the list for low-volume use; it’s Devotel-managed, already signed, and can’t be edited or deleted.

​
Registering an SMS / WhatsApp sender-id

The Sender IDs tab is the counterpart registry for messaging. The difference from email: you send from a name (alphanumeric ID) or a number, and whether you must register it before the first send depends on the destination market — not on Orbit.
  1. Open Audience → Senders → Sender IDs and click the request action. Pick the channel (SMS, WhatsApp, or another messaging channel) and enter the alphanumeric ID or brand ID you want recipients to see.
  2. The row enters Pending. Two things have to happen before it gates open: any provider-side registration the channel requires, and any market-level pre-registration the destination countries demand. A Rejected row shows the reason inline.
  3. When the row flips to Approved, toggle it default for channel so new sends pick it up without an explicit sender.
  4. Before you commit a campaign to it, run Test delivery: the sender-id delivery check confirms the ID arrives correctly on real carrier networks, so a carrier that silently overrides unregistered IDs shows up in testing rather than in your delivery rate.
Which markets force pre-registration (and which accept a dynamic sender outright) varies per country and changes the lead time you need — the Sender-ID pre-registration matrix is the per-market authority. Registration itself is a tenant-owned compliance obligation; Orbit surfaces the state per sender but doesn’t gate your sends on it.

​
Reputation monitoring in the hub

Sender reputation isn’t a separate console — it’s read off the same registry rows, per sender:
  • Domains: each domain card carries a live DNS status roll-up (Verified / Needs review / Failing) plus the provider sendability verdict, and deep-links into the per-domain page where 30 days of DNS health, deliverability history, and a spam-score test send live. That per-domain history is the raw material the rest of the platform reads: degraded reputation on one domain shows up there before it shows up as complaints.
  • Sender IDs: per-row status (Pending / Approved / Rejected) tells you whether the identity is deliverable at all; the Test delivery check tells you whether it survives carrier filtering in practice.
  • Sending streams: streams exist precisely because reputation is per-partition — a marketing complaint spike on one stream can’t drag transactional mail down, and the hub is where you see which stream carries which reputation.
Reputation per sender feeds campaign-level deliverability directly: the pre-flight Deliverability Lab reads your send history and sender state to project per-carrier delivery before you send. Read the hub registry as the operational map — which senders are healthy, which are cooling, which need DNS attention — and the lab as the scoring layer on top of those senders.

​
Removing and rotating a sender

Senders are operational assets with a lifecycle — plan the exit when you plan the entry:
  • Removing an email sender: the row’s ⋯ menu → Delete removes that sender only. Other from-addresses on the same verified domain and the domain’s DNS records are untouched, so retiring marketing@example.com while keeping support@example.com is a single-row action. Decommissioning the domain itself means removing its senders and letting the DNS records lapse — re-verification later starts clean.
  • Rotating a sender-id: when a sender-id is revoked by a carrier or a regulator, or a registration lapses, add the replacement first (it starts at Pending), approve it, flip the default toggle, then remove the old row. Rotating the default before removing the old row keeps outbound sends from falling back to a bare numeric sender mid-rotation. For SMS/voice numbering rotation at scale, use a sender pool so rotation is a strategy, not a manual swap.
  • Domain decommission hygiene: a domain that leaves service should stop receiving mail too — remove it from inbound routes and from any email lifecycle suppression or tracking references, then delete the sender rows. Leaving a decommissioned domain in the registry invites sends to a DNS space you no longer control.

​
Worked example: mail.example.com + the ORBIT SMS sender-id

Put both halves together for a tenant launching marketing email + SMS under one brand:
  1. Email. Audience → Senders → Domains → Add sending domain → enter mail.example.com. Open the card, publish SPF / DKIM / DMARC at the DNS provider, wait for Verified. Add noreply@mail.example.com as the sending address and Set as default. Marketing mail now signs from your own domain; subdomain isolation keeps it off the corporate root.
  2. SMS. Audience → Senders → Sender IDs → request an alphanumeric ID ORBIT on the SMS channel. Check the country matrix first — if your launch markets pre-register, submit the documents before the campaign date, not during it. Wait for Approved, run Test delivery against your target carriers, then toggle default for channel.
  3. Operate. Both rows now sit in the same registry. Watch the domain card’s DNS roll-up and the sender-id’s status inline; score the campaign body in the Deliverability Lab before the first blast. When the SMS registration is revoked in a market, rotate: register the replacement, set it default, remove the revoked row.

​
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.

​
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.

​
See also