Quick answer: Do-Not-Originate (DNO) is a screening practice built around one simple fact: some phone numbers exist only to receive calls. Inbound hotlines, government agency numbers, bank support lines, hospital switchboards — those numbers should never appear as the presenting caller ID on an outbound call. When a number is entered on a DNO registry, carriers and downstream providers screen outbound calls against that list and block any call whose caller ID matches. The guard cuts both ways: register your inbound-only numbers on a DNO list so spoofers get cut when they forge your identity, and check every outbound caller ID against the same lists so a launchable campaign does not die at the carrier edge on day one. On Devotel Orbit, the DNO guard runs at dial time and rejects a matched caller ID with a 422 VOICE_DNO_BLOCKED before any media, billing hold, or SIP INVITE is attempted.
This explainer answers both halves of the topic — the registry question (which numbers belong on DNO lists, and where in the path they are screened) and the dial-path question (how the guard runs on Devotel Orbit, and how a tenant curates its own list). Two older Do-Not-Originate posts previously lived in this corpus; their content was consolidated here, and those slugs now redirect to this one.
What a Do-Not-Originate registry actually is
Caller ID is an assertion, not a credential. By default, an originating network can present almost any number as the caller ID of an outbound call, and nothing in the legacy call path forced that number to be one the caller had the right to use. STIR/SHAKEN attests whether the signing carrier is allowed to use the number; DNO attacks the complementary case: even a technically-unchallengeable attestation means nothing if the number itself should never originate calls at all.
A DNO registry is therefore a negative list — and where Do-Not-Call (DNC) opt-outs filter destinations you must not reach, DNO flags caller IDs that must never originate a call. The operating rule:
- The number's owner (or its carrier) states that the number is receive-only.
- The number lands on one or more DNO lists maintained by carriers and industry working groups.
- Calls presenting that number as their caller ID are treated as spoofed by construction and can be blocked by carriers downstream of the originating network.
The categories of number that belong on a DNO list are the ones a legitimate originator cannot own:
| Category | Why no legitimate caller can present it |
|---|---|
| Government agency lines (IRS, SSA, law enforcement) | Fraud impersonation is the classic spoofing payload; the number is inbound-only by policy |
| Inbound-only toll-free ranges | The number is registered to terminate inbound calls, never to originate them |
| Unallocated NANP ranges | If no carrier has assigned the block, any call presenting it is fabrication |
| Inbound-only service and emergency lines | Same policy: the line exists to receive, not to originate |
A typical DNO candidate set also includes toll-free customer-care numbers, hospital and emergency switchboards, and any number an enterprise advertises as an inbound contact point. The common trait — callers are taught to trust these numbers, so they are also the numbers spoofers forge most.
The legal backdrop: TRACED Act and traceback pressure
Presenting an invalid, unallocated, or inbound-only caller ID is illegal spoofing under the TRACED Act and FCC rules (47 CFR § 64.1604), and it is the pattern that most often drives a carrier-initiated STIR/SHAKEN traceback investigation against an originator. Blocks at the dial path are cheaper than blocks at the regulatory path: a 422 you fix in your account settings is quiet; an FCC inquiry about spoofed originating traffic is not. DNO is the origination-side complement to the recipient-side DNC controls — the pair covers both directions of the compliance exposure a voice program carries.
Where the screening happens in the call path
DNO screening is not one check at one point. On open networks it is a defense layered over three stages:
- Originating provider check. A responsible carrier or softswitch screens the caller IDs it accepts before routing. An outbound request presenting a DNO-listed number it does not own gets refused at the edge, or flagged for review.
- Transit and wholesale screening. Intermediate carriers in the call path run their own analytics — including DNO matching — on wholesale traffic. A forged number that slips past a careless originator can still be killed in transit, with the originating route's reputation taking the hit.
- Terminating analytics. The called party's carrier runs its blocking logic before the phone rings. DNO lists are one of the high-confidence inputs there: an inbound-only number originating calls is close to a definitive spoof signal, so it survives even conservative blocking thresholds.
The practical consequence: a caller ID that sits on a DNO registry is radioactive anywhere in the path. Even if the first hop passes it, a later hop often will not — and every hop that blocks it counts against the route that carried it.
On Devotel Orbit specifically, the guard sits in the platform's fixed pre-send gate chain before any SIP leaves the platform. The DNO check runs after your caller ID is resolved and validated as an active number, alongside the fraud-velocity guard, and before the trunk allow-list and per-country rate-window checks — the same chain the send-gates overview documents for the messaging side. A match short-circuits the whole chain: the API returns 422 with code VOICE_DNO_BLOCKED, the response body names the matched DNO prefix, and no media, billing hold, or SIP INVITE is ever attempted. When a call does pass, routing is unchanged — the guard is advisory-only on the dial path and never alters how an accepted call is carried.
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 spoof-bait prefixes blocked outright at origination. The full field shape for configuring the guard lives in the DNO configuration spec.
Why an outbound caller ID on a DNO list fails — and what to do about it
The failure mode operators actually meet is subtler than spoofing. It usually looks like this: a company provisions a number for inbound service, then months later uses the same number as the caller ID for an outbound campaign. If that number was DNO-registered — by the company itself, or by a carrier on its behalf — the outbound traffic starts failing in ways that look like coverage problems: calls that never connect, blocking concentrated on certain destination carriers, answer rates collapsing without a clear error.
Three rules prevent it:
- Separate inbound and outbound inventory. Advertised inbound lines and outbound caller IDs serve opposite jobs; treat a DNO registration as a one-way door. If a number might ever be registered inbound-only, never use it as an outbound caller ID.
- Screen caller IDs before campaign launch. A launch checklist that checks DNO status once beats a reputation repair that runs all quarter. Add the check to the same pre-launch pass that validates consent lists and quiet-hours enforcement — for AI-driven outbound that check gates the whole dial plan, as covered in the AI-assisted outbound guide.
- Register your own inbound lines. The other half of the guard: every number your customers are told to call is a number spoofers can forge. Registering it as inbound-only means forged outbound calls presenting your number get blocked at carrier analytics before your customers pick up — which is also the strongest caller-identity statement you can make while the call-recording consent gates handle the recording side of lawful telephony.
How matching works: one prefix semantic, two granularities
Registry-lookup mechanics on Devotel Orbit match on prefix rather than exact equality, because the threat classes come in two shapes. A full E.164 entry such as +18005551212 blocks exactly that one number — a specific spoofed line you know about. A shorter entry such as +1800555 blocks the entire range — an unallocated block you want closed as a class. The same prefix match covers both, and normalization strips everything that is not a digit or a leading + before comparing, so access-prefixed or whitespace-padded input cannot sneak past the list.
| Presented caller ID | DNO entry | Result |
|---|---|---|
+18005550101 | +1800555 | blocked — range prefix |
+18005551212 | +18005551212 | blocked — exact entry |
+121255501xx (a DID you own) | neither | accepted |
Because the guard runs before the rate-window check in the gate chain and short-circuits it, a blocked origination never reaches the window at all.
Curating your list: the tenant-owned override model
There is no universally safe default DNO set — a platform-shipped block that included a range your business legitimately owns would be worse than an absent guard. Devotel Orbit ships an empty platform baseline and gives every organization a tenant-level override with three modes:
- extend — add entries to the platform baseline (the default shape for most lists).
- replace — use exactly and only your own entry set.
- subtract — remove specific baseline entries when your own DIDs collide with one.
The override lives in your voice settings, scoped to the whole organization. Because the default list is empty, existing tenants see no behavior change until they opt in and curate — the guard starts out as a cheap no-op. And if the per-organization lookup ever blips, the guard falls back to the platform baseline instead of black-holing your outbound traffic — a fail-open posture on a gate you own, which is the same asymmetric posture the rest of the dial-path tenant-owned gates take.
Configuring the override over the API
Only workspace owners and admins can write the override. Over the API, the whole shape goes through PUT /api/v1/settings/general as a full-list write — 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": ["+1800555"]
}
}
}'Removing an entry is the same call with the updated list — pass the remaining entries (or an empty array to clear the override) and the platform replaces the stored set wholesale. Because entries are normalized on write and compared as prefixes, ["+1800555"] blocks the entire inbound-only or unallocated range; append the exact E.164 to narrow the block to a single spoofed line.
DNO alongside DNC, CNAM, and the trunk allow-list
The voice-compliance vocabulary has four caller-protection controls that sound related but guard different surfaces:
- DNC filters your destinations by recipient opt-out status.
- DNO filters your caller IDs by origin legitimacy.
- CNAM names which business owns an inbound number — a reception-side identity annotation.
- Trunk allow-lists restrict which caller IDs a customer SIP trunk may present — a provisioning control.
They cooperate rather than overlap: a spoofed caller ID that slips through a bare trunk allow-list can still die on the DNO list, and a clean caller ID still respects every recipient's DNC opt-out. Read them as complementary, not competing.
Why procurement and audit ask about DNO first
Carrier KYC checks and FCC traceback requests reach for origination-time questions before softer controls — consent hygiene, complaint rates, 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 your 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.
How to build a DNO guard into outbound calling
- Inventory outbound caller IDs. List every number any campaign, dialer, or AI agent presents as caller ID. Numbers with no owner in the inventory should not originate.
- Screen each caller ID against DNO registries. Check with the carrier that provisioned each number, and re-check on a schedule — registry membership changes as owners submit and remove numbers.
- Register inbound-only lines on DNO. Request inbound-only status on every advertised contact number through the carrier holding it, and confirm the registration took effect.
- Gate launch on the check. Make DNO status a launch-blocking item for every new caller ID, the same way consent and quiet-hours checks gate sends.
Frequently asked questions
What is a Do-Not-Originate list?
A Do-Not-Originate (DNO) list holds the numbers that must never appear as a calling-party number — government agency lines, inbound-only toll-free ranges, unallocated number blocks. It is the origin-side counterpart to Do-Not-Call: one filters recipients, the other filters fabricated caller IDs. Entries are carrier-mediated — the owner of a number asks its provider to mark the number receive-only, and the provider syndicates that to the lists it screens against.
Does DNO screening replace STIR/SHAKEN?
No. The two answer different questions. STIR/SHAKEN attests whether the carrier signing the call has the right to use the caller ID it presents. DNO says the presented number should never originate calls at all, whatever the attestation claims. Terminating-carrier analytics weigh both — a strong SHAKEN attestation does not rescue a DNO-listed number, and an unknown number does not need a DNO entry to be blocked.
My outbound call was blocked with VOICE_DNO_BLOCKED — what happened?
The caller ID you presented matched a DNO entry or prefix — typically because the number is inbound-only, belongs to an unallocated range, or is a government line. Compare the rejected number against your organization's DID list, and present a verified number you own. Request removal only if the number genuinely originates outbound and was registered by mistake; otherwise move the campaign's caller ID to a number provisioned for outbound use. On Devotel Orbit, the 422 response names the matched DNO prefix, and if you deliberately own a number that collides with a baseline entry, the subtract override mode carves the exception. Treat a DNO hit as a launch-gate finding, not a post-launch production incident.
Is the DNO guard on by default?
No. The platform ships an empty baseline because there is no universally safe default set, and each organization opts in by curating its own entries with an extend / replace / subtract override in voice settings. Until you add entries, the guard is a cheap no-op.
Does DNO apply to SMS sender IDs?
No — DNO is a voice concept that screens the presented caller ID on calls. The messaging analog lives elsewhere: A2P registration regimes like 10DLC vet the sender identity of message traffic, and the sanction-sweep explainer covers how carriers enforce it. The shared lesson is the same one this guard teaches: identity that is never screened is identity that will eventually be forged.
The takeaway
DNO is the missing half of the caller-protection pair. DNC keeps unwanted calls from reaching recipients; DNO keeps fabricated identities from originating the call in the first place. On Devotel Orbit the guard is tenant-owned, prefix-matched, fail-open on lookup errors, and silent until you curate — and a VOICE_DNO_BLOCKED rejection names the exact prefix that fired, so fixing it is a settings change, not an escalation. For the operational runbook, see the voice destination blocks troubleshooting page, and for the full pre-send gate order see the voice pre-send gate chain concept page. The quick orientation above also placed this explainer beside the 10DLC sanction-sweep roundup and the deepfake-voice fraud breakdown — the third head of the same problem: outbound identity.