How to Find Business Email Addresses

There are only three ways to end up with a business email address: it was published and you found it, it was inferred from a pattern, or it was guessed. They look identical in a spreadsheet column and behave completely differently once you press send — on deliverability, on accuracy, and on the law.

Published, inferred, guessed

Make this distinction a column in your data before you make it an argument in a meeting.

Category	What it means	What it costs
Published	The business put the address on a page it controls: a mailto: link, a contact page, a legal imprint, a schema.org field	Nothing. It is a deliberate invitation to write, and it is the only category with a source URL you can cite
Inferred	You saw a.rossi@ elsewhere on the domain and constructed m.bianchi@ for someone else	An accuracy risk you carry, and one you must verify before it touches a sending domain
Guessed	You generated permutations and fired them at the domain to see which ones did not bounce	Reputation damage, and a pattern the FTC describes in terms you do not want applied to you

Almost every "email finder" article treats these as one activity. They are not, and the rest of this piece follows the split.

Where business addresses are actually published

In rough order of yield per page fetched:

• The contact page. /contact, /contact-us, /kontakt, /contatti. Take the mailto: href rather than the visible text — the text is often an image or an obfuscated string, while the href is machine-readable.
• Structured data. Many sites publish schema.org Organization or LocalBusiness JSON-LD carrying email, telephone and address. It is already parsed, already canonical, and it is the first place to look rather than the last.
• Legal imprint pages. In Germany and Austria the Impressum is a legal requirement and reliably carries a real, monitored address. Equivalents exist across the EU. For European targets this is the single highest-yield page on the site.
• The footer of whatever page you landed on. Cheap, because you already fetched it.
• Team and about pages. Where named addresses appear, when they appear at all.
• Public filings and registries. Slow, authoritative, jurisdiction-specific.

Four to six pages per domain covers most small and mid-sized sites. Fetching them is a page-scraping job at $0.0002 per page; if you would rather not write and maintain the extractor, the site contacts collector returns one contact record per domain with the pages it used, at $0.02 per site.

One habit worth building from day one: store the URL the address came from. It costs a column, and it is the difference between being able to answer "where did you get this?" and not.

Role mailboxes are a category, not a fallback

info@, sales@, support@, hello@ get treated as the consolation prize when a named address cannot be found. That is backwards on two counts.

First, they are standardised. RFC 2142 defines mailbox names for common business and service functions precisely so that a stranger can reach an organisation without knowing anyone's name. A role mailbox is the address the organisation nominated for unsolicited contact.

Second, and more consequentially: a role mailbox generally is not personal data, while maria.rossi@ generally is. That single distinction changes which obligations attach — whether GDPR's transparency duties are triggered, whether a UK PECR analysis is needed, whether the record belongs in your data-subject request tooling at all.

So keep two columns, not one, and let the choice be deliberate. For a first-touch message to a company you have never contacted, a role mailbox is frequently the better address as well as the lighter one.

What pattern guessing actually costs

The permutator-plus-bounce-test workflow is popular because it is easy. Three reasons to keep it out of production.

It is the pattern the FTC names. The CAN-SPAM guidance lists, among the acts carrying criminal penalties, harvesting email addresses or generating them through a dictionary attack — which it defines as sending email to addresses made up of random characters in the hope of reaching valid ones. Generating permutations of a person's name is not identical to random characters, and reasonable people can argue about where the line sits. That is precisely the argument you do not want to be having.

It destroys the asset you cannot rebuild quickly. Google's sender guidelines set a hard expectation: keep the spam rate reported in Postmaster Tools below 0.30%, and preferably under 0.10%. Every wrong guess is a bounce or a complaint against that budget. A domain reputation takes months to build and one campaign to spend.

It fails silently on catch-all domains. A domain configured to accept anything will accept every permutation you send. The absence of a bounce is not evidence of a correct address; it is evidence of a configuration.

Verification, and what it cannot tell you

Verification is a series of narrowing checks, each of which answers less than people assume.

• Syntax. Cheap, and only rules out the obviously broken.
• Domain and MX records. Does the domain resolve, and does it publish mail exchangers? This is the highest-value check per unit of effort: a domain with no MX cannot receive mail at all, and dead domains are a large share of a stale list.
• Disposable and parked-domain checks. Useful, and unglamorous.
• SMTP-level probing. Widely offered, decreasingly informative. Many providers accept-then-discard, greylist unfamiliar senders, or answer identically for every local part. A "valid" verdict from a probe against a catch-all domain carries essentially no information, and aggressive probing is itself the kind of traffic that gets a source blocked.

The realistic posture: verify the domain thoroughly, treat mailbox-level verdicts as weak evidence, and lean on provenance instead. A published address with a source URL beats a guessed address with a green tick from a verifier.

On the sending side, the requirements are published and specific. All senders need SPF or DKIM. Senders above 5,000 messages a day to personal Gmail accounts need SPF, DKIM and DMARC, with the From: domain aligned to the SPF or DKIM domain, plus one-click unsubscribe headers on marketing mail — the List-Unsubscribe-Post and List-Unsubscribe pair, not just a link in the footer. None of that is optional, and none of it compensates for a bad list.

What attaches the moment you find one

Finding an address is collection, and collection has consequences before any message is sent.

If it identifies a person and they are in the EU or UK, GDPR Article 14 applies. You did not get the data from them, so you owe them a notice: who you are, what you are doing with it, the legal basis, their rights, and the source it came from — including whether that source was publicly accessible. Within one month, or at the first communication if you intend to contact them, whichever is sooner. This is the clause that makes the source-URL column load-bearing rather than tidy.

Public availability is not a legal basis. The ICO states directly that using publicly available personal information for direct marketing still requires compliance with UK GDPR, and that you must consider whether your marketing would be unexpected to the person. It also advises against tracing replacement contact details when someone's old address stops working.

Which outreach rule applies depends on the recipient's legal form. Under UK PECR the email consent requirement does not apply to corporate subscribers — limited companies, LLPs, Scottish partnerships — but sole traders and ordinary partnerships are individual subscribers and need consent or the soft opt-in. The regulator's advice when you cannot tell is to treat the contact as an individual. In the US, CAN-SPAM requires no consent but does require truthful headers, a clear identification as advertising, a valid postal address, and an opt-out honoured within 10 business days — with penalties up to $53,088 per offending email.

More on the outreach layer in is lead generation legal, and on building the underlying list in how to build a B2B lead list.

Doing it at scale without doing it badly

The scaled version is the same method with three engineering additions.

1. Bound the crawl per domain. A fixed page budget and a fixed path list. Contact discovery is not a site crawl, and treating it as one is how you get blocked and overspend simultaneously.
2. Make provenance structural. Every address row carries the URL it came from, the timestamp, and the category — published, inferred or guessed. If a row cannot carry all three, it does not enter the table.
3. Separate discovery from sending. Different systems, different rate limits, different owners. The failure mode that hurts is a discovery bug quietly feeding a sender, and the fix is a gate between them, not more care.

Run at volume, both stages sit on one key: page fetches at $0.0002 each if you own the parser, the contacts collector at $0.02 per site if you do not, or the lead collector at $0.01 per enriched lead when discovery and contact extraction should be a single call. Failed requests are never billed, and every account gets $2 of free usage a month — enough to run a few hundred domains and see the published-versus-inferred ratio in your own segment before deciding anything.