Email Pattern Finder + Verifier by Domain

You give this actor a list of people, a name plus their company's domain. For each one, it generates a ranked set of likely email address candidates using well-known corporate email conventions (first.last@, flast@, firstlast@, and the rest), confirms the domain can actually receive mail via a live MX/A-record check, and then runs the top 3 candidates through a disposable-domain and catch-all check by default. You get back one best, status-tagged email (bestEmail / bestEmailStatus), the mail provider, and the full ranked candidate list, as one flat row per person.

This is a pattern generator with a mail-route and catch-all check, not a mailbox verifier. Confirming one specific address is a real, live mailbox requires an SMTP RCPT TO probe on port 25, and outbound port 25 is blocked on essentially every cloud/serverless runtime, Apify's included, to prevent spam abuse. Nothing here pretends otherwise: mailboxVerified is always false. bestEmailStatus is valid in the schema too, reserved for a future SMTP-capable depth, but this actor itself only ever returns catch-all or unknown (a domain with no mail route at all is reported as a miss before any candidate is billed, so invalid never appears on a hit either). What it honestly delivers is further than most pattern generators go without SMTP: proof the domain isn't a dead end, a disposable-domain check, and a catch-all flag when the target is a temp-mail provider, all before you're charged anything for a candidate.

Who it's for

The accountable_eel catalogue sells company intelligence columns for outbound. Each actor takes a list of domains or company identifiers and returns one flat, stably-named row per input — firmographics, registry IDs, tech stack, email route, hiring activity — the shape a Clay table, an n8n workflow, or an AI agent can consume without post-processing. Pricing is pay-per-event: a few tenths of a cent for a row that actually resolved, and nothing for a miss, so a list that doesn't enrich costs you next to nothing. This actor reuses this portfolio's own email-deliverability-check mail-route logic verbatim rather than re-deriving it, so the two stay consistent on what "this domain accepts mail" means.

