Provenance
Where every address comes from
The crawler, the pages it reads, how a name is attributed, what is stored with each address, and an erasure that also prevents re-collection.
The claim this product rests on is narrow and checkable: every discovered address keeps the page it was published on. Not a data supplier, not an aggregate of several, not “our proprietary database” — a URL you can open. This page is how that happens and what it does not cover.
There is no index-size figure anywhere on this page or on any other, deliberately. Index size is the number this category competes on and it is the number least connected to whether any individual answer is right.
- 1
Resolve the origin
A domain is resolved to the site that actually serves it, so a redirect chain or a parked domain does not produce a crawl of the wrong thing.
- 2
Read
robots.txtfirstBefore any page is fetched. A disallowed path is not fetched, and the crawler identifies itself by name so a site owner can see it in their logs and write a rule for it. The rules it binds itself to are published at /bot.
- 3
Plan the pages
Shallow and targeted rather than exhaustive. Candidates come from the site’s own links and sitemap, then from well-known paths —
/team,/about,/contact,/impressum,/kontakt— then from anchor text. Blind path probing is capped at eight: a crawler that guesses a thousand URLs on someone else’s server is a load problem, not a strategy. - 4
Extract
Four methods, strongest first:
mailtohrefs and Cloudflaredata-cfemailread off the parsed DOM rather than by regular expression, then textual obfuscation (bob [at] acme [dot] com), then plain text. Asset filenames, documentation placeholders and error-tracking keys are excluded, because each of those produces something that looks exactly like an address and is not one. - 5
Attribute a name
Also strongest first, and the ordering is reported rather than hidden: a schema.org
Personin JSON-LD or microdata, then proximity in the DOM, then the local part — and the local part only where the separator is unambiguous.jsmithis not trusted. No competitor distinguishes "the publisher told us in markup" from "we split the local part and guessed". - 6
Score, with the factors attached
Confidence is 0–100 with a band, and every score carries the factors that produced it: a code, a label, whether the effect was positive, negative or a ceiling, and its weight. A score is a disclosure control, not a summary — an opaque number is what lets a product ship confident nonsense.
- 7
Index with the citation
Every stored address carries where it came from: the URL, the domain, which of the four extraction methods found it, the date it was first extracted, the date it was last seen there, and whether it is still on that page today. That last flag is the difference between a contact you can explain and one you cannot.
- 8
Infer the address pattern
From addresses whose name is known, the domain’s format is inferred —
{first}.{last}and the rest — with confidence from agreement multiplied by sample size, and an ambiguous sample splitting its vote. Transliteration runs both ways, somullerandmuellerare the same person. The pattern finder shows the samples it used rather than only the answer.
What is stored with an address
| Field | What it records |
|---|---|
uri | The exact page the address was published on. |
domain | The site that published it, which is not always the address’s own domain. |
method | Which of the four extraction methods found it: mailto, cfemail, obfuscated, text — strongest first. |
extractedOn | The date it was first read from that page. |
lastSeenOn | The date it was most recently confirmed there. |
stillOnPage | False means it was published once and has since been taken down. That is a signal about the person, not a data-quality defect. |
Ceilings, not deductions
Where the evidence is weak, confidence is capped rather than penalised. The distinction matters: a −22 penalty applied to a raw 122 clamps to 100 and silently does nothing, which is exactly where it was supposed to do something.
| Condition | Confidence cannot exceed |
|---|---|
| Address not verified | 74 |
| Catch-all domain, address published somewhere | 88 |
| Catch-all domain, address generated from a pattern | 55 |
| Disposable domain | 40 |
| Domain has no MX records | 20 |
| SMTP says the mailbox does not exist | 5 |
Erasure that prevents re-collection
Most opt-outs mark a record hidden. The address stays in the index, the next crawl finds it on the same page again, and whether it stays suppressed depends on a flag surviving every future write path.
A suppression request here erases the matching records immediately and keeps the address out of every later crawl. It is enforced on the write path, on every read path, and with or without a database configured — so there is no code path where a suppressed address comes back. That is a stronger commitment than an opt-out and it is the one worth reading this page for.
It is also reachable with an ordinary verification key rather than an operations one, on purpose: the people who need removal are not the people holding the ops credentials. Use the data request page if you would rather not write code for it.
What we do not hold, and will not
- Personal consumer addresses. The index holds business addresses companies publish about themselves. Somebody’s private Gmail is a different activity with different ethics and it is not one we are in.
- Purchased or scraped lists. Nothing in the index arrived from a data broker, and the seeded company set is not drawn from one either.
- Data from platforms whose terms forbid collecting it. Exporting contacts you are already connected to is a feature those platforms offer. Scraping profiles you are not is not, and we would not publish a method we would not use.
- Spam-trap identification. We have none and claim none. A trap address is indistinguishable from a real mailbox at the protocol level, and a product claiming certainty there is selling a guess with a label on it.
- Inbox placement and blocklist monitoring. Different products. The free tools read your DNS records and look up a host on request; they do not watch anything for you.
The rest of the commitment
- Crawler policyWhat the crawler is called, what it fetches, and how to exclude it.
- Remove an addressErasure that also keeps it out of every later crawl.
- How we verifyThe eight stages of a verification, and why there is no accuracy figure.
- Privacy policyThe legal version of everything on this page.
- SubprocessorsWho else touches the data, and for what.
- Catch-all domainsWhy a discovered address on one is capped rather than confirmed.
Questions about where the data comes from
Where do email finders get their data?
Ours comes from pages companies publish about themselves — team, about, contact and imprint pages — fetched by a crawler that reads robots.txt first and identifies itself. Every stored address keeps the URL it was found on and the date it was last seen there. We do not buy lists and we do not scrape platforms whose terms forbid it.
Are email finder tools legal?
Business contact data a company publishes on its own website is generally processable in most jurisdictions, subject to conditions that vary by where you and the recipient are. What separates tools is how the data was collected and whether erasure is honoured. Take your own legal advice for your jurisdiction; this is a description of our practice, not advice about yours.
Can email finders find personal email addresses?
Ours deliberately does not. The index holds business addresses published by companies about themselves. A B2B contact index has no business need for personal consumer addresses, and holding them would create obligations that serve nobody.
Are the email addresses guesses or found somewhere?
Both exist and the difference matters, which is why the result says which one you got. A found address carries the page it was published on and the date it was last confirmed there. A generated one carries the pattern it came from and how many addresses that pattern was inferred from — and if the domain is catch-all, its confidence is capped at 55.
How do I remove my email address from your database?
Submit it through the data request page. The record is erased immediately and the address is also kept out of every later crawl, so it does not reappear the next time the site is read. The route takes an ordinary verification key rather than an operations key, on purpose: the people who need removal are not the people holding the ops credentials.
Check it on a domain you know
Run a domain search on your own company. Every address comes back with the page it was published on, so you can check the answer against a site you can read yourself.