Role emails vs personal: why lead lists need both split

A contact list with one column called “email” has thrown away the most important thing about each address: whether it belongs to a company or to a person. Those two need different handling legally, they perform differently when you write to them, and merging them means every rule you apply is applied to the wrong half of the list.

This page is about making the split, and about the placeholder addresses that end up in lead lists because nobody looked.

What separates them

A role address is a function: info@, sales@, support@, press@, careers@. It is published so that strangers can use it, it usually reaches a shared inbox, and it survives staff turnover. Contacting it is contacting the company.

A personal address identifies a human being: jane.smith@, dbowman@, sara@. Under GDPR it is personal data even though it sits on a public page and even though it is a work address. The company published it; the person did not necessarily choose to be in your database.

The distinction is not about which is more valuable. It is that they are governed differently, and a merged column removes your ability to act on that.

How to tell them apart from a domain alone

Three signals, in order of reliability:

Is it on the company’s own domain? An address on the company’s domain — or a subdomain, treating www. as the same host — plausibly belongs to that company. One on a different domain belongs to somebody else: the agency that built the site, the PR firm, an embedded widget’s vendor. Keep those, label them as off-domain, and never merge them into the company’s contacts.

Is the local part a function or a name? sales is a function. jane.smith is a person. Most of the volume falls cleanly on one side, and a maintained list of function words handles it. This is where the judgement sits, and where it is worth being explicit that the judgement can be wrong.

Is it a send-only address? noreply@, donotreply@, mailer-daemon@ are outbound-only and are never a contact route. They appear in scraped lists constantly because they appear in page source constantly.

Attach a confidence level rather than pretending to certainty. An on-domain role address is close to certain. An on-domain personal address is probable but unresolvable from the domain alone — [email protected] at a four-person firm is as likely to be the general inbox as to be Sam. An off-domain find of any kind is low confidence about this company by definition.

Do not discard the compliance addresses

A detail worth stating because it is easy to get backwards: privacy@, legal@, dpo@, compliance@, security@ are role addresses, not personal ones. They are as public and as company-owned as info@.

This matters because a filter built around sales vocabulary — info, sales, support, contact — treats them as unrecognised and, if the default is to exclude personal addresses, silently drops them. Those are exactly the addresses a GDPR enquiry, a security disclosure or a legal notice needs to reach. A list built for outbound will not notice; a list built for compliance work is useless without them.

Think of the function vocabulary as covering every department, not only the ones that buy from you.

The placeholder problem

Real companies publish fake email addresses on their own websites, and it is far more common than it sounds. Marketing pages get built from templates, documentation examples get copied into copy, and the sample addresses are not always removed before publication.

Two verifiable examples: stripe.com publishes [email protected] and [email protected]. mollie.com publishes [email protected] and [email protected]. Both are large, careful companies. An extractor that accepts every string matching an email pattern hands you those as contacts.

The classes worth filtering are documentation domains (example.com and relatives), template placeholder domains, template local parts (youremail@, john.doe@), asset filenames that happen to parse as addresses, and tracking or vendor domains embedded by scripts.

The filter has to match whole domains. acme.com is a placeholder; acmetrading.nl and example-catering.nl are real companies with real addresses, and a substring match deletes them without telling you.

What a usable row looks like

One row per domain, with the sets kept apart:

That shape lets a buyer make their own call — outbound to role addresses only, compliance work needing the department addresses, research wanting everything — without re-processing anything. A single merged column forces the decision at extraction time, by whoever built the tool, invisibly.

The empty rows are part of the product. A site that publishes only a contact form should come back explicitly empty with a reason, not silently filled with a guessed info@.

Limitations

The split is a heuristic and it is sometimes wrong. A function-word list cannot know that mike@ is a two-person agency’s shared inbox, or that orders@ at some companies is monitored by one named individual. Treat the labels as a strong default, not as a determination.

Non-English function words are a long tail. kontakt@, klantenservice@, verkoop@ are role addresses; there are hundreds of such words across the languages you are likely to encounter and no list covers all of them. Expect some role addresses to be labelled personal on non-English sites, which is the safer direction for the error to fall.

On-domain does not prove ownership. A parked domain, a shared hosting artefact or a stale page can all yield on-domain addresses that reach nobody.

Classification is not permission. Knowing an address is a role address does not by itself make contacting it lawful, and knowing one is personal does not make it forbidden. GDPR turns on your lawful basis, your notice and your handling of objections. This page describes what the data is; it is not legal advice.

Nothing here validates deliverability. A correctly classified address can still bounce. Verification is a separate step, and doing it by sending is the expensive way.

FAQ

Should I email role addresses or personal ones?

Role addresses for a first approach to a company you have no relationship with: they are published for exactly that, and the compliance position is simpler. Personal addresses when you have a specific reason to reach that specific person, and can say what it is in the first line.

Is [email protected] personal data under GDPR?

Generally not, because it does not identify an individual — which is why the split is worth making. [email protected] is personal data even though it is a work address and even though the company published it. Where an address falls in between, treat it as personal.

Why does my scraped list contain addresses from other companies?

Because they were on the page. Agency credits in footers, PR contacts on press pages, and support widget vendors all put third-party addresses into a company’s HTML. Separating on-domain from off-domain is what catches this.

How do I spot a fabricated list?

Look for a row against every domain you submitted, with no empties. Real websites do not publish contact details at a 100% rate; a list with no gaps has had the gaps filled by pattern-guessing.

Can I filter out anything with a dot in the local part?

No. no.reply@ has a dot and is not a person, sales.uk@ has a dot and is a role address, and plenty of people use jsmith@ with no dot at all. The local part’s shape is weaker evidence than the vocabulary.