The problem
Sales, recruiting and partnerships workflows all hit the same wall: you have a person's name and their company domain, and you need a work email address. The common shortcuts are guessing patterns (first.last@domain) and SMTP probing — both damage sender reputation, and a "mailbox accepted the message" probe proves nothing about who owns it. Paid people-search databases sell the same guess with a nicer UI.
The defensible alternative is boring and manual: open the company's own website, find the team page, and check whether the address is literally published next to the person's name. That does not scale past a handful of lookups.
What the actor does
The Domain to Verified Work Email actor automates exactly that check — and nothing more. For each {fullName, domain} pair (1–50 per run) it visits only the buyer-selected company's own website, reading at most four fixed pages in a fixed relevance order — /team, /about, /contact, then / — over HTTPS, honoring robots.txt fail-closed, with no login, proxy, CAPTCHA-solving or JavaScript execution. Per the README, every row lands in one of four outcome classes:
-
Published person match (billed): the literal address exists as visible text or a
mailto:link, the full name appears in the same bounded context, the local part follows a personal-name form, and the same HTML document carries a schema.orgPersonJSON-LD assertion whose normalized name and email exactly match. - Published visible match: every condition holds except the schema.org assertion — the page prints the address in the person's own block with no competing person. This is what most real company sites publish.
-
Free candidate list: name-shaped addresses (
jdoe@,jane@) that the page never prints next to the name are listed incandidateEmailsfor a human, never promoted to a match. -
Honest free decision: no address, only role mailboxes (
info@,press@— listed inroleEmails), an ambiguous tie, a robots-blocked page, or a budget stop. Every free row still reports checked pages, unreachable pages and reasons.
Every row — paid or free — carries safeToAutomate: false and safeForOutreach: false: a published page proves the address is printed, not mailbox ownership, consent or deliverability. Role-token local parts (contact-us, recruiters, human-resources, …) never become paid rows, and hidden CSS content is excluded via offline layout evaluation before matching.
Example: input and output
{
"people": [
{ "fullName": "King Lee", "domain": "visionwide.co", "companyName": "Visionwide" }
],
"maxPagesPerPerson": 3,
"maxConcurrency": 1
}
The README's published person match example (abridged to key fields):
{
"recordType": "person_email_decision",
"schemaVersion": "1.1",
"fullName": "King Lee",
"companyName": "Visionwide",
"domain": "visionwide.co",
"email": "king.lee@visionwide.co",
"verificationStatus": "published_person_match",
"matchScore": 100,
"matchReasons": ["literal_email_published", "full_name_on_page", "schema_org_person_name_email_assertion"],
"sourceUrl": "https://visionwide.co/team",
"sourceEvidence": { "schemaOrgPersonAssertion": true, "publicationChannel": "visible_text" },
"roleEmails": ["info@visionwide.co"],
"checkedPages": [
{ "path": "/team", "status": 200 },
{ "path": "/about", "status": 200 }
],
"confidenceBand": "high",
"recommendedAction": "ingest_evidence_then_apply_your_legal_outreach_policy",
"safeToAutomate": false,
"safeForOutreach": false,
"found": true,
"chargedEvent": "result-found"
}
Pricing and the free limit
Pay-per-event: $0.005 per run start plus $0.01 per published person match. A published visible match is billed only while its visible-match-found event carries a Store price — otherwise it is free. Every other outcome (candidates, role mailboxes, no-match, ambiguous, partial, robots-blocked) costs nothing beyond the start fee. A run delivering 100 published matches costs $0.005 + 100 × $0.01 = $1.005. Apify's free plan gives $5 of usage credits per month, so $5 covers about 4 such runs — roughly 400 verified addresses — plus any number of free-outcome rows at the start fee.
Try it
Submit a name and a domain, and read the evidence-tagged row before any outreach decision: Domain to Verified Work Email
For AI agents and MCP
The actor is built as a machine-first microservice: a closed input schema, a uniform 34-field row shape regardless of outcome, and a schema-validated OUTPUT summary — callable from the Apify API, a scheduled task, or the hosted Apify MCP server documented in the README. An agent can switch directly on verificationStatus and gate spend on chargedEvent, with safeToAutomate and safeForOutreach fixed at false so a lookup can never silently escalate into an autonomous send.
Top comments (0)