To find a professional email address, start with an official page or an address the person has chosen to share. If that does not work, use a reputable finder with the person’s name and company domain, record the evidence behind the result, and verify the address before deciding whether to contact the person.
Keep three decisions separate: whether an address was discovered, whether the mailbox appears deliverable, and whether your intended use is appropriate. A missing result does not prove that no address exists. A verification result does not guarantee future delivery, ownership, or permission to send.
For example, if Alex Morgan works at example.com, first check an official company page or visible profile contact information. Only then consider a documented name-and-domain lookup for [email protected]. Treat any result as a candidate until its source, status, and intended use have been reviewed.
Choose a lookup route based on what you already know
Use the least intrusive route that fits the information available. An address published on an official page is stronger evidence than a pattern guess. LinkedIn visibility is controlled by the member’s settings, so inspect Contact info only when it is visible to you. Do not scrape hidden fields or treat a missing address as proof that none exists.
Search operators can help locate pages where an address was actually published. Search for the person’s name with the company domain or the word “contact,” then inspect the page itself. A conference biography, press release, or PDF may be outdated, so record the page and the date you checked it. Do not cycle through likely formats such as [email protected] and treat a match as confirmation.
LinkedIn connection exports also have limits. An email is included only when the connection’s settings authorize its visibility or download. LinkedIn says Sales Navigator does not generally export account and lead information to CSV or XLS. Use its guidance on connection data exports and Sales Navigator export limits rather than assuming that it is a universal lead-email export tool.
Read the evidence behind a finder result
An email finder result needs context. Record whether the address was published, returned with a source, inferred from a pattern, or guessed. These categories describe evidence for the address. They do not describe whether the mailbox currently accepts mail.
- Published on an official page: The address is visibly listed on a company or personal page. This is direct evidence of publication, although the page may be old.
- Provider result with a source: A finder returns an address and a source URL or review date. Inspect the source and retain it.
- Inferred: The provider estimates an address from available information or a company pattern. It was not necessarily published publicly.
- Format guess: Someone applies a pattern without evidence that this person’s mailbox exists.
- Unverified guess: An address is proposed without a reliable source or mailbox check. Do not mark it as confirmed.
Hunter distinguishes Found and Inferred results and may provide source URLs and source-review dates. That describes Hunter’s own sourcing, not every provider’s method. Apollo describes a mix of contributor data, engagement signals, public web crawling, and third-party providers. Review each provider’s documentation before making assumptions about collection, retention, or accuracy.
A plausible company-format address is not the same as a publicly evidenced address. Store source type and source date separately from mailbox verification status. One confidence score cannot explain both.
Verify the address without overstating the result
A dedicated verifier assesses technical signals. Hunter documents checks including address format, disposable-domain status, mail-exchange records, and SMTP connectivity. Its results can include Valid, Invalid, Accept-all, and Blocked. These are observations at a point in time, not proof of inbox ownership, future delivery, or permission to contact.
- Valid: The verifier’s checks support the address at the time of the check. It is not a delivery guarantee.
- Invalid: The verifier found a problem with the address or its technical configuration. Review the details before discarding the candidate.
- Accept-all: The domain may accept mail for addresses whether or not an individual mailbox exists. Treat the individual result as inconclusive.
- Blocked or Unknown: The service could not complete its checks or reach a reliable conclusion. Route the result for review rather than approving a send.
Gmail autocomplete is not a mailbox-verification test. A suggestion may reflect a saved or otherwise recognized contact. No suggestion does not establish that the address is invalid, and a suggestion does not establish deliverability.
If an email bounces, retain the complete SMTP response, enhanced status code, and diagnostic text. A three-digit code alone is insufficient. Gmail’s documentation gives examples where 421 and 450 responses can reflect temporary, rate-related, or policy issues, while 550 can reflect more than a nonexistent recipient. Follow the receiving server’s diagnostic and retry guidance instead of assigning every 550 the same cause.
Record a candidate before updating the CRM
Keep the candidate address, its evidence, verification observations, and outreach events as separate records or fields. The contact record represents the person. A verification run represents an observation at a particular time. A send or bounce represents an outreach event. Separating those grains makes later review possible.
A practical candidate record might include:
email_address,person_name_at_lookup, andcompany_domain_at_lookupprovider,provider_record_id,source_type, andsource_urldiscovered_at,verification_status,verified_at, andverification_run_idreview_status,reviewer, andsuppression_checked_at
The following is an illustrative schema, not a vendor-prescribed model:
{
"candidate_id": "candidate-1042-01",
"email_address": "[email protected]",
"person_name_at_lookup": "Alex Morgan",
"company_domain_at_lookup": "example.com",
"provider": "illustrative finder",
"source_type": "inferred",
"source_url": null,
"discovered_at": "2026-11-13T10:30:00Z",
"verification_status": "Accept-all",
"verification_run_id": "verify-1042-01",
"review_status": "pending"
}Before writeback, check that the domain matches the intended company or document the exception, inspect existing CRM values, and check suppression, opt-out, and prior-bounce records. Do not silently replace a manually confirmed address with an inferred candidate. Create a separate candidate or review item instead. Well-designed CRM systems preserve that history instead of collapsing every observation into the contact’s current email field.
- Source type, source reference, and lookup timestamp are present.
- The company domain matches, or a reviewer has documented the exception.
- Verification status, verification timestamp, and run identifier are recorded.
- Suppression, opt-out, and prior-bounce fields have been checked.
- An existing confirmed value is preserved and duplicate handling is enforced.
Define the row grain before automating writes. A person, an email candidate, a verification observation, and an outreach event are different entities. A proposed candidate key might combine a normalized person or company association, normalized email address, and provider, but the correct uniqueness rule depends on the system’s purpose. Do not use email address plus date as a universal key.
When concurrent workers can process the same request, a lookup-then-create sequence is not sufficient. Enforce the intended uniqueness rule in the database and use an atomic upsert or transaction. If a unique-key conflict occurs, reload the existing candidate and attach the new verification observation rather than retrying a blind insert. Store materially different verification runs separately when auditability matters.
Use AI and automation for bounded, reviewable work
AI can extract a name and company from supplied text, summarize source evidence, classify an intended purpose, or suggest the next lookup route. Use deterministic rules for syntax, domain matching, disposable-domain handling, allowed status values, suppression checks, duplicate prevention, retry limits, and opt-out enforcement. Those checks should run before a CRM write or send.
Zapier MCP can let an authorized AI client call available Zapier app actions through connected credentials. It does not guarantee that a particular finder, verifier, CRM, or email-send action is available in your account. Confirm the actual actions and fields before designing the workflow. Keep discovery read-only until approval, limit enabled actions to what the task requires, and retain action history for audit. See Zapier’s MCP documentation. A considered Zapier automation design also needs exception handling for unavailable actions, expired credentials, rate limits, and ambiguous output.
Let AI prepare evidence. Let deterministic rules and an accountable reviewer decide whether a candidate can change the CRM or trigger outreach.
A proposed single-person workflow can use this sequence:
- Collect: The operator supplies the person’s name, company domain, intended use, and source-record ID.
- Discover: A documented finder receives the name and domain. Store the returned address, provider, source type, source URL if available, provider identifier, and discovery time.
- Validate: Deterministic checks confirm syntax, company-domain match, status, existing contact, suppression state, and prior-bounce information. Inferred or inconclusive results go to a reviewer.
- Review and write: A sales-operations or privacy reviewer approves, rejects, or requests more evidence. Only an approved candidate is written to the CRM, with the prior value and provenance preserved.
- Measure: Track completed reviews, rejected candidates, duplicate conflicts, verification observations, and delivery outcomes as distinct measures. A verification observation is not a successful send.
Hunter documents separate Email Finder and Email Verifier operations in its API reference. That documentation does not establish the CRM approval process above. The finder, verifier, CRM, approval step, and email tool should be treated as a proposed architecture until the connected account’s actions and field mappings have been tested.
AI agents can assist with extraction and evidence summaries, but they should not authorize an inferred address or make a suppression decision.
Check whether the intended contact is appropriate
Locating an address is different from storing, profiling, or contacting the person. Public availability alone does not establish that every use is appropriate. Before outreach, classify the purpose, check do-not-contact and opt-out records, and respect a direct objection.
In the United States, the FTC’s CAN-SPAM guidance covers commercial email requirements including accurate header information, non-deceptive subject lines, a valid physical postal address, and a functioning opt-out. The message’s primary purpose matters. In the EU, legitimate interest can be a basis for direct marketing under GDPR in some circumstances, but it is not blanket permission. Rights, reasonable expectations, transparency, objection rights, and applicable ePrivacy and national rules may also apply. See the FTC compliance guide and the GDPR text. This is general information, not jurisdiction-specific legal advice.
What to do when no reliable address is available
A finder may return no result because public information is limited, pages are blocked, the domain is wrong, or the provider cannot confirm a reliable match. A no-match is not evidence that the person has no professional email address.
Use a documented lookup limit, then follow this fallback order: check the organization’s official contact routes; inspect visible LinkedIn Contact info; ask through a relevant social channel for the preferred address; or send a concise request to a shared company inbox. Do not automatically send to a guessed, Accept-all, Blocked, or Unknown address. When the result remains uncertain, asking the person directly is usually more useful than escalating collection.