Do-Not-Originate (DNO) Explained — the Caller-ID Guard Against Spoofing

Quick answer: A Do-Not-Originate (DNO) list holds the numbers that must never appear as the calling-party number on an outbound call — invalid, unallocated, or inbound-only numbers that spoofers borrow to look legitimate. Presenting one as your caller ID is the exact pattern the FCC's robocall-mitigation rules and carrier KYC audits look for first. On Devotel Orbit, the DNO gate screens the resolved caller ID at origination time, before any SIP dispatch or billing hold, and hard-rejects a match with 422 VOICE_DNO_BLOCKED. The list ships empty by default on purpose — there is no universally-safe DNO set — and you opt in with extend, replace, or subtract override modes.

This post is the primer. The feature spec lives in Do-Not-Originate (DNO) Caller-ID Blocking; this walks through what a DNO list is, why the default-off posture is deliberate, and where the gate sits in the pre-dispatch chain.

What a DNO list actually is

Spoofers do not fabricate random digits. They borrow numbers that pass a quick plausibility check: a Washington government line, a bank's published customer-service number, an IRS fax-back line, an inbound-only toll-free range, or an unassigned allocation no one can call back. Any of those presented as your caller ID is illegal to originate in most jurisdictions — and it is the first thing regulators and carriers test for, because it is objectively checkable.

The US FCC robocall-mitigation framework makes this explicit: providers must take reasonable measures to prevent originating calls whose calling-party number is invalid, unallocated, or on a published Do-Not-Originate list, and must refuse transit for calls they cannot legitimately anchor. That is why carrier KYC audits and FCC Industry Traceback Group (ITG) requests ask about DNO before they get to quieter heuristics: your posture on origination-time screening is a binary, attestable question.

The fix on the originating side is to screen the calling-party number before the call leaves your account. On Orbit that check runs after the caller ID resolves to a number you own, and before dispatch:

• The from is resolved and validated as an active tenant-owned number.
• It is screened against the effective DNO set — platform baseline plus your organization override.
• A match returns 422 VOICE_DNO_BLOCKED with matched_prefix in the error details. No SIP is dispatched and no billing hold is placed.

Why the list ships empty

A DNO list you did not curate is a footgun. Short prefix entries overlap heavily with legitimate ranges, published feeds disagree with each other, and geography reshuffles the danger set. Any "universal default" will block someone's legitimate caller ID. So Orbit ships the baseline empty and the gate as a cheap no-op until you opt in — a tenant-owned protective control whose list is yours to curate, not a platform mandate.

That does not leave you at an empty page. Published DNO feeds are the standard starting stock: the identified spoofed lines circulate in the provider community, and many carriers publish a curated feed as part of their number-intelligence service. Import a feed as your starting set, then curate: your inbound-only toll-free ranges, unassigned allocations, and honeypot numbers belong there too — own-spoofed numbers carry a disproportionate share of traceback requests.

The three override modes

The effective DNO set reconciles a platform-level baseline list with your organization's own entries, in one of three modes set in voice organization settings:

• `extend` adds your entries to the baseline. The default, and what most tenants should use.
• `replace` cuts the baseline out and applies only your list — for tenants running their own curated registry.
• `subtract` removes specific baseline entries, for when a baseline prefix wrongly matches numbers you legitimately own.

Entries are normalized on write — + and digits are retained, everything else is stripped — and matching is prefix comparison. A full E.164 entry (+18005551212) blocks exactly that number; a shorter entry (+1800555) blocks an entire inbound-only or unallocated range. The longer the entry, the narrower the block.

Only workspace owners and admins can write the override. Over the API, the shape goes through PUT /api/v1/settings/general:

curl -X PUT https://api.orbit.devotel.io/api/v1/settings/general \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "voice": {
      "dno_override": {
        "enabled": true,
        "mode": "extend",
        "numbers": ["+1800555"]
      }
    }
  }'

Removing an entry is the same call with the updated list — the override is written as a full-list PUT, so the pattern is fetch-build-verify rather than incremental delta pushes:

curl -X PUT https://api.orbit.devotel.io/api/v1/settings/general \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "voice": {
      "dno_override": {
        "enabled": true,
        "mode": "extend",
        "numbers": []
      }
    }
  }'

Where DNO sits in the send-gate chain

Each outbound send on Orbit passes through the send gates documented on the Send Gates page: BAA when HIPAA mode is on, quiet hours, Do-Not-Call, Reassigned Numbers Database, Robocall Mitigation Database, preference checks. Voice adds pre-flight blocks on both halves of the call: the destination is screened against the emergency short-code table, and then, at origination time, the caller ID passes the DNO check. A DNO match rejects like the emergency block — before dispatch, before billing — unlike the post-dispatch per-destination auto-blocks.

DNO also stacks next to STIR/SHAKEN attestation, not behind it. Attestation proves the number; DNO decides whether a forbidden number may even be presented. The strongest posture is numbers you own attesting at level A, with spoofable spoof-bait prefixes blocked outright at origination.

Why procurement and audit ask about DNO first

Carrier KYC checks and FCC traceback requests reach for origination-time questions before they reach for softer controls — consent hygiene, complaint rates, CNAME/registration hygiene — because a DNO answer is binary and attestable: either calling-party screening happens before dispatch or it does not. A screened answer removes uncertainty quickly; it is easier to audit than rate-based throttles or post-hoc complaint ratios.

Procurement-grade tenants should treat their DNO configuration as audit evidence. Every change to the organization's override lands in the audit log with the actor and the before/after snapshot, and the log exports to SIEM. When a carrier or traceback group asks how spoofing is prevented, that audit trail plus the configuration is the answer — and it survives a reviewer who digs past marketing claims into the actual gate behavior.

Frequently asked questions

Is DNO the same as a blocked destination list?

No. DNO screens the calling-party number — the from you present — against a list of forbidden origination numbers. Destination-side blocks (emergency short codes, per-destination auto-blocks) guard the recipient end. Both run on voice, independently.

Does the DNO gate slow down calls?

Only marginally; when you have no entries, the check is a no-op. When entries exist, matching is an in-memory prefix comparison evaluated after caller-ID resolution, before any SIP dispatch.

What happens on a settings lookup failure?

The gate fails open to the platform baseline (usually empty) rather than blocking every outbound call. Deliberate: a transient settings-read blip must not hold your traffic.

Does DNO replace STIR/SHAKEN attestation?

No — the two stack. DNO decides whether a forbidden number may be presented at all; attestation decides how deep the carrier trust claim goes. Own the numbers for A attestation, and block spoof-bait prefixes at origination.

The takeaway

DNO list curation is admin-time well spent: it is cheap to maintain, it gives carriers the binary answer they audit first, and it closes the cheapest spoofing hole — the one that presents invalid, unallocated, or inbound-only numbers as caller ID. Opt in with extend mode and a published feed; refine with replace or subtract only when a baseline entry genuinely collides with a number you own. The DNO configuration spec has the full field shape; the send-gates overview shows the DNO gate in the chain.