Updated 2026-08-31
An email age check estimates how long an address has existed, because a freshly created address behind an otherwise clean application is one of the strongest fraud signals there is. No API can return a true creation date - mailbox providers do not publish one - so this guide covers what can actually be established, how to establish it from breach dates and registration breadth, and how much weight the result will bear.
The question people actually want answered is “was this address made yesterday to apply to us?” The honest answer is that the only party who knows is the mailbox provider, and no provider exposes it. Any vendor returning an emailAge field in days is modelling, not measuring - usually from the same breach data described below, with the modelling assumptions hidden inside a number that looks like a fact.
This API returns no age field for that reason. Inventing one would break the rule the whole product rests on: a value you cannot audit is indistinguishable from a value that was verified, once it reaches a risk model.
A data breach is a dated snapshot of a service's user table. If an address is in it, the address existed on that date. That is not an inference - it is a record, and it is the strongest age evidence available from open sources.
{
"query": "someone@example.com",
"matches": 6,
"breaches": [
{ "name": "LinkedIn", "breachDate": "2012-05-05" },
{ "name": "Dropbox", "breachDate": "2012-07-01" },
{ "name": "Collection1", "breachDate": "2019-01-07" }
]
}
// Earliest breachDate = 2012-05-05.
// The address demonstrably existed at least 14 years ago.Take the minimum breachDate across the breaches array and you have a floor on the age. Note what it is not: a creation date. An address first breached in 2019 may well have been created in 2009 and simply never appeared in an earlier corpus. The bound only ever runs one way.
Handle the null case explicitly. When the breach source is not configured, breaches is null rather than an empty array - “we did not look” is a different fact from “we looked and found nothing”, and collapsing them turns a missing check into a false conclusion about age. See the breach check guide.
The second signal is how many platforms the address is registered on. It carries no date, so it cannot produce a bound - but accounts accumulate over time, and an address registered across a dozen independent services has usually been in use for a while. Read it as corroboration for a breach-derived floor, never as a substitute for one.
Where breadth genuinely earns its place is the case breach data misses entirely: an address with no breach history and no registrations anywhere. That combination is the thin footprint described in the thin footprint guide, and it is more actionable than any single estimated age would be.
Derive the floor in your own code, from the raw breach dates, and keep it beside the facts it came from rather than replacing them. A reviewer who can see “earliest breach 2012-05-05, LinkedIn” can evaluate the reasoning; a reviewer who sees “email age: 14 years” can only trust it.
Then route on it rather than reject on it. Combine an unknown-or-recent floor with a thin registration result and low corroboration, and you have a case worth a human - which is exactly the outcome a signup risk check should produce.