A newsletter with 10,000 subscribers can sell a sponsorship for $150. The same newsletter, with the same 10,000 subscribers, can sell one for $1,000. Paved, a newsletter ad marketplace, puts a healthy newsletter at $15 to $30 per thousand readers and says an unusually valuable audience can reach $100 or more.
Both lists are the same size yet the second one sells for several times as much. Why? Because the writer can tell the sponsor who the readers are.
Knowing who reads your content is the hard part. Take a weekly newsletter about AI tools with 4,000 subscribers. The writer can open Substack's settings, create an export, and download every subscriber's email address as a CSV file. That file doesn't say who any of those people are, so when a sponsor asks who reads the newsletter, the answer is a subscriber count and an open rate.
Now suppose the writer matches each address to a LinkedIn profile and finds that several hundred subscribers are founders and product leads at software companies. The list never changes, but now the writer can say what the sponsor is actually paying for.
What a subscriber export contains
Substack delivers the export as a ZIP file with the subscriber list inside as a CSV, and each row gives you an email address and the date that person subscribed. Substack also runs a Developer API, but its terms cover public creator and publication data, such as profile URLs and total subscriber counts, and don't include subscriber email addresses. Substack's own analytics show opens, clicks, and rough location.
Job titles, employers, and seniority appear nowhere in that data. Writers who want those details usually run a reader survey, and Inbox Collective's advice on selling newsletter ads includes job title, role, and industry among the questions worth asking. A survey only describes the readers who answer it.
Most addresses on a newsletter list are personal ones. A work address like [email protected] at least carries a company domain to start from. A personal address like [email protected] carries no employer and often no recognizable name, so there's nothing in the address itself to work with.
Marketing teams have the same problem with gated content. When someone downloads an ebook or registers for a webinar, the form sends a name and an email address to the CRM. The email address is usually real, because that's where the ebook gets delivered. The name field is less reliable, since people type nicknames, initials, or a string of random letters into it. The CRM ends up holding thousands of personal addresses that nobody in sales can connect to a person.
Why sponsors ask who is reading
Newsletter sponsorships are sold either as a flat fee per placement or on a CPM (price per thousand subscribers or impressions). Paved's $15 to $30 range covers what it calls a healthy newsletter. For the $100-plus figure, its example is an audience that regularly buys luxury goods, so treat that number as the top of the market rather than a B2B benchmark.
For a list of 10,000 subscribers, a $15 to $30 CPM prices one placement at $150 to $300, and a $100 CPM prices it at $1,000. beehiiv's guide to sponsorship rates argues the same way with an 8,000-subscriber newsletter read entirely by SaaS founders, and it recommends listing readers' job titles in the media kit.
Before quoting a rate, check whether the sponsor counts CPM on subscribers or on opens, because the two produce very different numbers.
No public study measures how much LinkedIn data raises a newsletter's rate. What Paved and beehiiv both say is that sponsors pay more when they know who the readers are, and matching emails to profiles is one way to tell them.
Matching a personal email to a profile
If you build this yourself, the pipeline for personal email addresses looks roughly like this:
- Clean the username by stripping numbers and punctuation, so
j.smith.1987becomesj smith. Some pipelines also treat a trailing number like 1987 as a probable birth year. - Build several search queries from each address: the full email, the raw username, the cleaned username, and the username read as a first and last name.
- Run every query through a web or people search API and collect the profiles that come back.
- Score each candidate profile. Useful signals include whether the email address appears on the profile, whether the profile's URL resembles the username, and whether both parts of the parsed name appear in the profile's name or headline.
- Keep the top candidate if its score clears a threshold you choose, and store the score alongside it.
Each address takes several searches, so the cost adds up quickly on a list of any size. You also have to pick a cutoff score. A low cutoff lets the wrong people through, and a high one throws away real matches. There's no public, independent benchmark for how often a pipeline like this finds the right person either, so before you trust the output you need a test set of email addresses whose owners you already know.
The other option is a single API call. Enrich Layer's Reverse Email Lookup endpoint accepts a personal or work email address and returns the matching LinkedIn profile URL, plus Twitter and Facebook profile URLs when it finds them.
curl -G "https://enrichlayer.com/api/v2/profile/resolve/email" \
-H "Authorization: Bearer $ENRICHLAYER_API_KEY" \
--data-urlencode "[email protected]" \
--data-urlencode "lookup_depth=superficial" \
--data-urlencode "enrich_profile=enrich"
A trimmed response looks like this:
{
"linkedin_profile_url": "https://www.linkedin.com/in/example-reader",
"twitter_profile_url": null,
"facebook_profile_url": null,
"similarity_score": 0.91,
"profile": {
"full_name": "Jordan Example",
"occupation": "Head of Product at Example Co",
"city": "Austin",
"country": "US",
"experiences": [
{ "company": "Example Co", "title": "Head of Product" }
]
},
"last_updated": "2026-09-01T00:00:00Z"
}
The similarity_score runs from 0 to 1 and measures how closely the returned profile resembles the one being looked up, so you can set your own acceptance threshold, the same way you would in a pipeline you built.
The lookup_depth parameter controls how the lookup runs and how it's billed. With superficial, the address is compared against Enrich Layer's database, and a lookup that finds nothing costs nothing. With deep, which is the default, the lookup goes beyond the database and uses heuristics to identify the person. The documentation recommends deep lookups for work addresses, and they're charged whether or not a match comes back. A charged lookup costs 3 credits, and enrich_profile=enrich adds 1 credit to return Enrich Layer's stored profile for the match when it has one.
Spend more only on the contacts that justify it
Because a superficial lookup that misses is free, the cheapest order for a large list is to start there and pay more only where the contact is worth it:
- Run every address with
lookup_depth=superficialandenrich_profile=enrich. You pay only for matches, and a match with a stored profile comes back with a job title, employer, work history, and location. - Decide which unmatched addresses are worth a charged deep lookup. For a newsletter, that could be paid subscribers or readers who open every issue. For a CRM, it could be leads who visited the pricing page.
- For the contacts that matter most, call the Person Profile endpoint with
extra=include, which adds 1 credit and returns industry and other extra fields when the data exists.
Seniority isn't a field in the response. Work it out from the job title instead, with a mapping you keep in your own code (for example, "VP," "Head of," and "Chief" count as senior) so you can adjust it as you see real titles.
You don't have to match every subscriber to describe the list. A random sample of a few hundred addresses will estimate the job-title mix of the whole list, and you can save the full run for when you want names, such as the specific founders or buyers a sponsor would care about.
Either way, the numbers describe the subscribers who matched. Readers the lookup can't match won't appear at all, and they may be a different mix of people from the ones who do. Show the match count next to the percentages, like this: "1,900 of 4,000 subscribers matched, and 31% of those work in product roles." Then a sponsor can see what the percentages rest on.
What to do with the matched data
For a newsletter, the first use is the sponsor pitch. A media kit can show the job-title distribution, the most common employers, and where readers are based, next to the open rate. A sponsor selling developer tools can see how many readers are engineers before agreeing to a rate. The same breakdown can shape a paid tier: a writer who learns that a third of matched readers work in finance has a reason to test a finance-focused series.
For a marketing team, the lookup turns the gated-form backlog into a call list. If someone fills out your form with a Gmail address, the lookup tells you where they work. Sales can call the operations director at a logistics company first, and the student who wanted your ebook can go into a nurture sequence.
Privacy obligations when you enrich a list
Substack's Publisher Agreement makes the writer the controller of their subscriber list, and it says: "You must comply with your legal obligations as a data controller, including in your off-platform use of personal data." Matching subscribers to outside profiles is off-platform use.
Under GDPR, adding data to a subscriber's record is processing, and it needs a lawful basis. If you rely on legitimate interests, the UK ICO's guidance sets out a three-part test: you need a legitimate purpose, the processing has to be necessary for it, and the subscriber's interests must not override it.
When data comes from somewhere other than the subscriber, Article 14 generally requires telling them what categories of data you hold and where it came from. In California, the CCPA requires businesses it covers to disclose the personal information they collect, its sources, and its purpose, and to honor requests to access, delete, or opt out.
In practice, update your privacy notice to say that you add professional data to subscriber records and what kind of source it comes from, keep only the fields you'll actually use, and remove anyone who objects. This summary isn't legal advice, so check with counsel for the places your subscribers live.
Try it on your own list
The Reverse Email Lookup documentation covers every parameter and response field. To test it, pick a credit pack or plan and, once your privacy notice covers enrichment, run a handful of addresses from your own export with lookup_depth=superficial, so misses cost nothing.
