How to Find Company Email Addresses: A Permission-First Workflow

To find a company email address responsibly, start with the company’s public contact route, a relevant professional introduction, or a documented business-email research tool. Confirm the business purpose, capture where any result came from, and review it before deciding whether it belongs in the CRM or should be used for outreach.

If you do not know who handles procurement, partnerships, or another business need, write to the published company or department address and ask to be routed. If you have a clear reason to contact a named person, use a targeted research process rather than guessing an address or buying a bulk list.

An address being discoverable, appearing deliverable, belonging to the intended person, and being appropriate for outreach are separate questions. This guide covers business-contact research and CRM controls, not a legal determination about cold email. Its focus is relevant, traceable records and a controlled approval process.

Choose the right route before searching

Choose the least intrusive route that can answer the business question. When the right person or department is uncertain, use the company’s contact page, general inbox, or main line and ask to be routed. A staff or author page can help confirm someone’s role and may provide a stated contact route, but a public listing is not evidence of consent.

A mutual contact or existing professional interaction may provide useful context. Requesting an introduction can be more respectful and more effective than using a person-level lookup without any relationship. A newsletter, professional community, or social channel can also be a route for building context, but do not treat participation or visibility as permission to add someone to a campaign.

When the person, company domain, and business purpose are clear, a targeted research tool may help. Hunter documents three different operations: Domain Search finds addresses associated with a company or domain, Email Finder searches for a named person, and Email Verifier checks an address’s deliverability status. These operations provide research evidence, not consent or certainty that the address belongs to the intended individual.

Route	Best use	Next step
Public company route	The person or team is uncertain	Ask the general inbox or switchboard to route the inquiry
Professional introduction	A mutual contact or relevant interaction exists	Request an introduction with a clear business reason
Targeted email research	A named person and business purpose are established	Capture the source, review the result, and apply the outreach gate

A controlled workflow for researching and recording an address

Use a staged process so a lookup result does not silently become the contact’s approved email. The CRM should hold the current approved value. A research log or enrichment record should hold candidates, sources, verification observations, and review decisions until they pass your organization’s acceptance policy.

Check the email domain rather than assuming it. Hunter’s Domain Search documentation says results can include sources, dates, public or inferred indicators, verification status, and confidence information. These details help assess evidence but do not settle identity or outreach eligibility. See Hunter’s explanation of Domain Search results.

Illustrative implementation model, not a HubSpot or Hunter schema: this example represents one enrichment observation, not the contact’s full history or a source record.

{
  "event_id": "illustrative-uuid-8f31",
  "contact_id": "illustrative-contact-42",
  "provider": "Hunter",
  "operation_type": "Email Finder",
  "candidate_email": "[email protected]",
  "source_url": "https://example.com/team/jordan-lee",
  "source_type": "public_staff_page",
  "confidence": "provider_value_or_null",
  "verification_status": "not_checked",
  "observed_at": "2026-10-14T10:30:00Z"
}

Store each lookup observation as a separate event with its own ID and timestamp. Store each supporting URL as a source record when a finding has multiple sources. The contact record holds the current approved email, while a decision log explains why that value was selected. Do not use contact ID plus date as the only key when multiple providers, retries, or source pages are possible.

For concurrent workers, a read-then-insert check is not sufficient because two workers can observe the same blank field. Use a database-enforced unique constraint or a transactional upsert where supported. A proposed lookup-event key is a provider request ID when supplied, or a generated event UUID otherwise. A proposed input-specific key could combine normalized contact ID, provider, operation type, normalized input hash, and algorithm version. These are application design choices, not vendor-published fields.

Use deterministic rules for blank versus populated fields, email syntax, normalized domains, suppression checks, existing-record matching, and allowed verification values. AI may classify a public page as a likely contact page or summarize why a source appears relevant. It should not decide identity, consent, permission to contact, or whether to overwrite an existing email field. For teams designing ownership and review workflows, see CRM systems and workflows.

What HubSpot and LinkedIn integrations can and cannot do

HubSpot contact profiles can show CRM contact details and recent sales activity in supported Outlook experiences. The documented functions include reviewing contact information and activity, editing properties, creating tasks, and associating related CRM records. HubSpot’s legacy Outlook desktop add-in is in maintenance mode, and HubSpot recommends the Sales Office 365 add-in for current Outlook for Mac, PC, and the web. These profiles are useful for reviewing an existing CRM contact, not documented as a general-purpose way to discover arbitrary new email addresses. Consult the current HubSpot contact-profile documentation.

