Email Scraper: What It Actually Returns, and Why the List Bounces

Last updated: 2026-08-07

An email scraper is a tool that walks through web pages and pulls out every string that looks like an email address. Point it at a website, a list of URLs, or a directory, and it hands you back a column of addresses. It is fast, it is cheap per row, and it is the single most common way people end up with a list that bounces.

The confusion that costs the most is between an email scraper and an email finder. They sound interchangeable and they solve different problems. This guide covers what each one actually returns, where a scraper pulls from, why so much of its output is unusable for outbound, and how to turn a raw scrape into a list you can send to.

What an email scraper actually does

A scraper reads the visible and the underlying source of a page and matches anything with the shape of an address. It does not know who the person is, whether the mailbox is still open, or whether the address belongs to a human at all. It knows the pattern.

That matters because most addresses published on the open web are deliberately generic. Contact pages carry contact@, info@, hello@, sales@, support@. Legal pages carry privacy@ and dpo@. Those are real, they receive mail, and they are routed to a shared inbox that a decision maker does not read. A scrape of a thousand company websites will return a large pile of addresses and a small number of people.

So the honest description is: an email scraper answers which addresses are published on this page. It does not answer how do I reach the head of sales at this company. Those are different questions and they need different tools.

Email scraper versus email finder

An email finder starts from a person. You give it a name and a company or domain, and it returns the professional address for that individual. It is the right tool when you already know who you want to talk to.

A scraper starts from a page. You give it a URL and it returns whatever is published there. It is the right tool when you want everything a site exposes, including phone numbers and social profiles, and you do not have named targets yet.

In practice a serious list uses both, in sequence: scrape to map the companies, then find named contacts inside the ones that qualify. Using only the first half is what produces a list of role inboxes and a reply rate that never moves. If you want the finder half in detail, the lead email lookup guide covers it.

The four sources it pulls from

Not all scraped addresses are worth the same. Sorting the output by where it came from is the fastest quality gain available.

Company websites. Contact, about, team and legal pages. Reliable in the sense that the domain is right, weak in the sense that the addresses are usually generic. This is the highest volume source and the lowest share of named people.

Directories and marketplaces. Local listings, association registers, review sites. The address is often a shared business inbox, and it can be years old because nobody maintains a listing they created once.

Documents. Slide decks, price lists and PDFs indexed on a site. These frequently contain named addresses, and they are frequently obsolete because a PDF from three years ago still sits at the same URL.

Aggregated dumps. Bulk files of addresses collected elsewhere and resold. Cheapest per row and the worst on every quality axis. If you are considering one, the honest arithmetic is in how to buy an email list and what it really costs.

A practical rule: keep the first three, tag them by source, and measure bounce per source after the first send. The differences are usually large enough to change how you spend the next month.

Why scraped emails bounce

Four things go wrong, and they compound.

The page is old. A team page that has not been touched in two years still returns addresses. The people left. Nothing on the page tells you that.

The address is a trap or a decoy. Some sites publish addresses specifically to catch automated collection. Sending to one is a fast way to damage a sending domain.

The mailbox is a role, not a person. Role addresses often survive verification, so they do not show up as bounces at all. They show up as silence, which is worse, because you keep sending.

The domain accepts everything. A catch-all domain returns a positive signal for any address you test, valid or not. That is why a scrape can verify at a flattering rate and still bounce hard in production. The mechanics are in the catch-all guide, and the practical handling in the bounce checker guide.

None of these are arguments against scraping. They are arguments against sending straight from a scrape.

Running an email scraper from a spreadsheet

The version of this that survives contact with a real list keeps every step in one place, so you can see the drop at each stage rather than discovering it in your campaign stats.

Put your domains in a column. Email & Social Extractor from Website pulls the published addresses and social profiles for each row at 2 credits per line, straight into the sheet. You now have raw output with the source attached.

Next, separate role inboxes from named addresses. Anything before the @ that reads contact, info, hello, sales, support, admin, or a department name goes in a different bucket. Do not delete it, because a role inbox is sometimes the only route into a very small company, but do not count it as a contact either.

Then verify what is left. Email Verification runs at 1 credit per email and marks the catch-all domains separately, which is the flag that matters most here. It is worth deciding early whether you verify at import or at send, because the two produce different waste.

