Skip to main content

​
Do-Not-Originate (DNO) Caller-ID Blocking

A Do-Not-Originate (DNO) list holds the numbers that must never appear as a calling-party number (the caller ID you present on an outbound call). Numbers on such a list are invalid, unallocated, or inbound-only — spoofed government, bank, or IRS lines; inbound-only toll-free; unassigned ranges. Originating a call with one of these as the from number is the spoofing pattern that regulators (CTIA, FCC robocall mitigation, ITG traceback) and carrier KYC audits ask about first. Orbit runs a DNO check at origination time, before dispatch: after the caller ID is resolved and validated as an active tenant-owned number, it hard-rejects any from matching a DNO entry with 422 VOICE_DNO_BLOCKED. The list is yours to curate — the platform ships it empty by default, because there is no universally-safe DNO set, and a bad default would block legitimate caller IDs.
DNO is a tenant-owned protective control. Orbit does not mandate a DNO posture and does not populate your list. An empty list (the default) makes the check a cheap no-op, so existing tenants are unaffected until you opt in. This page is not legal advice.

​
1. The three-layer model

The effective DNO set for your organization reconciles a platform baseline with a per-organization override: The override enabled flag must be the literal boolean true; missing, malformed, or false entries are ignored and the env baseline alone applies.

​
2. Choose a mode: extend, replace, or subtract

The override harmonizes with your baseline in one of three modes: Prefer extend unless you have a specific reason to cut the platform baseline out of the set or need to carve back one entry.

​
3. Configure the override

Only workspace owners and admins can write this. Over the API, send a PUT /api/v1/settings/general payload carrying the voice.dno_override object:
  • enabled — must be true for the override to take effect.
  • mode — extend (default), replace, or subtract.
  • numbers — DNO entries. Entries are normalized: only + and digits are retained, so 800555 and +1 800 555 both canonicalize. Unusable entries are discarded rather than polluting the set.
The same shape is writable in the dashboard under the organization’s voice settings section.

​
4. How matching and failure behave

  • Prefix matching: matching is a prefix comparison, not exact-match. A full E.164 entry (+18005551212) blocks only that number; a shorter entry (+1800555) blocks an entire unallocated or inbound-only range. One semantic covers both the specific-spoofed-line and whole-range cases.
  • Fail-open on lookup error: if the organization-settings lookup fails (a transient blip), the gate falls back to the env baseline rather than blocking every outbound call. An empty resolved list makes the check a no-op.
  • Reject: a match throws 422 VOICE_DNO_BLOCKED:
For triage of this and sibling codes, see Troubleshooting: voice destination and emergency blocks.

​
5. Worked example — inbound-only toll-free spoofed

An org keeps an 800-series of inbound-only toll-free numbers. Spoofers are using them as caller ID, damaging the org’s reputation.
  1. The owner/admin adds those toll-free prefixes to the DNO list:
  1. A robocaller presenting +18005550199 as the caller ID is rejected with 422 VOICE_DNO_BLOCKED before any SIP dispatch. The matched_prefix in the response identifies the entry that fired.
  2. The next step is the caller-ID allowlist on the trunk or dialer: only verified numbers the org owns should be presented.

​
6. Where it sits in the pre-dispatch chain

DNO is one of the voice pre-flight gates. Ordering:
  1. Caller-ID resolution and ownership validation — the from number is resolved and validated as active.
  2. DNO check — rejects a forbidden calling-party before any billing hold or dispatch.
  3. Billing hold / dispatch — only reached after DNO passes.
On the customer-trunk path, the trunk caller-ID allowlist (VOICE_CALLER_ID_REJECTED) runs in parallel — both gates protect the caller-ID identity independently. DNO rejects pre-dispatch like the emergency short-code block, not post-dispatch like the per-destination auto-blocks.

​
7. Tenant-ownership framing

