Forem: Erik Strömberg

There's no clean way to verify an email address. Here's what works anyway.

Erik Strömberg — Sat, 09 May 2026 01:49:53 +0000

You have a list of addresses. Maybe they came from a signup form, a partner CRM, an enrichment run, or last quarter's webinar. You want to know which ones are real before you put them on a campaign and torch your sender reputation.

You search "email verification" and find a hundred services with landing pages claiming 99% accuracy. You install the obvious package, run it on your list, and 95% come back "valid." You send. A quarter of them bounce, and the major inbox providers start flagging your domain.

What happened? Some combination of: syntax-valid addresses that don't exist, mail servers that lie, catch-all domains, greylisting, and anti-probe behavior. "This is a real mailbox" is much harder to prove than it looks. Here's how the protocol actually works, where it breaks, and what a serious verifier has to do about it.

Syntax checks filter the obvious garbage and nothing else

Run a regex against [email protected] and you'll catch the obvious malformed strings. Use a real RFC 5322 parser and you'll catch a few more (john..doe@example.com, leading whitespace, addresses with control characters).

import re
EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$")
EMAIL_RE.match("definitelynotreal@gmail.com")  # matches

definitelynotreal@gmail.com passes every syntax check ever written. It does not exist. Syntax validation tells you whether a string could be an address; it tells you nothing about whether it is one.

You still want this as a first pass — there's no point burning network calls on not an email. But anyone who ships a regex as their email verifier is solving a different problem than they think they are.

DNS proves the domain accepts mail (and nothing else)

dig +short MX example.com
# 0 mail.example.com.

If a domain has no MX record (and no fallback A record per RFC 5321), it doesn't accept mail at all. Marking the address invalid is correct. This catches typo-domains, expired domains, and domains that were never set up for email.

But gmail.com has MX records. So does every Fortune 500. So does every catch-all spam trap. MX-exists tells you the domain is in the mail business, not that the address you care about exists on it.

Talking SMTP to the server

This is where every "real" verifier lives. You connect to the destination MX server, walk through the SMTP handshake, and stop one step short of actually sending the email:

$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf
220 mx.google.com ESMTP ready
EHLO verifier.example.com
250-mx.google.com at your service
...
MAIL FROM:<probe@verifier.example.com>
250 2.1.0 OK
RCPT TO:<linus@gmail.com>
550 5.1.1 The email account that you tried to reach does not exist
QUIT

The signal is in the RCPT TO response:

250 → server says it would accept mail for this address
550 / 551 → mailbox doesn't exist
4xx → temporary failure, try again later
nothing, eventually a timeout → ¯\_(ツ)_/¯

A naive verifier writes this loop in twenty lines and ships. It is wrong roughly as often as it is right, for reasons that have nothing to do with the code.

Why the SMTP handshake lies

Modern mail servers know that automated probers exist, and they don't make life easy for them.

Catch-all domains. Many companies configure their inbound to accept any address at their domain and route unmatched ones to a default mailbox or a black hole. Probe xq8z29zz@somecompany.com and you get 250 OK. Probe ceo@somecompany.com and you get 250 OK. They both look identical from the outside; one of them is the CEO and the other is gibberish. If the domain is catch-all, RCPT TO is meaningless.

You detect this by sending a deliberate-fake probe first and inferring catch-all from a positive response — something like definitely-does-not-exist-12345@domain.com. Any verifier that doesn't do this catch-all check is silently classifying random nonsense as valid mail on every catch-all domain it sees.

Greylisting. A receiver returns 451 try again later on first contact from an unknown sender. Legit MTAs queue and retry minutes or hours later. Probers usually don't. Naive verifiers mark these as failed; the addresses are fine.

Anti-probe behavior on the big providers. Gmail, Outlook, Office 365, Proofpoint, Mimecast, and several other large inbound systems either always return 250 regardless of the mailbox, or always return 4xx to anything that smells like a verifier. A handshake against gmail.com does not tell you whether the address exists on Gmail; it tells you that Gmail received a connection. Any verifier that reports a clean "valid" on a Gmail address from a single RCPT TO probe is making it up. Serious tools maintain a list of these providers and fall back to other signals when they hit one.