Finally, fill the gaps. For the companies that qualified but exposed nothing useful, switch tools: identify the person you want and use Email Finder at 5 credits per email, billed per result found. That last step is what turns a market map into a target list.

Run the scrape, the verification and the finder in one sheet with Derrick. The free plan includes 100 credits per month, so you can test the whole sequence on a small batch before committing a budget. Derrick also runs through an MCP server for AI clients and through a REST API, so the same steps fit into an automated workflow at any volume.

The cleanup pass that makes a scrape sendable

Six checks, in this order. Each one removes a different failure, and doing them out of order wastes credits.

1. Deduplicate on the address, not the row. The same address appears on several pages of the same site.
2. Drop obvious non-humans. noreply, no-reply, mailer-daemon, postmaster, webmaster.
3. Split role inboxes into their own bucket. Keep them, count them separately, never mix them into your reply rate.
4. Check the domain matches the company. Scrapes pick up addresses from embedded partners, agencies and widgets. An address on the page is not automatically an address at the company.
5. Verify, and read the catch-all flag. Treat catch-all domains as unconfirmed rather than valid.
6. Sample twenty rows by hand. Open the profile, confirm the person is still there. Twenty rows is enough to tell a fresh list from a stale one.

What survives all six is a smaller number than the scrape suggested, and it is the only number worth planning a campaign around. If you want the reference points for what happens after the send, measure reply and bounce per source over the first two sends.

When an email scraper is the wrong tool

Three situations where scraping will cost you more than it returns.

You already know the accounts. If you have a list of two hundred target companies and named roles, a scraper adds noise. Go straight to a finder against named people.

Your buyer is senior. Executives are almost never the published address on a contact page. Scraping an enterprise site returns the press inbox and the careers inbox. The executive email guide covers what does work.

The segment is dense and local. For local businesses the useful record is often the phone number and the opening hours, not an address that goes to a shared mailbox. Scraping the site is the wrong first move when a business listing already holds better structured data.

A worked example: one hundred domains, end to end

The abstract version of this is easy to nod at and hard to act on. Here is the shape of the funnel, written as a worksheet you fill with your own measurements rather than a benchmark to copy.

Start with one hundred company domains that already match your segment. Run the extraction and record the raw count of addresses returned. That first number is always the flattering one, and it is the one vendors quote.

Now subtract, in this order, and write down what each step removes:

• Duplicates. The same address published on the contact page, the footer and a PDF counts once.
• Non-humans. noreply, postmaster, webmaster, automated ticket addresses.
• Foreign domains. Addresses that came from an embedded partner, an agency credit or a widget, and do not belong to the company you were scraping.
• Role inboxes. Kept, but moved to a second list with its own expectations. A role inbox at a five person company is a real route in. The same address at a five hundred person company is a ticketing queue.
• Failed verification. Hard invalid, dead domain, syntax broken.
• Catch-all flags. Not removed, but marked unconfirmed, because the positive signal means nothing on those domains.

What remains is your named, confirmed contacts from one hundred domains. Divide the credits you spent by that count and you have a real cost per usable contact, on your segment, not on a generic case study.

Then run the second half. For the companies that qualified but yielded nothing named, identify the role you want and search for that person directly. Record the same two numbers: contacts obtained and credits spent. You now have the only comparison that matters, measured on your own market, and it will tell you whether your next thousand rows should start from pages or from people.

Keep the worksheet. Re-run it once a quarter on a fresh sample. The ratios move as the segment moves, and a number that was true in January is a guess by June.

Cost per usable contact

Per row, a scrape is the cheapest way to get an address. Per usable contact it is frequently not, because the denominator collapses during cleanup.

Work it out on your own numbers rather than on a vendor's. Take a hundred domains. Note how many rows the scrape returned, how many survived the role split, how many verified without a catch-all flag, and how many matched your ideal customer profile. Divide the total credits spent by that final count. Then do the same for a finder run against named people at the same hundred companies.

The answer is not always the same, which is the point. Scraping wins on breadth when you do not yet know the market. Finding wins on depth when you do. Running both in the same sheet, with the cost visible at each step, is how you stop guessing which one you are actually paying for.

If you want this as a repeatable job rather than a manual one, the same sequence runs from your own stack through the REST API.