How to Scrape Emails From LinkedIn (2026)

I tried to scrape an email from a LinkedIn profile the obvious way first: fetch the public page and read the contact field. The field was not there. That is the first thing to understand about how to scrape emails from LinkedIn, because the address you want is almost never on the public page. The job is not really scraping an email, it is resolving a verified work email from the fields that are public.

Here is what I ran in July 2026, why the email is missing from the page, and the routes that actually produce a usable address: the public profile record, the pattern-and-verify method in Python, and a scraper API that returns the profile data without a login. Every code sample below is code I executed myself against live LinkedIn pages.

Can you actually scrape emails from LinkedIn?

You can scrape a LinkedIn profile’s public fields, but you cannot scrape a member’s personal email from the public page, because LinkedIn does not put it there. The email address sits in the Contact-info panel, which renders only for a logged-in viewer the member has chosen to show it to, in practice their connections. To a logged-out client, that panel is replaced by a sign-in wall.

I measured this directly. When I fetched a public profile like /in/williamhgates with a Chrome User-Agent in July 2026, LinkedIn returned HTTP 200 with the person’s real name in the page title and a sign-in prompt where the contact details should be. With no User-Agent at all, the same request returned HTTP 999, LinkedIn’s denial code, and no page. Either way, there was no email field to parse.

So the public page splits cleanly into what you can read and what stays walled:

The takeaway reframes the whole task. The real question is not “how do I read the email off the page” but “how do I turn the public profile into a verified work email.” That resolve-and-verify step is exactly what every LinkedIn email finder runs under the hood, which the next section breaks down.

How do LinkedIn email finders actually get the address?

LinkedIn email finders get the address by enrichment, not by reading it off LinkedIn. They take the name and company from the public profile, derive the company’s email domain, apply the common corporate address pattern, and verify the result before returning it. The address comes from that pipeline, not from a hidden field on the profile.

The domain-and-pattern step is deterministic. Most companies use one of a handful of formats: first.last@company.com, firstlast@company.com, flast@company.com, or first@company.com. Once you know the person’s name and the employer’s mail domain, you can list every candidate in a line of code, which is why the finders converge on the same guesses.

Verification is the step that separates a useful list from a liability. Finding a candidate address tells you nothing about whether mail to it delivers. Mailchimp’s email benchmarks flag a bounce rate above 2% as a deliverability problem that damages your sender reputation, and an unverified scrape of guessed addresses blows past that fast. The finders that verify before they hand back a contact keep bounces low, and the ones that return raw guesses do not.

One practical split is worth noting before you write any code. Most consumer email finders are Chrome extensions that enrich profiles you open one at a time, which means a logged-in LinkedIn session and the account risk that comes with automating it. The do-it-yourself and API routes below avoid that logged-in exposure, starting with the Python build.

How do you scrape emails from LinkedIn with Python?

You scrape emails from LinkedIn with Python in four steps: pull the public profile record, read the name and company, generate candidate work emails from the company domain, then verify each candidate before you keep it. The first thing to internalize is that the naive fetch returns no email, so you never build on it directly.

import requests

ua = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36"
r = requests.get("https://www.linkedin.com/in/williamhgates", headers={"User-Agent": ua}, timeout=20)

print(r.status_code)                    # -> 200
print("sign in" in r.text.lower())      # -> True   (authwall, not the profile)
print("@" in r.text and "mailto" in r.text.lower())  # -> False  (no contact field)

With a Chrome User-Agent the status is 200 but the body is the sign-in wall, and with no User-Agent it is 999. Neither response contains the email, so Python’s job starts one step back, at the public fields you can actually get.

Step 1: Pull the public profile record

Step 1 is getting the name and current company, the two inputs the whole method depends on. The logged-out page is gated, so in practice you read those fields one of two ways: a real logged-in browser driven by Selenium and the linkedin_scraper library, which puts your own account on the line, or a scraper API that returns the fields without a login. Whichever you use, you only need two values out of it here, the person’s name and their employer.

Step 2: Generate and verify candidate emails

Step 2 turns that name and the company domain into a short list of candidate addresses, then checks them. The generation part is pure string work:

def candidate_emails(first, last, domain):
    f, l = first.lower(), last.lower()
    return [
        f"{f}.{l}@{domain}",     # jane.doe@acme.com
        f"{f}{l}@{domain}",      # janedoe@acme.com
        f"{f[0]}{l}@{domain}",   # jdoe@acme.com
        f"{f}@{domain}",         # jane@acme.com
        f"{f}.{l[0]}@{domain}",  # jane.d@acme.com
    ]

for addr in candidate_emails("Jane", "Doe", "acme.com"):
    print(addr)

Generating candidates is deterministic, but confirming which one exists is not, and that is where accuracy is won or lost. A basic MX lookup with dnspython tells you the domain accepts mail at all, which filters out dead domains before you spend a verification credit:

