If you run a BizDev or GTM service, your week starts with a list. Visitor identification deanonymizes the companies landing on a client’s site, engagement and lookalike signals stack on top, and someone — a rep, an automation, an account owner — decides which rows have earned attention.
The list arrives with one unchecked assumption baked in: that every domain on it is a real company, able to receive mail, and operated by the entity its name suggests. Most weeks that assumption is harmless. The tail is where it bites. A handful of rows are junk that cannot receive the outreach your sequence will send. A handful are brands a parent company quietly acquired, so the account routes to the wrong owner. And a handful are real companies sitting behind edge protection that lazy automation will misread or drop.
Those rows cost the two things a service like yours protects hardest: your best people’s hours, and your client’s trust in the report you hand them. When a client opens the weekly report and sees a company they know was acquired two years ago, or one that plainly is not a business, they do not file a ticket. They quietly decide the list is soft.
What WhoisGenius does
WhoisGenius is a domain-verification layer. You give it a domain; it reads that domain’s own present-day evidence — the registration record, DNS and certificate history, hosting, mail configuration, and the content of the site itself, including the copyright holder it names and the account-scoped analytics identifiers it loads — and returns one scored answer: who operates this domain right now, whether it can receive email, how long it has existed, and how strong the evidence is.
Three properties of that answer matter for a BizDev workflow:
- It’s an attribution, not a lookup. The operator comes from the domain’s own current evidence, not a firmographics database refreshed on someone else’s schedule — which is where stale acquisition data comes from in the first place.
- The verdict is graded honesty.
confirmedmeans independent ownership signals corroborate and no serious rival survives.likelyandpossiblesay progressively thinner evidence.unattributablemeans exactly that — the system names no one rather than guessing, because a confident wrong answer on a real company is worse than no answer. - Every row carries its rationale. When your client asks why a company is on their call list, the answer cites the registration record or the site’s own copyright holder — a sentence they can forward to their boss, not a model score.
The four treatments
Verification turns the weekly list into four piles, each with its own handling:
Work it. The evidence names a real operator, mail is configured, the domain has history. Enrich, personalize, route. And when the operator turns out to be a parent company, route to the parent account and note the subsidiary — that is the difference between pitching into the right org chart and the wrong one.
Work it, with a caveat. The evidence is thin but not damning: a younger company, partial coverage, an operator that is only probable. Keep the row, attach the caveat to the record, and let the rep calibrate.
Human review. The domain is real but edge-protected — its site returns a block page to automated readers, so the honest answer is “real, but we cannot see enough to name anyone.” This is a ten-second task for a person, not a reason to drop a genuine prospect, and never a reason to let automation invent an attribution.
Drop it. No mail configuration, a few hundred days old, the only operator candidate is the domain’s own name. That row was never going to close. Drop it before it becomes a CRM record, a sequence enrollment, or a rep’s research hour — and log the reason.
What we did, and why
To show what the classification looks like on a realistic workload, we built a 500-domain list shaped like a busy client’s monthly visitor report — and deliberately built it to argue with us:
- 274 real SaaS companies, drawn from public directories. This is the normal case — most rows on a real visitor report are real businesses, and the classification has to get them right without slowing anyone down.
- 96 known subsidiaries, each researched from public acquisition records with a verified parent: YouTube to Google, Wolt to DoorDash, BMC to KKR. This segment tests the part no mail-checker can do — does the evidence find the entity that actually owns the account?
- 120 freshly registered junk domains, pulled from a newly-registered-domain feed. Not invented strings — live registrations, indistinguishable from a prospect to a visitor-ID pixel. We planted them to measure false positives honestly, because a classifier you have not stress-tested is a hope, not a control.
- 10 edge cases — review platforms and edge-protected brands, the rows designed to break naive automation.
Five hundred domains is roughly a month of visitor reports for one busy client — big enough to stress the pipeline, small enough to stay boring.
What came back
The headline numbers:
| Segment | Result |
|---|---|
| Real SaaS (n=274): operator identified with confidence | 61% (166) |
| Subsidiaries (n=96): attributed to a real operating entity | 67% (64) |
| — of which named the correct parent or operating subsidiary | 62% |
| Fresh junk (n=120): rejected outright | 93% (111) |
| Fresh junk: false positive (never rated above “likely”) | 1.7% (2) |
Three takeaways for your own lists:
The majority of real rows resolve to a named legal entity. Sixty-one percent of real companies came back with a confident operator attribution. The rest land in the caveat or review piles rather than getting dropped, because an unattributable real company is a routing decision, not a verdict of fake.
Junk dies quietly, and it almost never impersonates well. Ninety-three percent of the freshly registered lookalikes were rejected outright. Two rows out of 120 slipped to “likely” — and not one ever earned confirmed. The layer’s most confident word stayed behind the evidence, which is what keeps a false positive from reaching a rep as a sure thing.
Your rates will differ, and that is fine. This list carries far more junk than a real visitor report — we built it to stress the classifier. The number that matters is your junk-and-misroute rate, measured on your own client lists.
The rows that make the case
Abstract rates are nice. Rows are better. From the actual result set:
youtube.comcame back named to Google LLC at the highest confidence.obsidian.netto Microsoft,avast.comto Gen Digital,rockset.comto OpenAI. A rep working the brand without the parent is pitching into the wrong org chart; territory rules keyed on the brand name route the account to the wrong owner.hulu.comcame back as Hulu, LLC — the operating subsidiary, with Disney as your account-hierarchy rollup. Same forwolt.com(Wolt Oy, rolling up to DoorDash) andriotgames.com(Riot Games, rolling up to Tencent). That is the correct reading: the domain’s own evidence names the entity that operates it, and your account hierarchy does the rest.- Where a private-equity fund owns the company, the evidence names the portfolio company, not the fund:
bmc.comreturns BMC Software,proofpoint.comreturns Proofpoint, Inc. No fund’s name appears in a registration record, and a tool that claimed otherwise would be inventing data. - The junk that slipped to “likely” tells you how the system fails when it fails: rows named by their own thin content, or by a privacy holding entity in their registration records. Weakly worded, never top-rated — and every one still fails the mail and age checks, so the drop rule catches what the attribution did not.
Implementing it on your client lists
The whole thing is a weekly habit, not a project:
- Classify before anyone acts. Take this week’s visitor domains per client and run the verification pass before the rows touch a CRM, a sequence, or a rep’s queue.
- Route by treatment. Work-it rows get enriched and assigned — to the parent account when one is named. Caveat rows get worked with the caveat on the record. Review rows become a ten-second human task. Drop rows never arrive, with the reason logged.
- Show the catch. This is the step that keeps the layer in the engagement. Its benefit is a negative — the junk a client never saw, the account that never got misrouted — and invisible benefits get cut at renewal. So every client-month, ship a one-page summary with the qualified report: rows dropped and why, rows rerouted to parents with the before-and-after, rows sent to review. That page turns a suppressed negative into a line your client can point to when they defend your spend internally.
- Price it as a deliverable, not a cost. Verification runs about $0.15–0.28 per domain — a 400-domain client book is $60–112 a month of input. The product you bill for is the qualified report and the monthly catch summary. Price against what it prevents — a rep-hour burned on junk, an enterprise account misrouted for a month, a renewal lost to a report the client stopped trusting — not against the fifteen cents.
Run your own list
Do not take our rates as your rates. Take last month’s actual visitor domains from one real client — the real list, not a simulation — and classify it. Then line the results up against what reps actually worked: how many worked rows had no mail configuration, how many were attributed to a subsidiary when the parent was the buying entity, how many hours went to domains under a year old. That delta is your business case, and it is the only one worth trusting, because it is yours.
Three ways to do it, none of them a project:
In the dashboard, no code. Export your visitor report as a text or CSV file, open the dashboard’s batch analysis, and upload the list — or paste domains one per line. Lists up to 50 domains show results live; larger lists run as a bulk job and email you CSV and JSON download links when they’re ready. One credit per domain, failed analyses refund automatically, and the free tier covers the first 75 — so last week’s report is the pilot.
Through the API. POST /analyze/batch accepts up to 50 domains per call and delivers results asynchronously, with signed webhooks if you want the pipeline event-driven. This is the path when classification becomes a standing step in your weekly workflow. API documentation.
Inside an agent workflow. The MCP server at https://api.whoisgeni.us/mcp exposes analyze_domain and correlate_domains, so an AI SDR or research agent can verify a domain mid-task, in seconds — no integration code, one instruction in the workflow.
The hypothesis, stated so your data can kill it: on a realistic intent-sourced list, a material share of rows should not cost a rep an hour, and at least one high-value row per client-month is attributed to the wrong legal entity. If your lists do not show that, your lists are clean — which is also worth knowing. Get an API key and classify your own list before it costs another rep-hour.