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). Everything runs as this Actor's own code by default: DNS lookups, pattern generation, and optional public-data enrichment (company website, GitHub, Gravatar) - no third-party API key required to use it. This Actor does not do live SMTP mailbox probing itself (see "Why this Actor doesn't do live SMTP checks" below for why). Optionally, for the specific cases where that leaves a result honestly "unknown", it can call a paid, real-time mailbox verification API (ZeroBounce) for a real answer - see "Optional: real-time mailbox verification (ZeroBounce)" below.

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, and a confidence score built from the domain's DNS and email-authentication setup).
• 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.

resultStatus is deliberately simple: it only ever takes three values, valid, invalid, or unknown. If most of your rows show "unknown" rather than a flat "valid", 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, including why a row was marked valid (direct evidence vs. a strong signal vs. a live ZeroBounce check) or how weak an unknown guess is. Read that field before worrying about anything else.

The short version: no email tool, on Apify or anywhere else, can safely and reliably confirm one specific mailbox exists without a live SMTP conversation with the target mail server, and this Actor deliberately doesn't attempt that itself (see below). So by default, resultStatus is built entirely from real, checkable signals instead:

resultStatus	What it means
invalid	Either the address isn't validly formatted, or the domain has a confirmed absence of any MX record and cannot receive mail at all, or (only when verifyWithZeroBounce is on and used) a live mailbox check flagged the address as nonexistent, a spam trap, an abuse complainer, or on a do-not-mail list. statusMeaning tells you which.
valid	Either this exact address was directly observed in public data (contact mode only: the company website or a GitHub commit), the domain has a full email-authentication setup (MX + SPF + DKIM + DMARC all found, a strong signal), or (only when verifyWithZeroBounce is on and used) a live ZeroBounce check confirmed the mailbox directly. statusMeaning tells you which kind of "valid" this is.
unknown	Looks plausible, but there isn't enough evidence to call it valid or invalid, even after an optional live check (ZeroBounce also returns "unknown" for catch-all domains and inconclusive checks). This covers everything from "reasonable guess" to "weak long shot" - check statusMeaning and confidenceScore to tell those apart.

Use confidenceScore (0 to 100) as your finer-grained signal, higher means more likely to be a real, deliverable address, and statusMeaning for the plain-English reason behind the specific row.

Why this Actor doesn't do live SMTP checks itself

Outbound port 25, the port live SMTP mailbox verification needs, is blocked on Apify's infrastructure (and on most cloud platforms), so a live "does this mailbox actually exist" probe almost never gets a real answer there anyway. Worse, sending a speculative RCPT TO to a mail server you don't own, to test whether some address exists, is exactly the kind of sending behavior that gets IPs rate-limited or blacklisted by receiving providers. We don't think that tradeoff, unreliable results in exchange for a real deliverability risk, is worth it, so this Actor's own code doesn't do it at all.

Some competing actors do attempt it, and quietly treat 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.

Instead, by default every result here is built from signals that are actually real and checkable:

