How to Verify Scraped Emails Before Sending: Clean, Then Check

You can verify scraped emails, but clean them first: scraped lists are full of parsing artefacts that are not addresses at all, and verifying those wastes time and skews your results. Normalise and dedupe, remove placeholders and image filenames, run syntax and domain checks, then SMTP-verify what is left and split out catch-all and role addresses. Verification tells you an address can receive mail. It does not tell you it is safe or lawful to send to.

That last point is the one people skip. Scraped lists carry two risks a verifier cannot remove: spam traps planted on web pages precisely to catch scrapers, and legal rules that treat harvesting itself as a problem. This post covers both, after the practical cleaning steps.

Why scraped lists need cleaning before verification

A scraper extracts anything that looks like something@something.something, and a lot of what matches is not an email address. Common artefacts in raw scraped output:

Artefact	Example	Why it appears
Image filenames	logo@2x.png, hero@3x.jpg	High-resolution image naming uses @2x
Trailing punctuation	jane@acme.com., jane@acme.com)	Address at the end of a sentence or in brackets
mailto: and query strings	mailto:jane@acme.com?subject=Hi	Extracted from link targets
Encoded characters	%20jane@acme.com	URL-encoded spaces in link targets
Obfuscated forms	jane [at] acme [dot] com	Site owners hiding addresses from scrapers
Template placeholders	you@example.com, name@domain.com	Unedited contact forms and themes
Wrong owner	support@wix.com, agency addresses	Footer credits, embedded widgets
Mixed case and spaces	Jane@ACME.com	Inconsistent page markup

The image filename row matters more than it looks: logo@2x.png passes a loose syntax check, and a few thousand of them inflate the row count you think you have. Remove anything ending in an image or file extension before going further.

Obfuscated addresses are a signal in themselves: the site owner did not want them collected automatically. If you are emailing Canadian or Australian recipients and relying on a published address as consent, an address hidden this way is a weak foundation.

Step 1: normalise

Turn every candidate into a single, comparable form before deduping.

1. Trim whitespace and strip leading mailto:.
2. Cut everything from ? onward.
3. URL-decode, then remove leading and trailing punctuation.
4. Lower-case the domain part. Lower-casing the local part is safe in practice for the large providers, though the standard allows case-sensitive local parts; deduping on a lower-cased copy and keeping the original is the cautious route.
5. Drop strings ending in file extensions such as .png, .jpg, .svg, .webp, .gif, .pdf.

Step 2: dedupe and remove non-prospects

Dedupe on the normalised address, then remove addresses that do not belong to the business you scraped. Scrapes of a site often return the web agency's address, the hosting platform's support address, or a widget provider's. If the domain of the address does not match the company domain in the row, either it is a different organisation or the person uses a personal address; check before keeping it.

Remove placeholders on reserved domains. example.com, example.org and example.net are reserved for documentation by RFC 2606 and never belong to a real recipient.

The free email list health check catches duplicates, bad syntax, typo domains, disposable domains, role addresses and dead domains in the browser, which covers most of this step for a CSV.

Step 3: domain and mail server checks

Every remaining domain needs a working MX record before any mailbox check makes sense. Scraped lists often include sites that were live when the page was cached but whose domain has since lapsed, or domains that publish no mail server at all. A bulk verifier checks this for every row.

Group by domain at this stage. A scrape of one large site can return dozens of addresses on one domain, and if that domain is a catch-all, all of them will come back "unknown" or "accept-all" together.

Step 4: SMTP verification and splitting the results

SMTP verification asks the mail server whether it will accept the address, without sending a message. Expect the results to split into four groups, and handle each differently:

Result	What it means for a scraped list	Action
Valid	Server accepts this mailbox and rejects fake ones	Candidate for sending, subject to the checks below
Invalid	Server rejects the mailbox	Remove permanently
Catch-all / accept-all	Server accepts everything; cannot confirm	Separate small batch, or skip
Role	info@, office@, sales@	Keep only if you mean to reach that function

Role addresses are common in scraped data, because they are what businesses publish on contact pages. That is not automatically bad, but they are often shared inboxes read by several people. Our post on role-based addresses covers when to keep them.

SimpleVerifier runs these checks on a CSV of up to 100,000 rows and exports valid, risky and invalid rows separately. Whichever verifier you use, keep the result and the date in the file.

What verification cannot tell you

A "valid" result on a scraped address says nothing about traps or permission. Two gaps remain.

Spam traps

Pristine and seeded traps are working mailboxes. Spamhaus describes seeded traps as placed "in webpage source code, for example", so that the only way anyone obtains them is automated collection. A verifier querying that mailbox gets the same acceptance a real person's mailbox would give. Our post on how spam traps get on your list explains the types; the practical point is that scraped lists are the main route for exactly the traps verification cannot detect.

What reduces the risk is narrowing what you scrape: specific team or contact pages of companies you have chosen, rather than crawling whole sites or directories for anything with an @.

The law

Several laws treat harvesting itself, not just the email, as the problem.

• United States. CAN-SPAM makes sending to addresses harvested by automated means from sites that say they will not share them an aggravated violation. See CAN-SPAM and cold email.
• Australia. The Spam Act bans using address-harvesting software or a harvested-address list in connection with unsolicited commercial messages, and separately bans sending to non-existent addresses without reason to believe they exist. See the Spam Act and cold email.
• UK and EU. A named work address is personal data, so scraping it needs a lawful basis and a transparency notice; sole traders in the UK need consent under PECR.

None of these is changed by verification. A verified harvested list is still a harvested list.

A sending decision for scraped data

After cleaning and verification, decide per segment rather than for the whole file:

1. Send to valid, non-role addresses from targeted pages, where you have a lawful basis for the recipient's country and the message fits their role.
2. Hold catch-all addresses for a small, slow batch with bounces watched, or skip them.
3. Remove invalid addresses, placeholders, wrong-owner addresses and anything from a broad crawl you cannot tie to a specific page.

If that leaves a much smaller list, that is the honest size of what you scraped.