Email age check: how old is an email address, really

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.

Why nobody can give you a creation date

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.

Breach dates: the one defensible lower bound

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.

Deriving a lower bound from breaches
{
  "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.

Registration breadth as corroboration

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.

Using it without over-using it

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.

Frequently asked questions

Can an API tell me when an email address was created?
No API can return a true creation date, and any that claims to is estimating. Mailbox providers - Gmail, Outlook, Yahoo, corporate mail servers - do not publish account creation dates to third parties through any public interface. What can be established is a defensible lower bound: the earliest date the address is demonstrably known to have existed.
How do you check the age of an email address?
The most defensible method is breach dates. If an address appears in a breach dated 2014, the address existed in 2014 and no argument changes that. Registration breadth is a weaker corroborating signal: an address registered on many independent platforms has usually accumulated them over time, though breadth alone gives no date.
What does the Digital Footprint API return for email age?
The API returns no age field, because it has no defensible value to put in one. It returns the breach records an address appears in, each with the breach date, and the platforms it is registered on. The earliest breach date is the lower bound on age; deriving it is one line in your own code, and doing it there means the number carries your assumptions rather than ours.
What if an address has no breach history at all?
Then no age lower bound can be established from breach data, and the correct reading is "unknown", not "new". Plenty of long-lived addresses have never appeared in a breach corpus, particularly addresses on private domains or in regions where the widely-circulated breach sets have poor coverage. Absence of breach history is not evidence of recency.
Is a new email address a reliable fraud signal on its own?
It is a strong input and a poor decision rule. Real people create new addresses constantly - for a new job, after a provider migration, or specifically to keep a service separate from their main inbox. A recent-looking address should raise the verification level rather than trigger a decline, and it becomes genuinely informative only alongside other thin-footprint signals.

Related

Start freeTry a lookup