An agency launched outreach on a purchased list of 10,000 numbers. Software sent only 40 messages - 18 failed delivery. On message 41, a two-year account with high trust got a permanent ban. Cause wasn't copy or send time - it was the list itself, visible in a 15-minute pre-launch audit.
Most WhatsApp guides cover message text, send timing, number warm-up - almost never the list. Yet the list most often decides whether outreach survives day two. A "dead" list isn't one signal - it's age, source, mobile share, and activity history combined, mostly visible before the first send. Warning signs, 15-minute express audit, and which failed-delivery rate should stop your test.
Five different problems hide under the label - detected differently.
| Problem type | Meaning | How to detect |
|---|---|---|
| Invalid | no WhatsApp account (no JID) | validator / Cloud API |
| Inactive | account exists but unused | not officially detectable - Meta only returns registered yes/no, no last-activity data |
| Duplicate | repeated contact | dedup before import |
| Landline/fax | number can't be on WhatsApp | HLR query, number-type slice |
| Format error | not E.164 standard | length/mask auto-check |
Step 1. Format and dupes. E.164 check and dedup - data hygiene, not WhatsApp-specific. Excel dedup alone can't tell mobile vs landline or check account existence.
Step 2. Validator check. Official: WABA Cloud API contact check returning valid/invalid - WABA overview. Gray: Baileys/whatsapp-web.js onWhatsApp(). Cloud services with registrar pools can validate 10k numbers in 5–15 minutes. Free forum checkers unstable and may steal numbers into their own lists - same logic as migrating from other messengers.
Step 3. HLR query. Active SIM? Mobile, landline, or virtual? City numbers in list - almost always parsing marker, not organic collection.
Step 4. Carrier/region slice. Chaotic mix of dozens of region codes without geographic logic - forum marker for "purchased junk." No confirmed Meta antispam use of this distribution - your own decision heuristic.
| Metric | Measures | Benchmark |
|---|---|---|
| Quality Rating | WABA number reputation | ideally ≥ 0.80 |
| Bounce Rate | undelivered share account-wide over time | ≤ 2% OK, > 10% serious |
| Complaint Rate | recipient reports | ideally ≤ 0.1% |
| Failed Rate on new-list test | failures on first sends to fresh list | many practices < 5% safe |
| P95 delivery time | send latency | up to ~3 sec normal load |
Bounce Rate ≠ Failed Rate on test sample. Bounce = account over time; Failed on first 50 = new-list diagnostic - see A/B testing methodology.
WABA doesn't shield bad lists: high Failed Rate drops Quality Rating → template blocks or 250/day cap - confirmed mechanics.
Never launch whole list. Standard: ~50-message test sample with separate Failed Rate control before scaling - see first cold message test logic.
Over 30% failed on test 50 - stop immediately, change list. Not official Meta rule - widely cited practitioner stop signal - high error cost.
Gray zone between <5% safe and >30% stop - slow down, scrutinize source - see ban mechanics and behavioral anti-spam.
| Failed | Working | |
|---|---|---|
| List | 10k purchased e-shop list, 2 years old | 5k scraped B2B from contractor |
| Pre-launch audit | None | Validator removed 1200 landline, 400 format errors, 800 no WA - 2600 clean |
| Outcome | 18/40 failed, ban on msg 41 despite 2yr trust | Test launch 98% delivery, no blocks |
Same warmed sender number both cases - difference: audit before launch or not.
Official tools: binary registered yes/no only. No last activity, app usage frequency, or last online in public docs. Claims about "active share" beyond binary status are assumptions.
Burn pattern: purchased list unchecked, skip validation "to save time," full-list launch, random free checkers. Multi-account split doesn't fix it - dead list burns each in turn - see broadcast economics where cheap list becomes most expensive line item.
Run current list through validator - record invalid % and landline share. If unexpectedly high - that's why last launch underperformed.
Practical rule:
You can rewrite message text after the first complaint. You can't rewrite a ban from a dead list - audit before launch, not after problems.
