📧 Work Email Finder — Name + Domain → Email, Pattern & Score

Give it a first name, a last name and a company domain. Get back a ranked ladder of work-email candidates — where the pattern was decoded from REAL addresses the company already published, with the source URLs on every row so you can check the answer yourself.

Most email finders hand you first.last@company.com and a confidence number they will not explain. On the 16 domains where this actor found decodable evidence in its benchmark run, 8 of them do not use first.last — Twilio, Cloudflare, HubSpot, Jones Day and Sidley use {f}{last}, McKinsey uses {first}_{last}, Stripe leans {first}{last}. A ranker that defaults to first.last is wrong half the time and never tells you.

This one shows its work:

🔍 What it does

1. DNS tier (always runs, direct, never proxied). MX, SPF, DMARC, BIMI and 18 DKIM selectors over DNS-over-HTTPS, plus RDAP registration facts. This tier alone guarantees every person gets a row.
2. Evidence tier (public sources only). The company's GitHub org commits (author name + address), npm maintainers/contributors, PyPI metadata, and the company's own website — homepage, then robots.txt → sitemap-discovered team / people / contact pages, plus /.well-known/security.txt.
3. Decode, don't guess. Every observed Name → address pair is tested against 20 pattern templates. A pattern only earns a vote if rendering it with that name reproduces the local part exactly. Michael Broshi → mbroshi votes {f}{last}; David Brownman → xavdid votes for nothing, and is reported as undecodable rather than forced into a bucket.
4. Rank and score. Confidence is agreement × a sample-size factor, so a domain that splits 43% five ways cannot come back "high".

Sources verified live (2026-09-02/03, direct and through the Apify proxy)

📥 Input

{
  "people": [
    { "firstName": "Michael", "lastName": "Broshi", "domain": "stripe.com" },
    { "firstName": "Jeff",    "lastName": "Lawson", "domain": "twilio.com" }
  ],
  "maxWebsitePages": 8,
  "maxGithubRepos": 3
}

Evidence is cached per domain, so 50 people at one company cost barely more work than the first.

📤 Output — one row per person, 70 fields

Identity + answer

The audit trail (this is the product)

Where the mail actually lives

Company + domain facts

Honesty fields

📊 Measured — run QOb1MsFAxLfhsskMe, build 0.1.4, 2026-09-03

Not estimates. This is one real Apify run at 1,024 MB through the Apify proxy.

Coverage — the number that matters, and it is not flattering

The 10 domains with no decodable evidence still shipped a full row — MX, SPF, DMARC, DKIM, RDAP and a ranked ladder — but flagged provider-heuristic / structural and scored very-low. That is the correct answer, not a failure. Read the section below before you buy.

What the evidence actually said

Eight of these sixteen domains do not use first.last. That is the whole argument for this actor. And note Stripe and Sidley: a big pile of observed addresses with low agreement scores low, because the domain genuinely uses several conventions — the ladder in candidates[] is the answer there, not the top row.

mwe.com is the case that breaks naive tools. McDermott's website is mwe.com; its people's addresses are at mcdermottlaw.com. This run detected that, switched mailDomain, set mailDomainDiffersFromInput: true, and decoded 7 addresses at 86% agreement. A tool that appends the input domain returns undeliverable @mwe.com guesses.

Badge-risk preflight (timeout=300, 1,024 MB)

Fleet health monitor: PASS, 19.1 s, 2 items.

💵 Pricing

Pay per event — $0.002 per person resolved ($2.00 per 1,000). One event, email-resolved. Both of Apify's auto-events (apify-default-dataset-item, apify-actor-start) are removed, so your bill shows only people you actually resolved.

• Rows are shipped with Actor.pushData(rows, 'email-resolved'), which is budget-aware: delivered equals billed, and a buyer who hits their charge cap never keeps rows they did not pay for.
• A person we can produce no candidate for is delivered free (pushed without the event).
• Evidence is cached per domain, so the 50th person at a company costs the same as the second.