Outbound IP reputation. Even when the receiver is willing to give you a real answer, it'll only do it if your sending IP doesn't look hostile. If you've been hammering a domain — or, more likely, if the IP block you happen to be on has been hammering it — you'll be tarpitted, throttled, or refused at HELO. Running verification from a residential IP, an EC2 box without rDNS, or a VPN basically doesn't work.

Tarpitting. Some servers respond to RCPT TO slowly on purpose — 30 seconds per probe, deliberately — to make automated verification economically unviable. Your verifier needs to handle long timeouts on some domains without falling over on the rest.

Some servers only check on DATA. They accept any RCPT TO and only bounce after you've sent the body. Verification-without-sending is impossible against those servers; the most you can do is flag them.

Port 25 is often blocked outbound. Most cloud providers and residential ISPs block outbound 25 to limit spam. A naive verifier from your laptop or your default EC2 instance will silently fail the SMTP step on every domain. Real verifiers connect from infrastructure with port 25 open, and fall back to 587/465 with STARTTLS when needed.

What "good" verification looks like

A serious verifier does, roughly:

Syntax-check the address.
Suggest typo corrections for common domains (gmial.com → gmail.com).
Look up MX (and A as fallback).
Check disposable-domain lists (Mailinator, 10MinuteMail, Guerrilla Mail, and a few hundred others).
Identify the receiver: Gmail, Outlook/Office 365, Yahoo, ProtonMail, Proofpoint, Mimecast, an in-house Postfix, etc. The provider determines which signals are trustworthy.
For receivers known to give honest RCPT TO responses, probe — from a warmed-up IP with valid rDNS, sensible HELO, and conservative pacing per destination domain.
Detect catch-all by probing a fake address first.
Honor 4xx by retrying with backoff over hours, not seconds.
For receivers known to lie, fall back to historical signals: has this address shown up in our previous deliveries? Has it bounced before?
Classify each result honestly. "Valid / invalid" is the wrong vocabulary; you need at least three buckets — deliverable, undeliverable, and risky (catch-all, greylisting timeout, large-provider unknown). Sending into the risky bucket is a business decision, not a technical one.

The infrastructure question is harder than the protocol question. You need a pool of warmed sending IPs, a monitoring system for IPs starting to bounce, per-receiver rate limiters, a queue that respects greylist retry intervals, and a database of which providers behave how. Get any of that wrong and the answers you get are noise.

Things people get burned by

Treating "catch-all" as "valid." Catch-all means I don't know whether this mailbox exists, not yes, it does. Sending into a catch-all domain blindly is one of the cleanest ways to end up flagged for spam, because spam traps love catch-alls.
Trusting role-based addresses. info@, support@, sales@, noreply@ are almost always deliverable. They're almost never the right address for cold outreach, and many ESPs treat marketing mail to role addresses as a strong spam signal.
Running checks at send time. Don't verify in your signup form's request handler. The verification call can take seconds, sometimes tens of seconds. Verify async, or against a cached lookup, never inline.
Bulk-probing without pacing. A loop that fires 1,000 RCPT TO calls at the same Google Workspace tenant gets that tenant's whole verification surface to lock you out for the rest of the day. Per-domain pacing is mandatory.
Ignoring the score. A binary "valid: true" hides a lot. An address that passes syntax + MX + disposable but where the SMTP step had to be assumed (problematic provider, timeout, IP-blocked) is a different animal from one that got a clean 250 from a non-catch-all server. Anything that doesn't expose its confidence is hiding bad news.

The shortcut

This is what /api/v1/email_verifications does at PeopleDB. The protocol piece, the receiver classification, the catch-all detection, the IP reputation, the disposable-domain list, and the typo suggestions all run on the server side; you get one HTTP call:

curl "https://peopledb.co/api/v1/email_verifications?email_address=somebody@example.com" \
  -H "Authorization: Bearer $PEOPLEDB_TOKEN"

