Email Verifier and Finder

Find corporate email addresses, check whether an address is likely real, and grade a domain's email deliverability setup (SPF, DKIM, DMARC), with zero third-party API dependency. Everything runs as this Actor's own code: DNS lookups, pattern generation, and optional public-data enrichment (company website, GitHub, Gravatar).

What it does

Give it any mix of three input types in one run:

• emails, a list of specific addresses to check (format, MX/provider, disposable/free/role detection, best-effort SMTP).
• contacts, a list of {firstName, lastName, domain}. Generates the common corporate email patterns (first.last@, flast@, first@, etc.), ranks them, and optionally cross-checks the company website, GitHub commit history, and Gravatar for a real observed match.
• domains, a list of domains. Tests common role addresses (info@, contact@, sales@, support@, hello@, admin@) and reports which ones the domain could plausibly deliver to.

Every result also gets an optional deliverability grade (A+ to F) for the domain's SPF, DKIM, and DMARC setup.

First time seeing your results? Read this first.

If most of your rows show resultStatus: "unknown" and isVerified: false, that is the normal, expected result, not a sign this Actor is broken or that your email is bad. Every single row also includes a statusMeaning field with a plain-English sentence explaining exactly what that specific result does and doesn't tell you. Start there before worrying about the other fields.

The short version: no email tool on Apify (or most cloud platforms) can directly confirm a specific mailbox exists, because the network port that kind of check needs is blocked. So isVerified: true is rare by design, and "unknown" for an address with the right format on a domain that can receive mail is actually a good result, it means everything checkable looked fine, we just can't 100% prove that one inbox exists. Use confidenceScore (0 to 100) as your real signal: higher means more likely to be a real, deliverable address. The only results that mean something is actually wrong are "invalid_format" (typo'd address) and "invalid" (domain confirmed to have no mail server, or a mail server that explicitly rejected it).

Why this Actor is honest about "unknown"

Outbound port 25, the port real SMTP mailbox verification needs, is blocked on Apify's infrastructure (and on most cloud platforms). We confirmed this by direct testing before building this Actor. That means a live "does this mailbox actually exist" check will almost never get a real answer here, on this Actor or any other.

Some competing actors handle that by quietly treating a failed or blocked connection as proof the address is invalid. We tested one directly: it reported postmaster@github.com, an address guaranteed to exist by RFC, as invalid, with the exact same output as a genuinely nonexistent address. That's not a verification result, it's a coin flip dressed up as one, and it will get real, deliverable leads thrown out of your list.

This Actor never does that. A blocked or failed connection is reported honestly as "unknown" (or, in contact/domain mode, folded into the confidence score), never as "invalid". The only ways to get "invalid" are:

1. The address fails basic format validation.
2. The domain has confirmed no MX record at all (a real DNS answer, not a timeout), meaning nothing can ever be delivered there.
3. Verification level is set to smtp and the target mail server actually answered with an explicit rejection (rare on cloud platforms, but it does happen with a few misconfigured or permissive servers).

Every other case is "valid" (explicit SMTP acceptance) or "unknown" plus a confidenceScore (0 to 100) built from MX presence, pattern commonality, and any direct evidence found (website, GitHub, or Gravatar match).

Input

See the input schema for full details. Key fields:

Field	Description
emails / contacts / domains	The three input modes, use any combination
emailsFile	Optional CSV upload as an alternative to emails. Single column, no header row
contactsFile	Optional CSV upload as an alternative to contacts. Header row required, with columns firstName, lastName, domain, and an optional linkedinUrl column
verificationLevel	format, mx (default), or smtp, your choice
detectCatchAll	Flags domains that accept mail to any address (requires smtp level to get a real answer)
maxPatternsToTest	How many email patterns to try per contact (default 8)
checkDeliverability	SPF, DKIM, and DMARC grade for the domain
checkWebsite / checkGitHub / checkGravatar	Extra enrichment for contact mode: company website, GitHub, and Gravatar lookups. All three are free (no extra cost) and on by default
githubToken	Optional token for higher GitHub API rate limits

For contacts, firstName, lastName, and domain (the contact's company website domain, e.g. example.com) are all mandatory, whether you enter them as JSON or upload them as a CSV. linkedinUrl (optional) can be added too, it's simply passed through to the result for your own reference. For emails, you can either use the Bulk edit box or upload a single-column, no-header CSV in emailsFile instead.

Output

One dataset row per result, including: email, resultStatus (valid, unknown, invalid, invalid_format, or low_confidence), statusMeaning (a plain-English sentence explaining that row's result, read this first if a status is confusing), confidenceScore, isVerified, hasMxRecords, provider, isCatchAll, isDisposable, isFreeProvider, isRoleAccount, verificationMethod, and (when enabled) deliverabilityGrade, deliverabilityScore, and deliverabilityIssues.

Pricing

$4.00 per 1,000 results, pay per event. No hidden per-call costs from third-party services, this Actor doesn't call any.

FAQ

Does this Actor need any API keys?

No. Everything (DNS lookups, pattern generation, deliverability grading) runs as the Actor's own code. The only optional key is a GitHub token, used solely to raise the GitHub search rate limit for contact-mode enrichment.

Why does my result say "unknown" instead of "valid" or "invalid"?

That's expected for most real, deliverable addresses, see "First time seeing your results? Read this first" above and the statusMeaning field on the row itself. It means the address looks valid and the domain can receive mail, but a live mailbox check isn't possible on this platform (or any cloud platform), so we honestly say "unknown" instead of guessing. Check confidenceScore for a 0-100 likelihood instead.

Will it ever falsely mark a real email as invalid?

No. A blocked or failed connection (common on cloud platforms where port 25 is closed) is always reported as "unknown", never "invalid". Only a confirmed-absent MX record, a failed format check, or an explicit SMTP rejection produces "invalid".

Can I upload a list of names and domains and get back verified emails?

Yes, that's the contacts input mode: give it firstName, lastName, and domain for each row, and it returns the best-candidate email with a confidence score.

Can I check whether a domain's email setup will land in spam?

Yes, turn on checkDeliverability. It grades the domain's SPF, DKIM, and DMARC records (A+ to F) and lists specific issues found.