Reverse email lookup API: what you can and cannot learn from an address

What a reverse email lookup API returns

One request, one shape of answer. For every platform that answered, the response carries whether an account exists for the address (registered), a label for how that fact was established (method) and the exact moment it was established (checkedAt). Three counts sit on top: matches is every registration, socialMatches drops the accounts that came bundled with the mailbox itself, and derivedMatches is explained below. Breach history and public web mentions ride along in the same response, each an array when the source was checked and null when it was not - an empty array and a null are different facts.

curl -X POST "https://api.digifootprint.dev/v1/lookup?wait=true" \
  -H "Authorization: Bearer dfp_your_key" \
  -H "Content-Type: application/json" \
  -d '{"query": "j.okafor@example.com"}'

{
  "query": "j.okafor@example.com",
  "platformsChecked": 887,
  "matches": 3,
  "socialMatches": 2,
  "derivedMatches": 1,
  "servedFromCache": false,
  "results": [
    { "platform": "github",   "registered": true,  "method": "public_api",     "checkedAt": "2026-08-30T08:41:12.004Z" },
    { "platform": "spotify",  "registered": true,  "method": "public_api",     "checkedAt": "2026-08-30T08:41:12.117Z" },
    { "platform": "google",   "registered": true,  "method": "domain_derived", "checkedAt": "2026-08-30T08:41:12.117Z", "mailboxProvider": true },
    { "platform": "twitter",  "registered": false, "method": "public_api",     "checkedAt": "2026-08-30T08:41:12.390Z" },
    { "platform": "reddit",   "registered": true,  "method": "public_api",     "checkedAt": "2026-08-30T08:41:12.512Z", "derivedFrom": "email_local_part" }
  ],
  "breaches": [{ "name": "Adobe", "date": "2013-10-04" }],
  "webMentions": [],
  "phoneDetails": null
}

The google row above carries mailboxProvider: true. A Google or Microsoft account that exists because the address is a Gmail or Microsoft 365 mailbox says nothing about the person, so it counts in matches but not in socialMatches. For risk scoring, socialMatches is usually the number you want.

Reverse email lookup coverage: 27 platforms answer for an address

Of the 887 platforms in the registry, 27 can be checked from an email address, 4 of them from an email or a username interchangeably. That is a small fraction of the whole, and it is the honest number: most platforms expose nothing about an address, and we do not pretend otherwise. What the email set lacks in breadth it makes up in signal. It includes the accounts people actually hold - GitHub, Spotify, Instagram, X, Discord, LinkedIn - and a hit on any of them means that exact address was used to sign up, not that a similar-looking handle exists somewhere. Each platform page says which inputs it accepts; the social and developer hubs list the ones most teams care about.

Derived handles: the local part tried as a username

Because a username reaches far more platforms than an email, the part of the address before the @ is also tried as a handle across the username-keyed platforms. Anything found that way is labelled derivedFrom: "email_local_part" and counted only in derivedMatches, never in matches or socialMatches. The distinction matters: a derived hit says a handle exists, not that this person owns it. Handles collide, and common words collide constantly. Local parts that belong to a role rather than a person - the info and admin family - are not derived at all, because they exist on essentially every platform and would only add noise. Treat derived rows as leads to corroborate, and treat the direct rows as facts about the address.

What a reverse email lookup cannot tell you

It cannot tell you who the person is. No display names, photos, bios, followers, posts, locations or anything else that lives inside an account is collected or returned - a reverse email lookup here is a registration check, not a profile read. It cannot tell you the address is unused: a platform that did not answer confidently is omitted from results entirely rather than reported as registered: false, so absence from the list is an unknown, not a negative. And it cannot tell you an address is clean: breaches: null means breach data was not enabled for your account, which is a different fact from [], meaning it was checked and nothing was found. Every field is verified or omitted, never guessed.

Where a reverse email lookup fits

At signup, the address is the identifier the person gave you, which makes it the highest-signal input for fraud prevention: an address with years of registrations and a breach record from 2013 is a very different object from one that exists nowhere. In KYC and AML review it corroborates a submitted identity without touching profile contents. Trust and safety teams use it to link a fresh account to a banned one by the address it shares, and OSINT workflows use it as the first pass before manual work. If you need the widest reach rather than the highest signal, start from the handle instead - see the username search API guide. There are free lookups to start; the pricing section has the rest.