{
  "email": "somebody@example.com",
  "valid": true,
  "classification": "valid",
  "score": 95,
  "checks": {
    "syntax": true,
    "mx_record": true,
    "smtp_deliverable": true,
    "disposable": false,
    "typo_suggestion": null,
    "accepts_any_email": false
  },
  "warnings": [],
  "errors": []
}

The classification has three states: valid, risky, invalid. Risky is the honest one — catch-all domains, large providers that won't tell you the truth over SMTP, and disposable addresses all surface there. The score is 0–100 so you can pick your own threshold per use case (a stricter cutoff for cold outreach than for password reset).

If you've got a list, run it through this before you put it on a sender. SMTP is a thirty-year-old protocol layered with anti-abuse, and the difference between a verifier that knows that and one that doesn't is the difference between a clean send and a deliverability incident.

There is no LinkedIn email API. Here's what to use instead.

Erik Strömberg — Sun, 03 May 2026 14:11:28 +0000

You have a LinkedIn URL. You want the person's email. You search "linkedin email api" and find a maze of marketing pages and Stack Overflow threads from 2018 that all say roughly the same thing: there isn't one.

That's true. There is no first-party LinkedIn API that takes a profile URL and returns an email address. There never has been, and there isn't going to be. But there is a perfectly normal way to do this, and it's been quietly running under the hood of every CRM, sales tool, and recruiting platform for a decade. Here's what's actually going on.

What LinkedIn's APIs actually return

LinkedIn does have APIs. They are aggressively gated and aggressively scoped:

Marketing Developer Platform — ad campaign management, ad analytics, posting on behalf of pages. No contact data.
Talent Solutions API — for ATS integrations. Returns candidates who applied to your job, not arbitrary lookups.
Sales Navigator API — internal use by Sales Nav itself, not really a public developer surface.
Sign In With LinkedIn (OIDC) — returns the email of the signed-in user, with their consent, scoped to that session. You cannot use this to look up anyone else.
Profile API — restricted to LinkedIn-approved partners with formal agreements; even then, contact info isn't part of the schema for anyone other than the authenticated user.

Every LinkedIn API exposes data about the authenticated user (consent-driven) or paid customer activity within your own account. None of them lets you say "give me the email for linkedin.com/in/somebody."

Why? Because that's not what LinkedIn sells. LinkedIn's product is the platform — the network effect, InMail, recruiter seats. Letting third parties bypass that with a GET would directly compete with their own monetization.

What "LinkedIn email API" actually means

When developers search for it, they almost always mean this:

GET /lookup?linkedin_url=https://linkedin.com/in/somebody
→ { "email": "somebody@example.com", ... }

That's not a LinkedIn endpoint. It's an enrichment endpoint, served by a third-party service that maintains its own contact database and uses the LinkedIn URL as a join key.

Aggregators have been building these databases for over a decade by combining:

Public-web signals — corporate websites, conference speaker bios, GitHub commits, press releases, paper authorships, podcast guest pages.
Contributed data — address books voluntarily uploaded by users of various email and CRM tools, contact graphs from sales acceleration platforms, opt-in business directories.
B2B partnerships — companies that have shared customer lists in business-data co-ops in exchange for access to the pooled data.
Verification feedback — every time a user marks an email as bounced or correct, the database learns.

None of this requires LinkedIn's permission, because none of it comes from LinkedIn. The LinkedIn URL is the lookup key, not the source.

The two LinkedIn identifiers worth knowing

Before you can hit any of these APIs, you need to extract a stable identifier from the LinkedIn URL the user gave you. There are two:

1. The public identifier (slug):

https://linkedin.com/in/williamhgates
                       ^^^^^^^^^^^^^^^
                       public_identifier

Stable until the user customizes it. Most enrichment APIs accept this as the input.

2. The numeric LinkedIn ID:

Sometimes you'll see URLs like:

https://linkedin.com/in/ACoAAA-3B7U-_b0123abc/

That long string is an opaque, account-scoped encoding of the user's internal numeric ID. It looks intimidating, but for lookup purposes it functions as just another stable identifier — useful when the slug isn't available (e.g. some recruiter or Sales Navigator URLs).

When parsing user-supplied LinkedIn URLs, handle both:

from urllib.parse import urlparse