For comparison, measured from the Apify API on 2026-09-02: the largest actor in this lane charges $0.029 per email resolution (14.5× this), and a pattern-finder in the same lane bills $0.008 per pattern tested — roughly $0.064 for one person, and you pay for every wrong guess. This actor bills once per person and hands you the whole ladder.

⚠️ Honest limits — read these before you buy

1. There is no SMTP verification here, and smtpVerified is hardcoded false forever. Outbound TCP port 25 is blocked on the Apify platform — measured 2026-09-02 from a real Apify run: MX hosts on :25 returned ETIMEDOUT in ~260 ms while smtp.gmail.com:587 answered with a live 220 banner from the same run. And even where port 25 is reachable, it lies: during recon a deliberately garbage mailbox, zzqqxx9988@stripe.com, got the same 250 2.1.5 OK from Google's MX as a real one. Google Workspace and Microsoft 365 host most B2B mail and accept every recipient at the gateway. Any product that calls those addresses "verified" is guessing with extra steps. We put that fact in catchAllBasis on every affected row instead.

2. Coverage is tech-skewed. Measured above: 10 of 11 technology domains decoded, 6 of 15 non-technology domains. GitHub commits are the single richest source and a plumbing distributor does not have a GitHub org. Non-tech domains fall back to the website tier, and if the company publishes no addresses at all you get provider-heuristic at very-low confidence. That is what cushmanwakefield.com, grainger.com, trane.com and wwgrainger.com returned in this run — a complete DNS row and an honest "we have no evidence about this domain."

3. A correct pattern is not a live mailbox. We prove the domain's convention. We do not prove the person still works there, that the mailbox exists, or that they do not use a nickname — observed in a run against the stripe/stripe-python repos: David Brownman → xavdid@stripe.com and Zachary Chua → zacchua@stripe.com. Both are reported pattern: null rather than guessed. confidenceReason says this on every row.

4. Some sites block us, and we say so rather than reporting "nothing found." Measured on this build: grainger.com returns HTTP 403 to the Apify container IP; mcdermottlaw.com (Imperva) served a _Incapsula_Resource interstitial to a datacenter IP, to an Apify RESIDENTIAL IP and to a plain home connection during testing — yet the same page returned 369,600 bytes of real content on other attempts, so this is IP reputation and rate, not a permanent wall. Those rows carry blockedSources[] naming the URL and the reason. Bring your own residential proxy via proxyConfiguration if a target site refuses Apify's ranges.

5. GitHub's unauthenticated rate limit is 60 requests/hour per IP (measured:

X-RateLimit-Limit: 60

6. companyNameFromRegistry filled 0/30 in this run. ICANN privacy redacts the registrant organisation on essentially every gTLD. The field is kept because some registries do publish it; on .com/.org/.io expect null. Use companyTitle (86.7% fill) instead.

7. Name order from a web page is not evidence. Kirkland files Ken Au at /lawyers/a/au-ken, so proximity-derived names can be surname-first. When a local part decodes under both orderings the vote is split and both candidates appear on the ladder — which is why kirkland.com scores 0.43, not 0.85.

⚖️ Sources, robots and fair use

Every source this actor reads is public and unauthenticated: DNS records, RDAP registration data, GitHub's public API, npm and PyPI registry metadata, and the company's own public web pages. There is no login, no target-site cookie, no CAPTCHA solving, no named-crawler impersonation, and no LinkedIn scraping of any kind — LinkedIn discovery is the practice that ended Proxycurl, and this actor takes the name and domain from you instead.

The company-website tier reads robots.txt primarily to discover sitemaps, and the row reports robotsDisallowsPeoplePaths so you can see whether a given site's robots.txt disallows the people/team paths involved. Fleet policy is that a robots.txt Disallow is disclosed, not treated as a licence question the actor decides on your behalf — the compliance call is yours.

Output is personal work-contact data. Depending on where you and your recipients are (GDPR, CAN-SPAM, CASL, PECR), you may need a lawful basis to process or contact these people, and you are responsible for that. This actor is built for legitimate B2B outreach, CRM enrichment and deliverability research. Do not use it for spam, harassment, or to contact private individuals.