This one is for outbound prospecting specifically: you have a decision-maker's name and their company's domain (from a job posting, a LinkedIn profile, a company's team page) and need a best-guess email address to reach them at, before running it through a separate deliverability/verification step.

Why this one

• Never charged for a domain that can't receive mail. The MX/A-record check runs before any candidate is billed — a domain with no mail route is a free, honest miss, not a wasted guess.
• Ranked, not just listed. Candidates come back ordered by real-world pattern frequency, with a single mostLikelyEmail pick, not an unordered dump you have to re-rank yourself.
• The top 3 get verified, by default. verify (on unless you turn it off) runs the top 3 ranked candidates through a disposable-domain and catch-all check and fills in bestEmail, bestEmailStatus, mxProvider, and confidence. The extra verified-email charge only ever applies when a candidate actually resolves to catch-all (never to a domain that can't receive mail at all).
• Honest about what it can't confirm. mailboxVerified is always false — this actor will never claim a specific mailbox exists, because no HTTP-only tool honestly can.
• Runs as a batch. Paste a whole list of names and domains from a lead list or a scraped team page, get back a dataset instead of guessing each address by hand.
• Handles real-world name mess. Apostrophes, hyphens, and accented characters (O'Brien, Renée, Smith-Jones) sanitize into the plain local-part real mail systems actually use, not a broken guess.
• Field names don't move between runs. The output schema is frozen — mostLikelyEmail is always mostLikelyEmail — so a Clay table or an agent's tool call built against it today still works against it next month.

What you get

One row per input person. Every field below is present on a found: true row; on a miss, only query, found, status, message, and scrapedAt are set.

Field	Type / format	Description
query	string	The input line exactly as you submitted it.
found	boolean	true if the domain has a confirmed mail route and at least one candidate was generated, false otherwise. Never charged when false.
status	string	OK on a hit; NOT_FOUND or BAD_FORMAT on a miss.
firstName	string	The first name as submitted.
lastName	string	The last name as submitted.
domain	string	The company domain, lowercased.
hasMailRoute	boolean	Always true on a hit — the domain has an MX or, failing that, an A record.
mostLikelyEmail	string	The single top-ranked candidate address.
mostLikelyPattern	string	Which pattern produced it (e.g. first.last, flast).
candidateEmails	array of strings	Every ranked candidate, most-likely first.
candidateCount	number	How many distinct candidates were generated (duplicates from short names, e.g. first and flast colliding, are removed).
mailboxVerified	boolean	Always false — see the honesty note above. Never becomes true; it exists so a buyer's pipeline can filter on it deliberately rather than assume verification happened.
bestEmail	string	Present when verify is on (default). The top-ranked candidate after the disposable-domain and catch-all check, same address as mostLikelyEmail unless a future depth reorders it. null when verify is off.
bestEmailStatus	string	catch-all (the domain is a known disposable/temp-mail provider that accepts any address), or unknown (a real, non-disposable mail route exists, but no HTTP-only signal can confirm this specific mailbox). Never valid, see the honesty note above. null when verify is off.
mxProvider	string	google, microsoft, or other, based on the domain's MX records. null when the domain has no MX record at all (an A-record-only mail route).
isCatchAll	boolean or null	true for a known disposable/temp-mail domain, false when the domain can't receive mail, null when a real mail route exists but catch-all behavior can't be confirmed without SMTP.
confidence	number (0-1)	How common bestEmail's pattern is across real companies (see the Price section for the exact formula). Not a deliverability guarantee. null when verify is off.
patternsTried	array of objects	The top 3 ranked candidates that were checked: { pattern, email, status, confidence } each. null when verify is off.
scrapedAt	string (ISO 8601)	Timestamp of the mail-route check for this row.
message	string (miss rows only)	Human-readable reason for a miss.

Run it on a schedule

Email patterns don't change often, but the people at a company do — new hires join the same domain on the same convention. Point people at a growing lead list and schedule this actor to re-run it: a fresh check every day picks up newly-added names against domains you're already tracking, and a name that resolved yesterday costs nothing to re-check today since you're only billed again if the row is re-submitted.

Set people to your running list of names and domains (the same First Last, domain.com format as any other run). Schedule it in Apify (Schedules > Create) or trigger it from n8n/Make; each run is billed the same per-row rate as any other run.

Price

$4 per 1,000 people + domains, plus a $0.00005 start fee. Misses (found:false) are never charged.

$4 per 1,000 people, plus a $0.00005 start fee, the same rate as this portfolio's other validator-class actors (email-deliverability-check, iban-bic-validator). A domain with no mail route is never charged.

Verified-email bonus. When verify is on (default) and a candidate resolves to bestEmailStatus: "catch-all", a second event adds +$0.002 to that row, once. A bestEmailStatus: "unknown" row (the common case: a real, non-disposable mail route) is never charged the bonus, only the base $4/1k rate applies. Turn verify off to skip verification and the bonus entirely.

confidence is PATTERN_PRIOR[pattern] (roughly Hunter.io-style pattern-popularity ordering, e.g. first.last is 0.42, a bare last is 0.03), demoted to 0.02 across the board if the domain can't receive mail at all, and cut to 30% of its usual value for a candidate whose local part happens to collide with a role address (sales@, info@, and the like). It is the same score for catch-all and unknown rows, since neither status confirms which specific local part actually belongs to the person.

How to use

1. In the Apify Console. Open the actor page and click Start — the people field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~email-pattern-finder/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"people":["Jane Doe, acme.com"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

1. Paste one person per line as First Last, domain.com (an @ also works instead of the comma). A first and last name are both required — a single name (a mononym, or a first-name-only lead) doesn't have enough signal to rank patterns against and comes back BAD_FORMAT.
2. Press Start. Each line becomes one dataset row, tagged found: true or found: false.
3. Use bestEmail (the verified top pick) as your first guess, or take the whole candidateEmails list into a separate deliverability check (this portfolio's own email-deliverability-check, or your own SMTP-capable verifier) before sending anything.
4. Export the dataset as CSV/JSON, or pull it via the API — onlyFound and columns (see the integrations section below) let you trim the response before it lands in your table.

Bulk example — a real lead list is rarely one line. This is the same people field with 25 names and domains pasted in at once:

{
  "people": [
    "Jane Doe, google.com",
    "John Smith, microsoft.com",
    "Alice Johnson, apple.com",
    "Bob Lee, amazon.com",
    "Carol White, meta.com",
    "David Kim, netflix.com",
    "Emma Brown, salesforce.com",
    "Frank Zhang, adobe.com",
    "Grace Liu, oracle.com",
    "Henry Davis, ibm.com",
    "Isabel Garcia, intel.com",
    "Jack Wilson, cisco.com",
    "Karen Moore, sap.com",
    "Liam Taylor, shopify.com",
    "Mia Anderson, stripe.com",
    "Noah Thomas, spotify.com",
    "Olivia Martin, airbnb.com",
    "Peter Jackson, uber.com",
    "Quinn Harris, slack.com",
    "Rachel Clark, zoom.us",
    "Sam Lewis, dropbox.com",
    "Tara Walker, hubspot.com",
    "Umar Hall, twilio.com",
    "Victoria Young, atlassian.com",
    "William King, github.com"
  ]
}

At the headline rate of $4 per 1,000 people (plus the $0.00005 start fee), 25 people costs about $0.10 if every one resolves — misses are free, so a list with a few dead domains costs less.

Input

{
  "people": [
    "Jane Doe, acme.com"
  ]
}

One per line: "First Last, domain.com". A ranked set of likely email address candidates is generated for each, and the top 3 are run through a disposable-domain and catch-all check by default. Never mailbox-verified: no SMTP probe is possible on this runtime. Accepted formats: Jane Doe, acme.com, Jane Doe @ acme.com.

Sample output

query	found	status	firstName	lastName	domain	hasMailRoute	mostLikelyEmail	mostLikelyPattern	candidateEmails	candidateCount	mailboxVerified	bestEmail	bestEmailStatus	mxProvider	isCatchAll	confidence	patternsTried	scrapedAt
Jane Doe, google.com	true	OK	Jane	Doe	google.com	true	jane.doe@google.com	first.last	["jane.doe@google.com","jane@google.com","janedoe@google.com","jdoe@google.com","jane_doe@google.com","doe.jane@google.com","doejane@google.com","doe@google.com"]	8	false	jane.doe@google.com	unknown	google		0.42	[{"pattern":"first.last","email":"jane.doe@google.com","status":"unknown","confidence":0.42},{"pattern":"first","email":"jane@google.com","status":"unknown","confidence":0.2},{"pattern":"firstlast","email":"janedoe@google.com","status":"unknown","confidence":0.12}]	2026-09-21T06:00:54.064Z

A miss looks like: {"query": "Not A Real Domain, thisdomaindoesnotexist12345zz.com", "found": false, "status": "NOT_FOUND", "message": "This domain has no mail route (no MX or A record) — it can't receive email, so no pattern was generated.", "scrapedAt": "2026-08-24T16:54:25.233Z"} — no charge, one row.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~email-pattern-finder/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"people":["Jane Doe, acme.com"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~email-pattern-finder/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"people":["Jane Doe, acme.com"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~email-pattern-finder/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"people":["{{person + domain}}"]}, mapping the row's person + domain into the people array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Email Address Finder by Domain: Company Email Pattern" — the agent will find and run this actor.

Tips

• Feed bestEmail alone into a downstream deliverability check first — it's right often enough (first.last@ and a bare first name are the two most common corporate defaults) to be worth checking before spending on the full candidate list.
• Use columns to request only bestEmail if you don't need the full ranked list — it trims the response without changing what you're charged.
• A domain with no MX or A record is a strong signal the domain itself is dead or was typed wrong — worth double-checking the source data before assuming the person doesn't exist.
• This actor does not detect which pattern a specific company actually uses from known examples — it ranks by general frequency across companies. If you already have one or two confirmed real addresses at a target company, that's stronger evidence of their actual convention than this actor's ranking.
• Turn verify off if you only want the ranked candidate list and never the verified-email bonus charge, for example when you already run your own deliverability step downstream.

vs. alternatives

For a one-off guess, most people just type first.last@company.com by hand. This actor exists for the batch case and the honesty guarantee: a whole list in, a dataset out, with the mail-route check, disposable-domain and catch-all check, and pattern ranking already done, and nothing billed for a dead domain.

	What it costs	What you get	Trade-off
This actor (email-pattern-finder)	$0.004 per resolved row (FREE tier), $0.00005 actor start, +$0.002 only on a catch-all hit, nothing for a dead domain	Ranked candidate emails, a confirmed mail-route check, and a disposable-domain and catch-all flag on the top 3, per person	Never claims mailbox-level (SMTP) verification, pair with a deliverability check before sending.
A commercial email-finder platform (Hunter, Findymail, and similar)	Roughly $0.03 to $0.10+ per lookup in credits, often with a monthly seat	Pattern-plus-verification in one step, sometimes with a confidence score from a proprietary database of confirmed hits	Pricier per row, usually bundled into a broader enrichment seat rather than callable as one column.
A decision-maker "waterfall" service (find the person, then the email, one priced call)	Roughly $0.10 to $0.14+ per contact, sometimes marketed per 1,000 (a specialty vendor in this space has been seen pricing around $140 per 1,000 domain-to-decision-maker lookups)	A named person plus a verified email in one call, including the "who is the right person" step	This actor never finds the person for you, only the email pattern once you already have a name; it does not attempt decision-maker discovery at all (see the FAQ). Orders of magnitude cheaper per row if you already have the name.
Guessing by hand	Free, your time	The same first.last@ default most people reach for anyway	No batch mode, no mail-route check, you find out a domain is dead only when your email bounces.

Prices for third-party tools are their published or observed list prices as of September 2026 and are not tracked here, check the vendor before relying on the comparison.

FAQ

Does this confirm a specific email address is real? No, it confirms the domain can receive mail, checks whether that domain is a known disposable/temp-mail provider (in which case any address is a "catch-all" hit), and ranks candidate addresses by how common each pattern is. Confirming one specific mailbox exists requires an SMTP probe, which is blocked on this actor's runtime (and most cloud platforms) to prevent spam abuse. mailboxVerified is always false.

What does verify actually check, if not the mailbox itself? Two things, both derivable without SMTP: whether the domain is on a public disposable/temp-mail blocklist (if so, bestEmailStatus is catch-all, since those services accept mail at any address by design), and which provider hosts the mailbox (mxProvider: google, microsoft, or other). A real, non-disposable mail route with no other signal comes back unknown, not valid, because nothing short of SMTP can tell "this mailbox exists" from "this mailbox doesn't, but the domain still isn't dead."

Does this find the decision-maker for me, not just the email pattern? No. This actor takes a name you already have (from a job posting, a LinkedIn profile, a team page) and turns it into a ranked, verified email guess. Finding WHO the right person is at a company is a separate problem this actor deliberately does not attempt: the only realistic sources are LinkedIn's people search (which is login-gated for automated tools) or a licensed contact database, neither of which fits this actor's plain-HTTP, no-login architecture. Pair it with your own lead source for the name.

What happens when a domain can't receive mail at all? It's a clean miss: found: false, status: "NOT_FOUND", and you're never charged. No candidates are generated for a domain that can't receive mail — there'd be nothing honest to guess at.

Why do I need both a first and last name? The ranked pattern list (first.last, flast, last.first, and the rest) needs both parts to build most of its candidates. A single name doesn't carry enough signal, so it comes back BAD_FORMAT rather than a degraded guess.

Is this cached, or a live check every run? Live. Every row runs a fresh MX/A-record check when the actor executes — there's no stored snapshot from a previous run.

Can this detect the actual pattern a specific company uses, not just a general guess? Not currently — it ranks by general cross-company frequency. If you already have a couple of confirmed real addresses at the target company, that's stronger signal than this actor's ranking and should take priority.

Does this actor use a proxy? No — the only network call is a DNS-over-HTTPS query to Cloudflare's public resolver, not a scrape of any target site, so there's no anti-bot layer to route around.

Can I schedule this to run automatically, or call it from an AI agent? Yes to both. Set up an Apify schedule for recurring lead-list enrichment, or call it via the Apify API from a script or n8n/Make workflow. It's also discoverable through the Apify MCP server, so an AI agent (Claude, Cursor, or any MCP client) can find and run it directly by name — see the integrations section above.

Related actors

• LinkedIn Profile Lookup — get the name and current company for a decision-maker from their public profile URL, the name+domain pair this actor needs as input.
• Email Deliverability Check — mail route, disposable-domain and role-address flags, and provider fingerprint for a specific email address (run this actor's candidates through it before sending).
• Domain RDAP Lookup — registrar, registration and expiry dates for the same domains.
• Company Domain Enrichment — multi-source company intelligence fan-out from a single domain.

If this saved you a scrape, a rating on the Store page helps other buyers find it.