DNC scrubbing vs phone validation: what's the difference?

Two jobs get mixed up constantly on outbound teams: DNC scrubbing and phone validation. They sound adjacent, they both shrink your call list, and plenty of vendors are happy to blur the line. They are not the same job, and doing one does not do the other. One is a compliance check against official registries. The other is a data-quality check on the number itself. Here is the difference, and why the order you run them in changes your bill.

What DNC scrubbing actually is#

DNC scrubbing means checking each number against Do-Not-Call registries. In the US that's the National Do Not Call Registry, plus applicable state lists, plus your own internal suppression list and any wireless or consent rules that apply to your outreach. It answers exactly one question: are you allowed to call this number?

That's a compliance step. You do it with the official registries directly or with a dedicated DNC-scrubbing service that subscribes to them and keeps its data current. Boundstone does not do this. Boundstone is a data-validation tool — not a DNC service, not a compliance service, and not legal advice. We'll say that a few more times, because the confusion is expensive.

What phone validation actually is#

Phone validation checks the number itself: is it well-formed, is it possible for its region, what type of line is it, and what does the clean E.164 version look like. It answers "is this a real, usable number, and what kind is it" — a data-quality question, not a legal one.

curl https://api.boundstone.io/v1/verify/phone \
  -H "Authorization: Bearer bs_live_YOUR_KEY" \
  -d '{"phone":"+16504472983"}'

{
  "valid": true,
  "e164": "+16504472983",
  "country": "US",
  "line_type": "fixed_line_or_mobile",
  "national_format": "(650) 447-2983",
  "checks": {
    "performed": ["format", "region", "line_type_metadata"],
    "not_performed": ["carrier_lookup", "ported_status", "hlr_liveness"]
  }
}

The line_type comes from Google's libphonenumber metadata — the number's designated type in its region's numbering plan (MOBILE, FIXED_LINE, VOIP, TOLL_FREE, and so on). It is not a live network check. And valid: true means the number is well-formed and possible for its region — not that it's currently in service, reachable, or that a human will answer. Confirming that needs a live carrier or HLR lookup, which is why carrier_lookup, ported_status, and hlr_liveness sit in not_performed by default. Send hlr:true (5 credits, paid plans) and they move into performed. Read the arrays and believe them.

Why the two get confused#

Both steps shrink your list. Both feel like "cleaning." Both happen before you dial. But they cut different junk.

Validation drops numbers that were never valid: typos, wrong digit counts, invalid area codes, numbers with too few digits. DNC scrubbing drops numbers you aren't permitted to dial. A number can pass validation perfectly and still be on the DNC list. A number can be DNC-clear and still be six garbage digits. Neither result implies the other, which is the whole point.

Run validation first — it's cheaper#

Here's the money argument. DNC scrubbing generally costs something per number. If you scrub your raw list, you're paying to scrub typos, blank rows, and malformed junk that was never a real number in the first place.

Validate first. Drop the impossible numbers, normalize the survivors to E.164, then scrub what's left. You send the DNC service a smaller, cleaner list and stop paying to check numbers that were never real. Same logic applies to any downstream cost — dialer minutes, enrichment, a live carrier lookup if you add one later. The phone validator is the hygiene pass that goes in front of all of it, and the free tier (250 credits a month, no card) is enough to see whether your list is as clean as you think.

Validation also hands you line_type metadata, which is genuinely useful for outbound segmentation — routing MOBILE differently from FIXED_LINE, for instance. Two honest caveats. First, FIXED_LINE_OR_MOBILE (common across North America) means the numbering plan itself can't tell the two apart, so don't guess — take it as "unknown," not "pick one." Second, VoIP detection only catches numbers sitting in ranges designated as VoIP; a hosted or ported VoIP number reusing a mobile or fixed-line range looks like a normal mobile or fixed line to metadata. Catching that reliably needs a live carrier lookup, which is not_performed.

Where each job stops#

Boundstone's job is the hygiene layer: drop the invalid and impossible, segment by line type, normalize to E.164. It is not the compliance layer, and it never will be by accident.

For the compliance side — DNC scrubbing, TCPA, consent, wireless rules — you need the official registries and/or a qualified attorney. This post is not legal advice. If you want the fuller picture on how validation fits alongside your compliance work (and where it stops), TCPA and phone validation walks through the boundary. For the mechanics of running the hygiene pass over a real list, clean your phone list before calling covers the workflow, including bulk CSV.

The short version#

• DNC scrubbing = are you allowed to call this number? A compliance step, done with official Do-Not-Call registries or a DNC service. Boundstone does not do it.
• Phone validation = is this a real, well-formed number, and what type? A data-quality step. Boundstone does this.
• They cut different junk. Passing one tells you nothing about the other.
• Run validation first so you don't pay to scrub numbers that were never valid in the first place.
• valid means well-formed and possible — not live, reachable, or textable. Live carrier/HLR checks are not_performed by default, and a paid opt-in with hlr:true.
• Boundstone is the hygiene layer, not the compliance layer. It is not legal advice either — for DNC and TCPA, use the registries and counsel.