# 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.*

- Canonical URL: https://www.refolk.ai/guides/grading-commit-mined-email
- Pillar: Process, data, and compliance
- Format: Framework
- Published: 2026-08-18
- Last reviewed: 2026-08-18
- Reading time: 4 min
- Keywords: extract emails from git commit history, github noreply email filter, commit email deliverability, verify scraped developer email, personal vs work email git, clean git shortlog email list

## 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.

**22-30% - Annual loss of valid addresses on a clean list**

Even a perfect list decays at roughly 2.1% per month, so every grade has a shelf life.

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

1. **Recency** - Is the last commit recent enough that the person still holds this address?
2. **Identity** - Does this address identify a real person, and is it the right channel?
3. **Reachability** - Can mail reach the domain at all, tested without sending?

*An address must clear every layer to earn a loadable grade; each layer answers a different question.*

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`.

```callout
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.

## Frequently asked questions

### 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.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/grading-commit-mined-email*