def parse_linkedin_url(url):
    path = urlparse(url).path.strip("/")
    if not path.startswith("in/"):
        return None
    slug = path.split("/")[1]
    # ACoAA... = numeric URN, anything else = public identifier
    if slug.startswith("ACoAA"):
        return ("linkedin_id", slug)
    return ("linkedin_public_identifier", slug)

parse_linkedin_url("https://linkedin.com/in/williamhgates")
# → ("linkedin_public_identifier", "williamhgates")

What the lookup actually does

Pseudocode for what a serious enrichment API runs when you hit it:

def lookup(identifier):
    # 1. Find every record across every source that matches this identifier
    matches = profiles.where(linkedin_public_identifier=identifier)
    if not matches:
        return None

    # 2. Expand: pull in any other records that share an email or
    #    secondary identifier with the initial matches.
    #    A person often has separate records from separate sources;
    #    this is how you merge them.
    matches = expand_by_shared_attributes(matches)

    # 3. Collect emails, phones, social handles
    emails = dedupe([e for m in matches for e in m.emails])
    return {
        "linkedin_public_identifier": identifier,
        "email_addresses": emails,
        "phone_numbers": [...],
        "github_login": ...,
        "twitter_username": ...,
    }

Two non-obvious things going on here:

Identity resolution is the hard part. There's no canonical "person ID" across sources. You have to chain matches: this LinkedIn record shares an email with a CRM record, which shares a phone with a conference-speaker entry, etc. Done well, you end up with a merged view. Done badly, you accidentally fuse two different people who happen to share a generic info@ inbox.
Email classification matters more than people think. Anyone serious will separate personal addresses (@gmail.com, @protonmail.com) from work addresses. Outreach into a personal inbox has very different deliverability and acceptable-use implications than reaching someone at their employer.

A practical example

Here's enriching a CSV of LinkedIn URLs into emails, end to end:

import csv
import requests
from urllib.parse import urlparse

API = "https://peopledb.co/api/v1/people"
TOKEN = "YOUR_TOKEN"

def parse(url):
    path = urlparse(url).path.strip("/")
    if not path.startswith("in/"):
        return None
    slug = path.split("/")[1]
    return ("linkedin_id", slug) if slug.startswith("ACoAA") else ("linkedin_public_identifier", slug)

def lookup(url):
    parsed = parse(url)
    if not parsed:
        return None
    param, value = parsed
    r = requests.get(
        API,
        params={param: value},
        headers={"Authorization": f"Bearer {TOKEN}"},
    )
    return r.json() if r.ok else None

with open("input.csv") as f, open("output.csv", "w", newline="") as out:
    reader = csv.DictReader(f)
    writer = csv.DictWriter(out, fieldnames=["linkedin_url", "name", "work_email", "personal_email"])
    writer.writeheader()
    for row in reader:
        result = lookup(row["linkedin_url"]) or {}
        writer.writerow({
            "linkedin_url": row["linkedin_url"],
            "name": row.get("name", ""),
            "work_email":     (result.get("work_email_addresses") or [""])[0],
            "personal_email": (result.get("personal_email_addresses") or [""])[0],
        })

That's the whole pipeline: parse, look up, write. The interesting work happens server-side; the client is twenty lines.

Things to keep in mind

A few things worth being honest about:

Coverage is not 100%. Aggregator APIs hit on a meaningful fraction of profiles — but never all of them. Plan for misses, not just hits.
Data ages. People change jobs, drop addresses, move to new domains. Anything you enrich today should be re-validated before you use it months later.
Verify before sending. A correctly-resolved email that bounces is still a bounce. SMTP-level validation (or a verification endpoint, if your provider has one) before bulk outreach is table stakes.
Compliance is on you. If you're enriching contacts at scale and reaching out from the EU or UK, GDPR's legitimate-interest tests apply. CCPA in California, CASL in Canada, similar regimes elsewhere. The API gives you data; what you do with it is your problem.
Don't scrape LinkedIn directly. Aside from the ToS issues, you'll be fighting CAPTCHAs and IP bans within minutes. The whole point of an enrichment API is that someone else has already absorbed that operational cost — across many sources, not just LinkedIn.