1. MX records — can the domain receive mail at all? A confirmed absence is the only thing that produces "invalid" on its own (alongside a bad format).
2. SPF, DKIM, and DMARC — does the domain have a genuine, complete email-authentication setup? All three present is a meaningfully strong signal for a domain a business actually controls and runs, so it earns "valid" (with statusMeaning noting it's a strong signal, not direct confirmation).
3. Direct evidence (contact mode only) — was this exact address found on the company's own website, or in public GitHub commit history? That's real observed evidence, not a guess, so it also earns "valid" (with statusMeaning noting it's confirmed via direct evidence).

One important nuance: for free webmail domains (Gmail, Outlook, Yahoo, etc.), MX/SPF/DKIM/DMARC are essentially always fully present, that's true of every address at that domain, real or made up, so those records say nothing about whether one specific username exists there. This Actor accounts for that: domain-authentication signals only earn their full confidence bonus for a domain the target actually controls (a custom company domain), not a shared free provider. That's why test@gmail.com correctly stays "unknown" from the free DNS-based checks alone, even though gmail.com itself has perfect SPF/DKIM/DMARC. If you personally know a specific Gmail-style address is real and need that confirmed rather than just scored, that's exactly the gap verifyWithZeroBounce (below) is for.

Optional: real-time mailbox verification (ZeroBounce)

For emails and contacts input modes only (never for domain-wide role discovery in domains mode), when the free DNS-based checks above would otherwise leave a result honestly "unknown" - most commonly a free-provider address like Gmail/Outlook where DNS alone can't say anything about one specific username, or an unconfirmed pattern guess for a contact - this Actor can optionally call ZeroBounce's real-time, paid mailbox-verification API for an actual answer, controlled by the verifyWithZeroBounce input field (on by default).

A few things worth knowing about this tier:

• It only ever fires when DNS alone would say "unknown." If a result is already "valid" or "invalid" from the free checks (a confirmed-absent MX record, direct website/GitHub evidence, or a fully-authenticated custom domain), no ZeroBounce credit is spent, it's already resolved. It also never fires for a domain that isn't confirmed to have MX records at all, there's no reason to pay for a live check on a domain that can't receive mail, or one that wasn't looked up (verificationLevel: "format").
• It's a real, metered cost to the Actor, not something you configure with your own API key. Rows that actually consume a live ZeroBounce check are billed at a separate, higher pay-per-event rate (see Pricing below) than the standard DNS-only rate, since it costs real money per lookup. If a row didn't need ZeroBounce (DNS alone already resolved it, or ZeroBounce wasn't reached), you're only charged the standard rate.
• It adds two new fields when used: verificationMethod will read "zerobounce", and zeroBounceStatus carries ZeroBounce's own raw status (valid, invalid, catch-all, unknown, spamtrap, abuse, or do_not_mail) for full transparency into what it actually reported.
• A confirmed "valid" from ZeroBounce sets isVerified: true - the one case in this Actor (alongside direct website/GitHub evidence in contact mode) where that field is genuinely earned rather than inferred from DNS signals.
• Turn it off (verifyWithZeroBounce: false) to stay entirely on the free, DNS-only signals for every result, exactly like this Actor's original behavior.

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 (syntax only) or mx (default; also checks MX, provider, and SPF/DKIM/DMARC)
verifyWithZeroBounce	Default on. For emails/contacts results that would otherwise be "unknown" after the free checks, calls ZeroBounce's real-time mailbox verification for a real answer, billed at a higher per-result rate. Never applies to domains mode. See "Optional: real-time mailbox verification (ZeroBounce)" above
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, invalid, or unknown, see the table above), statusMeaning (a plain-English sentence explaining that row's result, read this first if a status is confusing), confidenceScore, isVerified, hasMxRecords, provider, isDisposable, isFreeProvider, isRoleAccount, verificationMethod (format, mx, pattern, website, github, or zerobounce), zeroBounceStatus (only present on rows that actually used the optional ZeroBounce tier - see above), and (when enabled) deliverabilityGrade, deliverabilityScore, and deliverabilityIssues.

Pricing

$4.00 per 1,000 standard results, pay per event. Rows in emails/contacts mode that actually consume a real, live ZeroBounce check (only when verifyWithZeroBounce is on and DNS alone left the result "unknown") are billed separately at roughly $0.03 per verified result, reflecting the real per-lookup cost of that live check. You're never charged both rates for the same row, and every "domains"-mode result and every row DNS alone already resolved stays on the standard rate with no ZeroBounce involved.

FAQ

Does this Actor need any API keys?

No, not to use it. Everything by default (DNS lookups, pattern generation, deliverability grading) runs as the Actor's own code with no third-party dependency. The optional GitHub token is solely to raise the GitHub search rate limit for contact-mode enrichment. The optional ZeroBounce tier (see above) doesn't need a key from you either, the Actor owner covers that account; you just pay the higher per-result rate on the rows that actually use it.

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. By default this Actor doesn't do live SMTP mailbox probing (see "Why this Actor doesn't do live SMTP checks itself"), so "valid" from the free checks alone is reserved for cases with real observed evidence or a full email-authentication setup. If you need a real answer for a specific address that's landing on "unknown" - a free-provider address is the most common case - turning on verifyWithZeroBounce (on by default) can resolve it with an actual live mailbox check, for a real, paid, per-result cost.

Will it ever falsely mark a real email as invalid?

From the free DNS-based checks alone: no. Only a confirmed-absent MX record or a failed format check produces "invalid" there, no SMTP step that could misread a blocked connection as a rejection. If you've turned on verifyWithZeroBounce, a small share of genuinely real mailboxes can still come back "invalid" from ZeroBounce's own live check (for example a mailbox that's since been closed) - that's an actual live result from a third party, not a guess, but it's not infallible either.

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.

I own a Gmail address and it came back "unknown" - is that a bug?

No. See "One important nuance" above: every Gmail address has the same well-configured SPF/DKIM/DMARC, so those records can't distinguish a real inbox from a made-up one, and this Actor won't claim otherwise. verifyWithZeroBounce (on by default) is built for exactly this case, it calls a real, live mailbox check instead of relying on DNS alone.