Compliance is the tenant’s responsibility; Orbit is the conduit. DNO is a tenant-owned protective control: the platform ships it empty deliberately so no default blocks a legitimate caller ID. You opt in, you curate, you own what gets listed. The resolved set exists at origination time only for the check — it is not a persistent posture register. STIR/SHAKEN attestation is weakened when the caller ID is unprovable, so DNO pairs with attestation: block spoofable numbers at origination, present numbers you own so the carrier can attest A.

​
See also

​
8. Where to source DNO numbers

The platform ships your list empty by design, so the bootstrap question is where to get a starting set. Standard sources:
  • FCC Robocall “Do-Not-Originate” collection points (US). The FCC’s robocall-mitigation docket requires voice-service providers to mitigate calls from invalid, unallocated, or unused numbers, and from numbers on a published DNO list. Industry SPOKE points are published by the provider community and refreshed as spoofed government, bank, and IRS lines are identified. Seed with these.
  • Country equivalents. Canada (CRTC/CTIA-equivalent guidance), the UK (Ofcom / industry DNO lists), and Australia (ACMA) publish own collections. If you originate into several countries, source one list per country and merge them into your override — a US-only list leaves the rest of your originating destinations unprotected.
  • Partner-aggregator feeds. Many carriers maintain a curated DNO feed as part of their number-intelligence or fraud-mitigation service; ask for the feed in a plain format (one number per line with the + is fine) and import it. Treat the feed as a starting point, not the final posture — you keep curating it as your own spoof-bait numbers surface.
  • Your own numbers. Your inbound-only ranges, unassigned allocations, and honeypot numbers belong on the list. Own-spoofed callers ID-carry a disproportionate share of traceback requests.
A source feeds your curation, not your default. The platform baseline stays empty; you opt into every entry you import — no feed is silently activated on you. See the glossary DNO term below for how the canonical collection points fit together.

​
9. Format and schema for entries

The numbers array accepts the following entry shapes. Entries are normalized on write — only + and digits are retained; punctuation is stripped; unusable entries are discarded rather than polluting the set. There is no separate wildcard syntax — a shorter prefix is the wildcard. A +1 block catches every US/Canada number; +4420 catches all London (020) numbers. Keep the asymmetry in mind when you scope entries: the longer the entry, the narrower the block.

​
10. Sync cadence and bulk import

Two patterns hold up in production:
  • Scheduled refresh — a cron job on your side fetches the feed(s) and re-PUTs the exact shape under Section 3 on a daily or weekly cadence. The update is a full-list PUT, so schedule it as build the new list → PUT → verify rather than incremental delta pushes; a failed verification loops back to the last-known-good list instead of a partial one.
  • Manual push — an owner/admin edits the list in the dashboard’s voice settings or via one PUT /api/v1/settings/general call. Suitable for a stable list that changes rarely.
Feed-driven cadence is daily, staggered (see Section 11): a new spoofed range appears in a published source within hours, and you want the gate to reflect it before the first originating attempt.

​
11. Timezone and stagger

When you wire a scheduled refresh, stagger the run time across tenants to avoid thundering-herd API spikes and allow one list revision to soak before the next fleet-wide push in a federation scenario. The refresh itself is UTC-safe — the voice origin-time DNO check is routing-only and has no timezone component. Related failed lookups fall back to the baseline as described in Section 4.

​
12. Audit trail

Every change to dno_override lands in your organization’s audit log with actor, timestamp, and the before/after snapshot of the list — you can answer “who added this entry and when” from the compliance audit surface, and you can export the audit log to SIEM. Use the attestation posture page for tying a DNO entry to the caller-ID ownership evidence it unblocks.

​
13. Posture — opt-in by design

The DNO gate is deliberately empty-by-default and opt-in. “The list is yours to curate” carries an operational meaning: the platform does not import a default set, a replace-mode override can cut the env baseline out entirely, and a missing/malformed override falls back to the env baseline rather than silently blocking. Your feed is never activated on you; the empty default is what makes the gate a cheap no-op for tenants who have not opted in.