Grading a Commit-Mined Email Before It Enters the CRM
You will grade every git-sourced email as current, stale, wrong-channel, or junk using fixed rules two graders both reach.
Key takeaways
- GitHub noreply addresses come in two formats split by a July 18 2017 boundary, so a filter that matches only the modern ID+username pattern silently leaks legacy username-only aliases into your reachable pool.
- A valid MX record proves only that a domain accepts mail, not that a mailbox exists, which makes MX-pass the highest-volume false grade when you treat it as a reachable person.
- With 69% of developers under two years tenure, a work email on a two-year-old commit is more likely dead than a syntactically ugly but recent one - staleness beats syntax as the dominant failure.
- Score identity on the author email, never the committer field, because web-UI and patch-applied commits put 'GitHub' or a maintainer in the committer slot.
- Clean lists lose roughly 2.1% of valid addresses monthly, compounding to 22 to 30% per year, so any grade you assign has a shelf life and needs quarterly re-verification.
- In Refolk's index the US Software Engineer plus Git pool is 49,364 against Germany's 4,574, a 10.8x gap, so thin non-US mined exports are a sourcing artifact, not a grading failure.
You have an export of email addresses pulled from git commit history and a decision to make on each one: does it belong in the CRM or not. This guide is the scoring model for that call. It is for the recruiting or revenue operations owner who is answerable for how the data was gathered, and it gives you a fixed rubric that grades every address on three axes - reachability, identity, and recency - so two people triaging the same export land on the same grade.
This is not a scraper tutorial. It assumes you already have a raw list. What it fixes is the moment after extraction, when a few thousand addresses are sitting in a spreadsheet and someone is tempted to bulk-import them.
Why a mined commit list needs grading, not just filtering
A commit-mined list is a mix of four populations, and only two of them belong in a CRM. Filtering strips the obvious platform noise; grading decides what to do with everything that survives the filter.
The instinct is to run one noreply filter and load the rest. That fails for a specific reason: reachability, identity, and recency are three separate questions, and an address can pass one while failing another. A gmail.com address is reachable but is the wrong channel for a work CRM. A work address on a live domain can be attached to a commit old enough that the person has changed jobs. A committer field can name "GitHub" rather than a human. Each of these is a different failure, and a single filter cannot catch all three.
The other reason to grade rather than filter: git commit emails are not a private data source. A historical mass export once held 5.8 million unique GitHub commit emails covering 2011 to 2015, and it was removed after a request from GitHub. The addresses are public in a technical sense, but a data owner still has to justify what enters the system and why. A grade with the rule that produced it is that justification.
The output of this model is one of four grades per address. Two are loadable, two are quarantined.
| Grade | What it means | Action |
|---|---|---|
| Reachable and current | Real mailbox, right channel, recent commit | Load |
| Reachable but stale | Real mailbox, right channel, past recency cutoff | Load, flag for re-verify |
| Wrong channel | Reaches a person but not usable (noreply, free-mail, role) | Quarantine |
| Junk | Bot, dead domain, or fails syntax | Quarantine |
The three axes every grade rests on
Every grade is a combination of three independent reads: can mail reach the domain, does the address identify a person, and is the observation recent enough to trust. Score each axis on its own before you combine them, because collapsing them early is how false grades slip in.
Reachability answers whether mail can be delivered. It is scored with no-send checks: syntax, DNS, and MX. It tops out at "the domain accepts mail" unless you add mailbox-level probing.
Identity answers who the address belongs to and whether that is the right channel. This is where noreply aliases, bot commits, free-mail domains, and role addresses get separated from real personal-or-work mailboxes. It also decides personal versus work.
Recency answers how old the evidence is. A commit date is a timestamp on the person's relationship to that address, and it decays on two different clocks depending on whether the mailbox is work or personal.
The three axes, scored bottom to top
- RecencyIs the last commit recent enough that the person still holds this address?
- IdentityDoes this address identify a real person, and is it the right channel?
- ReachabilityCan mail reach the domain at all, tested without sending?
The order matters when you work by hand. Reachability is cheapest, so it goes first and clears garbage before you spend attention on identity. Recency is last because it only matters for addresses that already passed the other two.
Reading the address itself: platform aliases and the 2017 boundary
Before any network check, the address string tells you whether it can ever be a real mailbox. GitHub noreply aliases and bot addresses are structurally unreachable for outreach, and they come in three documented forms.
The trap is that GitHub changed its noreply format on July 18, 2017. Accounts created after that date use ID+USERNAME@users.noreply.github.com. Accounts created before, and set to private earlier, use the shorter USERNAME@users.noreply.github.com. GitHub App and bot commits use a third form, USERID+APP-NAME[bot]@users.noreply.github.com.
kind: warning
title: A single-pattern noreply filter leaks
Filtering only the modern ID+ pattern or only the [bot] suffix silently passes the legacy USERNAME@ format into your reachable pool. Match the whole domain string users.noreply.github.com, not a prefix or suffix.
Questions practitioners ask
How do I extract emails from git commit history in the first place?
Run git shortlog -sea inside a cloned repo, where -sea expands to --summary --email --all. That prints commit count, name, and email per contributor across every branch. For an org-wide pull use the GitHub API, but remember the unauthenticated API is capped at 60 requests per hour, so batch large jobs or authenticate to raise the ceiling.
What is the correct github noreply email filter?
Filter on the whole domain string 'users.noreply.github.com', not on the ID+ prefix or the [bot] suffix. GitHub changed the format on July 18 2017, so accounts have either ID+username@ or the legacy username@ form, and matching only one pattern leaks the other. A domain-level grep catches modern, legacy, and app-bot addresses in one pass.
Can I check commit email deliverability without sending a message?
Yes. Verification runs five no-send stages: syntax parsing against RFC 5322, domain DNS lookup, MX record retrieval, an SMTP RCPT TO probe, and classification against catch-all, role, and disposable lists. The first three cost nothing and filter most garbage. Treat an MX pass as 'domain accepts mail', never as proof the specific mailbox exists.
Should I treat a personal Gmail address from a commit as usable?
Grade it reachable but classify it as wrong-channel for a work CRM. A gmail.com author email may deliver perfectly, yet it is not the professional address your outreach or attribution model expects. Classify free-mail domains separately before assigning a grade so a live personal inbox does not get imported as a work contact.
Which recency cutoff should I use for git-sourced work emails?
Pick based on what you are grading. The 24-month cutoff tracks the person and maps to median developer tenure of 3.5 years and the 69% of developers under two years tenure. The 12-month cutoff tracks the mailbox and maps to the 22 to 30% annual decay curve. Job change and mailbox death are different clocks, so state which one your rule targets.
Why did my non-US repo return so few gradeable addresses?
That is usually market depth, not a grading fault. In Refolk's index the US Software Engineer plus Git pool is 49,364 against Germany's 4,574, a derived 10.8x gap. An identical mining workflow returns an order of magnitude more addresses in the US, so a thin European export reflects the size of the underlying population.
Try it on your own search
Stop building boolean strings. Just describe the person.
Type one sentence and I plan the search, read GitHub, public LinkedIn and Crunchbase records, and the open web live, then hand back a ranked shortlist with the reasoning behind every name. No filters to learn, no export to clean up, no sales call to sit through.
- One sentence in, a ranked shortlist out. No boolean, no filters, no seat to buy.
- Read live at search time, not from a database that went stale last quarter.
- Watch every step as it runs, and see why each name made the list.
- Staff backend engineers in NYC who shipped Rust in production
- Series A fintechs in SF under 50 people, growing headcount this year
- Maintainers of fast-growing Rust web frameworks on GitHub
500 free credits on sign-up. No card, no demo call. See real searches.