Finding a contact, legitimately

In the EU, the UK and a growing number of other jurisdictions, a work email address identifying a named person is personal data. Collecting it, storing it and using it for outreach are each regulated activities with obligations attached — a lawful basis, a notice, and a right to object.

This is not a footnote to bolt on later. It shapes what the system may store, for how long, and what it must do when someone asks. Building first and considering it afterwards usually means rebuilding.

The obligations are concrete enough to design against. Be able to say where an address came from and when, be able to delete it on request within the required window, honour an objection permanently rather than for a cooling-off period, and be able to tell someone what you hold about them.

Pattern-based generation — first.last, first initial plus surname — is what most tools do, and it fails three ways. It bounces, and bounce rates damage domain reputation for everyone on the platform. It reaches the wrong person when the pattern collides with a different employee. And an unverified guess is a claim, not a contact.

The third failure is the most damaging in practice: a message about someone’s job search landing in a stranger’s inbox at their company. That is a privacy incident the candidate never authorised and cannot undo.

The reputation cost compounds in a way individual users never see. Sustained bounces from a shared sending domain degrade deliverability for every legitimate message the platform sends, so one aggressive feature quietly reduces the effectiveness of everything else the product does.

• Unverified addresses bounce, and bounces are a shared cost
• Pattern collisions deliver to the wrong colleague
• Misdelivered job search mail is a real privacy harm
• Never store a guessed address as if it were known

Most postings give a route: an application form, a stated contact address, a careers inbox, sometimes a named recruiter with published contact details. That route is consented contact by definition, and it reaches someone whose job is to read it.

An agent should exhaust these before attempting discovery at all. Bypassing an offered channel to reach someone privately is rarely received the way the sender imagined.

It usually works better, too, which makes this an easy argument. A message through the stated channel arrives where someone is looking for it; the same message to a personal address arrives as an intrusion, and the second is less likely to get a reply even when it is read.

Company contact pages, the posting itself and a recruiter’s own published profile are legitimate sources. Scraping platforms in breach of their terms, or buying scraped databases of unclear provenance, is not — and the second brings liability along with the data.

Store the source and the date with every address. Without provenance you cannot answer a deletion request properly, you cannot tell verified from guessed, and you cannot defend how you obtained it.

Record a confidence alongside it and never let the two collapse. An address read from a posting and an address inferred from a pattern must be distinguishable forever, because the moment they are stored identically, the system has lost the ability to behave differently about them.

A suppression list is the single most important piece of state in this system. Anyone who asks not to be contacted goes on it permanently, checked before generation rather than before sending, so no message is ever produced for a suppressed recipient.

Make it global rather than per user. If a recruiter has asked one candidate’s agent not to contact them, honouring that only for that candidate means the platform keeps contacting them through everyone else, which is precisely the behaviour the objection was about.

Detect the informal objection as well as the formal one. "Please stop", a bounce marked as a complaint, or a reply asking who gave you the address are all objections, and a system that only recognises a formal opt-out link will keep sending.

Rate limits belong beside it. Even legitimate contact becomes harassment at volume, and a per-recipient cap — never more than one unanswered message, never again within a quarter — costs nothing and prevents the pattern that makes a platform unwelcome.

Verification before sending — that the domain accepts mail and the address exists — reduces bounces substantially. It does not confirm you have the right person, which no technical check can.

And the agent must be allowed to conclude that no contact is available. The alternative is a system whose fallback is always a guess, which guarantees the failure mode you were trying to avoid.

Make that outcome useful rather than a dead end. Reporting that no verified contact exists and offering the application form instead is a complete answer, and it is the honest version of what the tool was asked to do.