HubSpot’s LinkedIn Sales Navigator integration displays LinkedIn insights and activity on matching HubSpot contact and company records. HubSpot documents a Sales Hub Professional or Enterprise requirement and a LinkedIn Sales Navigator Advanced Plus requirement. The integration uses existing CRM fields, including email when present, to help match profiles, and HubSpot states that it cannot import contacts from LinkedIn. It is therefore not documented as a way to extract an unknown email address from LinkedIn.

Use the integration for context on an existing record, such as job title, company, time in role, location, industry, shared connections, or possible introduction context. Confirm the record match and subscription requirements before relying on it. For implementation planning, see HubSpot systems support.

Write back to the CRM without losing provenance

Hunter documents a HubSpot integration with configurable field mappings and synchronization settings. It can synchronize leads, create contacts, optionally create deals, and link a lead to an existing HubSpot contact when the same email already exists. Hunter also states that its documented record action does not overwrite an existing HubSpot email field when saving a found result.

That email-based behavior is useful protection, but it is not universal duplicate resolution. It does not resolve every contact who shares a name, company, or domain, and it does not replace an organization’s review policy.

Use a two-stage write:

1. Candidate observation: store the proposed address, provider, operation, confidence, verification result, source, timestamp, input hash, and request identifier without changing the approved email.
2. Approval or deterministic acceptance: compare the candidate with the current CRM value and suppression records. Write only when the acceptance policy passes, and retain the prior value and decision history.

Keep these data grains distinct:

• Contact record: one current approved email value and current status.
• Enrichment observation: one lookup or verification result for one target at one time.
• Source record: one URL or evidence item that supports an observation.
• CRM decision event: one approval, hold, rejection, or update action.
• Period metric: an aggregate over a stated time window, such as approved unique contacts, not a replacement for individual events.

Before a write, check the target record’s current email, suppression state, company identity, and ownership. Route inferred or conflicting findings to a named reviewer. If a team uses automatic synchronization, verify permissions and field mappings first. Hunter notes that synchronization behavior depends on its configured settings and that email matching is the basis for its documented existing-contact link.

Decide whether to contact the person and what to measure

A public listing or deliverability check does not establish identity certainty, consent, or legal permission to contact. Keep outreach eligibility separate from research status. Proposed fields such as permission_status, suppression_status, source_type, and last_reviewed_at are workflow design choices, not HubSpot-published schema.

Apply suppression and eligibility rules before campaign activation. Respect opt-outs, unsubscribes, blacklists, expressed disinterest, and applicable jurisdiction-specific requirements. If a person has asked not to be contacted or has clearly indicated disinterest, stop or suppress the outreach route rather than searching for another address.

Google advises senders not to purchase email addresses and recommends sending to people who want messages from the sender. Google also explains that spam reports can affect sender reputation and that unauthenticated messages may be marked as spam or rejected. This is Gmail sender guidance, not a universal legal ruling or a threshold for every mailbox provider. Review Google’s email sender guidelines and its additional Gmail sender guidance.

Measure activity at the correct grain:

• Lookup attempts: provider or public-source research events, including failures.
• Successful findings: provider outcomes that return a candidate, whether or not the candidate is approved.
• Verification observations: individual checks for an address at a specific time.
• Approved unique contacts: distinct CRM contacts whose candidates passed the acceptance policy.
• Replies, meetings, and revenue: later engagement or commercial outcomes, not lookup results.

Define the time period and denominator for every rate. A count of repeated attempts is not a count of newly enriched people, and a provider response is not an approved CRM update.

Common failure cases and practical checks

An accept-all domain or inconclusive verifier response does not prove that an address is valid or invalid. Hold the candidate for review rather than marking it confirmed. An inferred pattern should remain a candidate until it passes the organization’s checks. If a personal address appears instead of a business route, escalate it to a human owner rather than treating it as interchangeable.

If the CRM already contains a different email, preserve the current value, log the new observation, and request review. Do not overwrite it merely because a provider returned another candidate. For a rate-limit response, record the failed attempt and use a bounded retry queue with backoff. This is implementation guidance, not a vendor-prescribed retry policy. Hunter documents API limits, so consult its API reference when configuring request volume.

Close or defer unresolved attempts rather than retrying indefinitely. A defensible CRM record explains what was observed, where it came from, how the candidate was evaluated, and who approved the next step. That is more useful than a guessed address stored without context, and it keeps research readiness separate from authorization to send.