Email Finder vs Email Verification: What Each Proves

An email finder answers “what is this person’s address?”. Email verification answers “will mail to this address bounce?”. Teams blur them because one tool often does both, but the evidence behind each is completely different — and a sending domain’s reputation depends on not confusing a guess with a check.

The rule that follows: every found address goes through verification before it is sent to, and the confidence you attach to it should say which kind of evidence you actually have.

There are only two honest ways to produce an address for a named person:

1. 1A published address. The person’s address appears on the company website, in a press release or in structured data. This is the strongest evidence a finder can have — somebody at the company wrote it down — but people leave, and pages go stale.
2. 2A pattern applied to a name. Collect the addresses a company publishes, match them against known names, and infer the format — {first}.{last}, {f}{last}, {first} — then apply it. Most companies use one format, so the guess is often right; it says nothing about whether this particular person still works there.

Our email_pattern tool returns the second half of that for any company we hold: the format, a confidence, whether the pattern was confirmed by a live mailbox check in our own data pipeline (validated), whether the domain has MX records, and whether it is catch-all. It never returns a person’s address:

curl https://businessmcp.com/api/hub/v1/companies/acme.com/email-pattern \
  -H "Authorization: Bearer $BUSINESSMCP_API_KEY"

The person-level email_finder (15 credits per address returned, people data terms apply) returns a stored address with the status our pipeline recorded when we hold the person — otherwise it applies the pattern and labels the result email_status: "pattern": built, never checked, verify before sending.

Verification is a stack of checks, cheapest first. Each removes a class of bounce; none of the DNS-level ones can prove a mailbox exists.

The catch-all row is the one people miss. On a catch-all domain every address “exists” at the SMTP level, including typos, so no verifier — SMTP or not — can separate a real mailbox from a wrong guess. Treat catch-all as risky, not as valid.

An SMTP probe connects to the domain’s mail server and walks through the start of a delivery — EHLO, MAIL FROM, RCPT TO:<address> — then hangs up before sending anything. The server’s reply to RCPT TO is the only mailbox-level evidence available without actually sending. (The older VRFY command, defined in RFC 5321, is disabled almost everywhere.)

On a server that answers honestly, that reply is genuinely useful: it catches the person who left, the misspelled name, the pattern that was right for the company but wrong for this employee. That is why dedicated verifiers run it. But it has real costs:

• Greylisting. Many servers temporarily reject unknown senders (RFC 6647) and only accept a retry minutes later, so a probe either waits or returns “unknown”.
• Catch-alls and accept-then-bounce servers. Some servers accept every recipient at RCPT TO and bounce afterwards, which makes the probe’s “yes” meaningless there.
• Rate limits and blocks. Mail providers treat bursts of abandoned SMTP sessions as directory harvesting. Probing from your own sending IPs risks exactly the reputation you are trying to protect.
• Time. A probe is a network conversation with a remote server. Hunter’s verifier, for example, allows up to 20 seconds and returns HTTP 202 to poll when it needs longer (Hunter API docs).

The Data API’s email_verify runs every check in the table except the SMTP probe: syntax, a live MX lookup, disposable and free-mail lists, role inboxes, our catch-all cache, and whether the local part fits the company’s known pattern. It never opens an SMTP session, so it never claims the mailbox exists. The best verdict it can give is domain_ok — the domain accepts mail — and the reason says so in words.

curl -X POST https://businessmcp.com/api/hub/v1/emails/verify \
  -H "Authorization: Bearer $BUSINESSMCP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"jane.doe@acme.com"}'

{
  "email": "jane.doe@acme.com",
  "verdict": "domain_ok",
  "reasons": [
    "The domain accepts mail. The mailbox itself was not contacted."
  ],
  "checks": {
    "syntax": true,
    "mx": [
      "aspmx.l.google.com"
    ],
    "catch_all": false,
    "disposable": false,
    "free_mail": false,
    "role": false,
    "fits_company_pattern": true,
    "company_pattern": "{first}.{last}"
  }
}

It costs 1 credit per call and is covered by the 1,000 free monthly credits. Used as a pre-send filter it removes the cheap bounces — dead domains, typos in the domain, disposable signups, shared inboxes — before you pay a mailbox-level verifier for the rest.

Verification protects you from bounces, not from spam folders. Authentication decides whether mail that is delivered is trusted, so pair this with a correctly configured SPF, DKIM and DMARC setup — you can check a domain’s records with the free email deliverability checker.