import dns.resolver   # pip install dnspython

def domain_accepts_mail(domain):
    try:
        return bool(dns.resolver.resolve(domain, "MX"))
    except Exception:
        return False

print(domain_accepts_mail("acme.com"))   # -> True if the domain has mail servers

The MX check only proves the domain takes mail, not that jane.doe@ is a real mailbox. For per-address confirmation you need real verification, which handles catch-all domains and greylisting, and that is what a dedicated email-verification API does. Do not send to an address that has only been guessed, because that is precisely what runs your bounce rate past the 2% line. The weak link in this whole DIY chain is Step 1, getting the name and company reliably at volume without a login or a block, which is the problem the managed route removes.

How do you scrape LinkedIn emails at scale without getting blocked?

You scrape LinkedIn emails at scale without getting blocked by sending each profile URL to a scraper API that returns the public profile record as JSON, with the proxies, the browser rendering, and the login handled server-side, then running the enrich-and-verify step on the fields it returns. This clears the two things that break a do-it-yourself job: the authwall on Step 1 and the account risk of a logged-in extension.

LinkedIn’s own robots.txt opens by stating that automated access without permission is “strictly prohibited” and disallows the profile paths, which is why an unattended DIY scraper draws the 999 quickly from a datacenter IP. A managed API absorbs that by rotating residential proxies for you, so the block problem stops being yours to babysit.

In my runs, the ChocoData LinkedIn endpoint returned the profile record, name, headline, current company, and the public company website, from a single call, with the personal email marked null where it is not public. That null is the honest result: the API reports what LinkedIn actually exposes rather than pretending to read a private field.

The request is a plain GET with the profile URL and your API key:

curl "https://chocodata.com/api/v1/linkedin/profile?url=https://www.linkedin.com/in/williamhgates&api_key=$CHOCO_API_KEY"

The same shape in Python hands you the fields that feed the candidate_emails function from the section above, so the profile pull and the email generation become one short pipeline:

import requests

resp = requests.get(
    "https://chocodata.com/api/v1/linkedin/profile",
    params={
        "url": "https://www.linkedin.com/in/williamhgates",
        "api_key": "YOUR_CHOCO_API_KEY",
    },
    timeout=30,
)
profile = resp.json()

name = profile["name"].split()
domain = "acme.com"   # derive from profile["company"] or its website field
leads = candidate_emails(name[0], name[-1], domain)
print(profile["name"], profile.get("headline"), leads)

Because the rotation and the rendering live on the server, a list of thousands of profile URLs collects concurrently without you touching a proxy or a browser, and no LinkedIn login of yours is ever attached to the job. On price, the free plan covers 1,000 requests with no card, the Pro tier works out to about $0.60 per 1,000, and you are billed only for successful calls, so blocks and retries do not land on your invoice. If you want the full DIY build first, I walk through it in how to scrape LinkedIn with Python, and I rank the managed options in the best LinkedIn scrapers guide. Running logged out on public fields keeps you in the lowest-risk position technically, but the email itself is still personal data, which is where the legal line matters.

Is it legal to scrape emails from LinkedIn?

Scraping public LinkedIn profile data is legal in a narrow US sense, but scraping emails from LinkedIn adds a second layer, because an email tied to a named person is personal data and the outreach that follows is separately regulated. The Ninth Circuit held in hiQ v. LinkedIn that collecting publicly visible data likely does not violate the Computer Fraud and Abuse Act, which protects the act of reading public pages. It does not clear the other two rules.

The first is contract. Section 8.2 of the LinkedIn User Agreement prohibits using software, bots, or crawlers to scrape the Services or copy contact data, so any logged-in tool or extension is operating against the terms and risks having its account restricted. A logged-out API sidesteps that hook because there is no account of yours agreeing to those terms while it collects.

The second is privacy law, and it is the one that bites hardest on emails. Collecting a person’s work email is processing personal data, so in the EU and UK the GDPR applies and you need a lawful basis, usually legitimate interest, plus a clear opt-out. Regulators enforce this specifically against LinkedIn scraping: on 5 December 2024 France’s CNIL fined the company behind the KASPR extension EUR 240,000 for collecting contact details from members who had restricted their visibility to 1st and 2nd-degree connections, which the regulator said exceeded what people could reasonably expect. The lesson is concrete: collect genuinely public fields, honor visibility settings, and do not hoard restricted data.

In the US the outreach itself is governed by the CAN-SPAM Act, enforced by the FTC, which requires every commercial email to carry an honest header, a physical mailing address, and a working unsubscribe that you actually honor. Getting the data compliant and sending it compliant are two separate duties, and the tools handle neither for you. I keep the full breakdown of the terms and the privacy rules in LinkedIn scraping and the Terms of Service. This is general information drawn from primary sources, not legal advice, so for a specific project talk to a lawyer.