The shortcut

This is what PeopleDB does. The endpoint accepts either identifier:

# By public identifier (the slug)
curl "https://peopledb.co/api/v1/people?linkedin_public_identifier=williamhgates" \
  -H "Authorization: Bearer $PEOPLEDB_TOKEN"

# By numeric ID
curl "https://peopledb.co/api/v1/people?linkedin_id=ACoAAA-3B7U-_b0123abc" \
  -H "Authorization: Bearer $PEOPLEDB_TOKEN"

{
  "linkedin_public_identifier": "williamhgates",
  "linkedin_id": "...",
  "github_login": null,
  "email_addresses": ["..."],
  "personal_email_addresses": ["..."],
  "work_email_addresses": ["..."],
  "phone_numbers": ["..."]
}

The same identity-resolution layer also accepts github_login and github_id, so if a person shows up under both LinkedIn and GitHub in the index, you get the union — useful when you've got a contributor's GitHub handle but want to reach them at their work address.

There is no first-party LinkedIn email API. There probably never will be. What there is, is a category of enrichment APIs that have been quietly solving this for years. That's the trade.

Why finding a GitHub user's email is harder than you'd think

Erik Strömberg — Sun, 03 May 2026 01:21:36 +0000

You've found a contributor whose work you depend on. The maintainer of a package you use, a developer who fixed something for you upstream, the author of a CVE you need to coordinate with. You have their GitHub username. You'd like their email.

You'd think this would be a GET away. It isn't. Here's why — and what it actually takes to find one.

The GitHub API doesn't have it

GET /users/:login returns an email field. For the vast majority of users, that field is null.

GitHub flipped private-by-default years ago. When you sign up today, your commit email is set to <id>+<login>@users.noreply.github.com and the public profile email field is empty. Older accounts that opted in still expose addresses, but they're a minority — and the people you actually want to reach (active maintainers, security-conscious developers) are exactly the ones who turned this off.

So that's out.

The commits don't have it either (mostly)

The next obvious move: look at the user's commits. Every commit has an author email in its metadata. Pick a public repo, fetch the commit, get the email.

curl https://api.github.com/repos/torvalds/linux/commits | jq '.[0].commit.author.email'
# "torvalds@linux-foundation.org"

That works for Linus. It does not work for most people. Run this against any reasonably modern repo and you'll see a lot of:

"49699333+dependabot[bot]@users.noreply.github.com"
"12345678+somecontributor@users.noreply.github.com"

GitHub rewrites commit emails to the noreply form whenever the author has the "Keep my email addresses private" setting on, which is the default. The <id>+<login> part is the user's GitHub ID and login — useful if all you wanted was to identify them, but you already had their login. You wanted to email them.

The events archive: harder, but real data

There's another source that dev tooling people sometimes forget about: the public events stream. GitHub publishes a firehose of public events (pushes, opens, comments, releases) and GH Archive has been recording it hourly since 2011 — terabytes of newline-delimited JSON, gzipped, freely downloadable.

Each PushEvent carries the underlying commit metadata, including author name and email. In principle, if a developer ever pushed a commit before they turned on private email — or if they push from a CI pipeline that uses a real address — that email is in the archive.

The job that processes it looks roughly like this:

gz = Zlib::GzipReader.new(StringIO.new(http.get(archive_url).body))

gz.each_line do |line|
  event = JSON.parse(line)
  next unless event["type"] == "PushEvent"

  login = event.dig("actor", "login")

  event.dig("payload", "commits").to_a.each do |commit|
    author_name  = commit.dig("author", "name")
    author_email = commit.dig("author", "email")
    # ... we have a (login, name, email) triple. Now what?
  end
end

You scan a few hours of archive and immediately find a problem. A lot of those emails look like this:

8a3f9b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80@gmail.com

Forty hex characters. That's a SHA-1 hash. The local part of the email has been one-way-hashed; only the domain is in the clear. This is a historical artifact of how the events feed has been emitted for stretches of GitHub's history — commit emails arriving with the local part obfuscated.

Great. Now you have a hash.

Reversing the hash

SHA-1 of an arbitrary string is a one-way function. SHA-1 of an email local part is not, because email local parts are not arbitrary. They're drawn from a tiny, predictable distribution: firstname, firstname.lastname, f.lastname, firstnamelastname, firstname_lastname, firstname1985, and a few hundred other patterns layered over a finite list of names.

If you precompute a table of sha1(local_part) → local_part for every plausible candidate — every name you've ever encountered, every email you've ever seen published — you can reverse most of these in O(1).

if email =~ /^([a-f0-9]{40})@(.+)$/
  hash, domain = $1, $2
  if (record = Sha1Hash.find_by(sha1_hash: hash))
    real_email = "#{record.text}@#{domain}"
  end
end

The lookup table is the asset. Building it well is most of the work. Mine is hundreds of millions of rows and grows every time the world publishes another address.

The harder problem: was that actually them?

You now have a (login, author_name, real_email) triple. The temptation is to claim the email belongs to the login. Don't.

Anyone can configure git locally. People commit with user.name set to their full legal name, their nickname, "John", "John D.", "johndoe", "John Doe via Acme Corp", "Acme CI Bot", or — frequently — someone else's name entirely, because they cloned a repo on a coworker's machine and never reconfigured. A login pushes hundreds of commits over the years; many of them carry author names that don't actually identify the person behind the login.

So you need a confidence layer. Mine is a separate pass over the same archive that builds a (login, author_name) → observation_count table:

CREATE TABLE github_login_author_name_mappings (
  login              text,
  author_name        text,
  observation_count  int,
  PRIMARY KEY (login, author_name)
);

When a hash reverses to a candidate email, I look up every author name that login has ever been observed pushing under, and ask: what fraction of this login's total commits use this author name?

total_count = all_names.sum { |_, count| count }
name_count  = all_names.find { |name, _| name == author_name }&.last || 0
percentage  = (name_count.to_f / total_count.to_f) * 100

# Need at least 10 commits for any signal at all
return false if total_count < 10

# With a long history, 50% co-occurrence is enough; with little, demand 80%
threshold = total_count > 100 ? 50.0 : 80.0
percentage >= threshold

This rejects the noise. The contributor who once pushed a commit signed "Test User" doesn't get linked to a test.user@example.com reversal. The CI bot pushing under a real engineer's login but with git config user.name "Buildkite" doesn't pollute the index. What survives is the set of (login, name) pairs that consistently co-occur — a fairly trustworthy proxy for "this is the human behind this login."

What's left

Doing this for one user, end to end:

Identify which monthly archive shards likely contain their activity.
Stream and decompress hundreds of gigabytes of JSON.
Maintain a SHA-1 lookup table of every plausible email local part you've ever seen.
Maintain a parallel (login, author_name) co-occurrence index across the entire archive.
For every reversed hash, run the confidence check.
Validate the resulting email isn't already claimed by a different GitHub login (people misconfigure git constantly).
Verify the address actually accepts mail before you rely on it.

That's a multi-day backfill the first time, hundreds of gigabytes resident, and a continuous trickle of new data forever. Perfectly reasonable to build if finding email addresses for GitHub users is your full-time job. Absurd to build if you just need to email three maintainers about a CVE.

The shortcut

This is the work PeopleDB does in the background. The pipeline above — archive ingestion, hash reversal, identity correlation, deduplication, SMTP validation — runs continuously. The answer is one HTTP call:

curl "https://peopledb.co/api/v1/people?github_login=octocat" \
  -H "Authorization: Bearer $PEOPLEDB_TOKEN"

{
  "github_login": "octocat",
  "github_id": 583231,
  "linkedin_public_identifier": "...",
  "email_addresses": ["..."],
  "personal_email_addresses": ["..."],
  "work_email_addresses": ["..."]
}

The endpoint also accepts github_id, linkedin_id, and linkedin_public_identifier — the same identity-merging logic runs across all of them, so if a person has both a GitHub and a LinkedIn record in the index, you get the union.

If you're doing security disclosure, contributor outreach, or any kind of identity resolution where you start with a username and need to actually reach the human, that's the trade: spin up the pipeline, or skip it.