Diagnosing a Commit-Mined Contact Batch That Bounced

You mined author emails from a repository's commit history, sent to them, and the bounce rate came back high enough to threaten your sending domain. This guide is for the person answerable for that batch - recruiting ops, revenue ops, or the deliverability owner - and it walks one already-sent, already-bounced list backward to root cause. By the end you can sort every address into a named bounce bucket with a real count, recover the deliverable subset, suppress what must never re-send, and fix the miner so the next batch clears the threshold.

Most guides on this topic explain how to set your own noreply address. That is not the job here. The job is auditing someone else's mined list after it has already bounced, and that means naming each bucket, running the real git commands, and knowing which wrong turns waste a day.

What a commit-mined bounce actually tells you

A high bounce on a commit-mined batch is rarely a data-decay problem. It is usually a structural one: most of the addresses were never routable to begin with. Because GitHub applies its noreply form by default when "Keep my email addresses private" is on, a modern repo's author list is dominated by addresses that point at a dead domain. Every one you sent hit users.noreply.github.com, which accepts no mail, and every one counted as a bounce.

So before you touch a verifier or blame list age, you need to know the composition of what you sent. The bounce log tells you what failed. The re-extracted repo tells you why. The reconciliation of the two is the whole diagnosis.

Here is the shape of the problem. A commit-mined list narrows sharply from raw addresses to humans you can actually reach, and each narrowing step is a bounce cause you can name and count.

The stage figures above are an illustrative shape, not measured counts. Your own numbers come out of the reconciliation in the step-by-step. The point is directional: the largest single drop is the noreply layer, and it happens before any verifier runs.

The bounce thresholds you are being judged against

The threshold that matters is not one number but a set of provider ceilings, and you want to sit well under all of them. Amazon SES reviews accounts at a 5% bounce rate and may pause sending above 10%, so the risk to your domain is real and automatic, not a warning you can ignore.

Hard bounces are the ones that hurt. A hard bounce is a permanent failure from an invalid address, a non-existent domain, or a disabled mailbox, and it immediately damages sender reputation because it signals poor list hygiene. A soft bounce is temporary, but it does not stay harmless: Mailchimp converts a soft bounce to a hard bounce after 7 to 15 occurrences depending on engagement, and SendGrid retries a deferred message for up to 72 hours before blocking. Treat three or more consecutive soft bounces to one address as hard.

Read this table as a floor-and-ceiling. The provider rows are where enforcement kicks in. The practitioner row is where you want to live so that one bad batch does not tip you into enforcement. If your bounced batch put you above 5%, the domain is already at risk and step one is not optional.

The four buckets every mined address falls into

Every address in a commit-mined batch sorts into exactly one of four buckets, and the bucket decides its fate before you ever verify it. Getting the sort right is the difference between a clean recovery and a second bounce.

The two noreply formats depend on account age. Accounts created after July 18, 2017 get an ID number and username, in the form ID+USERNAME@users.noreply.github.com. Accounts created before that date, with privacy enabled before that date, get USERNAME@users.noreply.github.com. The distinction matters for recovery: the ID form maps reliably to a GitHub account by its user-ID part, while the username-only form breaks if the person later renamed their account.

The bot bucket is its own hazard. Bot commits carry bracketed-login noreply addresses: dependabot authors as 49699333+dependabot[bot]@users.noreply.github.com, and github-actions authors as 41898282+github-actions[bot]@users.noreply.github.com. The general app pattern is USERID+APP-NAME[bot]@users.noreply.github.com. In an active repo, these bots can author a large fraction of commits, so a raw mine skews toward addresses that must never be contacted. They inflate the batch without inflating the count of reachable humans.

Extract the git addresses cleanly

Re-clone the repo and pull a counted, deduplicated author-email list with one command. That list, not the ESP export, is your source of truth for what you actually sent. The ESP knows what bounced; only the repo knows what each address was.

The workhorse is git shortlog -sne, where -s suppresses descriptions for a count-only summary, -n sorts by number of commits per author, and -e shows the email address. Authors are unique by name plus email, so that gives you a deduplicated author-plus-email-plus-count list in one pass.

# Counted, deduplicated author-email list
git log --all --pretty=format:'%ae' | sort | uniq -c | sort -rn > authors.txt

# Or the canonical per-author summary
git shortlog -sne --all

# Masked (noreply) addresses
grep 'users.noreply.github.com' authors.txt > bucket_noreply.txt

# Bot / role addresses (require BOTH conditions)
grep '\[bot\]@users.noreply.github.com' authors.txt > bucket_bot.txt
grep -E 'support@github.com|no-reply@github.com' authors.txt >> bucket_bot.txt

# Real mailboxes = everything not already bucketed
grep -v 'users.noreply.github.com' authors.txt | \
  grep -viE 'support@github.com|no-reply@github.com' > bucket_real.txt

One caution on canonicalisation. The --use-mailmap flag coalesces alias names and emails to canonical identities, which is useful, but it can also collapse two different people or hide an alias. Check the raw %ae output alongside the mailmapped view so a mailmap does not quietly merge or mask an address you needed to see.

If the salvage math comes out thin, this is the exit. Rather than nurse a broken batch back to health, Refolk lets you ask for the people you want in plain English and get back addresses that are already verified, which is often cheaper than recovering a masked German-Rust list of a few dozen contributors.

The teardown: run the batch backward to root cause

This is the procedure. Follow it on your own case as you read. The counts in the walkthrough below are worked examples on a hypothetical 100-address batch; substitute yours at each fork.

Worked example, address by address

Take a batch of 100 sent addresses that came back at 8% hard bounce - already past the SES review line.

Step 1, freeze. Pull the log. Say 62 delivered, 38 bounced, of which 30 are 5xx (hard) and 8 are 4xx (soft). That 30% hard is the headline, but the campaign-level 8% was diluted by earlier clean batches; this one is worse than the average implied.

Step 2, re-extract. The repo yields 100 unique author emails matching the sent list. Good - the mine and the send agree, so the problem is in the addresses, not in a join error.

Step 3, bucket. The greps split it: 40 on users.noreply.github.com (34 ID-form, 6 legacy), 7 bot/role (5 dependabot and github-actions, 2 support@github.com), 53 real mailboxes.

Step 4, reconcile. Join buckets to bounce codes. The result is the payoff table: 40 noreply and 7 bot/role addresses account for 30 hard bounces between them (some noreply addresses had been silently dropped by the ESP and never counted, which is why the numbers do not sum cleanly - note that and move on). Of the 53 real mailboxes, 8 soft-bounced and the rest delivered. Now every bounce has a named cause.

Step 5, recover. The 40 noreply addresses are the salvage candidates. This is where the calendar cliff bites, covered in the next section. Suppose 12 of the 34 ID-form addresses resolve to a real email via the events API and pass SMTP verify; the other 22 do not. The 6 legacy addresses give you logins but no mailbox. Deliverable subset from recovery: 12. Unrecoverable: 28.

Step 6, suppress. All 30 hard bounces, all 47 noreply-and-bot addresses, and any address that failed verification go on the suppression list. They can never re-send.

Step 7, fix the miner. Add the noreply and bot filters from the template above so the extractor never emits those addresses again. Dry-run the same repo: it should now emit only the real-mailbox bucket plus recovered addresses.

Step 8, re-verify and re-project. Run the surviving real mailboxes plus the 12 recovered addresses through a verifier. If catch-alls and dead mailboxes cut that to, say, 50 clean addresses, project the bounce rate on those and confirm it lands under 1% hard and 2% total before you re-send anything.

Recovering a real email, and where recovery hits a wall

Recovery works for a masked address only through public traces outside git, and it fails silently more often than it succeeds. The ID+username noreply form already yields the GitHub ID and login, but never a mailbox. To get a real address you fall back to the public events endpoint at api.github.com/users/USERNAME/events/public, or you append .patch to a commit URL to reveal the committer's email - and the .patch trick only works if the user had not set their email to private.

The hard limit is a calendar cliff. The events fallback only surfaces an email if the person made a commit to a public repo during the current calendar year and had their email exposed when they made it. An inactive contributor is structurally unrecoverable regardless of tooling, so check the date of their last public commit before you conclude anything. A stale events window returns nothing and looks identical to a genuine dead end.

Market size sets that judgement. In Refolk's index, the same skill is far larger in one market than another, and that decides whether salvage is worth the hour.

The counts above come from Refolk's index; the multiples are derived from them. Read them as a re-mine-or-rescue signal. A thin salvaged German-Rust batch sits against only 967 addressable people, so rescuing 12 masked addresses may be worth the hour. The same effort on a US-Rust or German-Go segment, which are 3.5x and 5x larger, is usually wasted: re-mine instead.

How this goes wrong: the false positives that waste a day

Every step above has a failure mode that produces a confident wrong answer. These are the ones that cost you a second bounce or a dropped real contributor, so treat this section as the checklist behind the checklist.

• Regex over-matches bots. A bare [bot] filter also blocks a human whose login literally contains "bot", dropping a real contributor. Check that the domain is users.noreply.github.com and the login ends in [bot] before you drop it.
• Spoofed author. Email is a user-controlled field, so if someone commits in another person's name it resolves to the wrong person. Cross-reference the login against the commit's verified signature before you trust the identity.
• Catch-all "valid" verdicts. A catch-all server accepts all mail, so a verifier cannot confirm a mailbox exists. That produces a "valid" that hard bounces. Catch-alls run up to 30% in B2B and about 23% of unverified catch-alls bounce, so treat every catch-all as risky, not deliverable.
• Hashed events email. Some historical events emit a SHA-1-hashed local part, for example 40 hex characters @gmail.com. Send to it and it bounces. Reject any local part matching ^[0-9a-f]{40}$.
• Soft bounce misread as recoverable. A repeatedly deferred mailbox is effectively dead. Treat three or more consecutive soft bounces as a hard bounce and suppress it.
• Mailmap masking duplicates. --use-mailmap can collapse two people or hide an alias. Check the raw %ae output alongside the mailmapped view.
• Stale events window. The events fallback returns nothing if the last public commit predates this calendar year, producing a false "unrecoverable". Check the last-commit date before you conclude the mailbox is gone.

The catch-all trap deserves the most weight because it survives every earlier filter. Your buckets are clean, your recovery worked, your verifier passed the address - and it still bounces, because a catch-all domain accepted the SMTP probe without a mailbox behind it. On developer domains this is common enough to breach the 2% total-bounce line on its own. When a segment is heavy with catch-alls, the honest move is to hold those addresses out of the near-threshold batch rather than gamble the domain on them.

Before you call the batch salvaged

Run this list before you resend anything. Each item is a checkable state, not a topic, and skipping one is how a "fixed" batch bounces again.

Keep the fixed pipeline honest

The fix is not the suppression list; it is the filter that runs before the extractor emits a single address. Once the miner drops noreply and bot addresses by default, the noreply layer - your largest single bounce cause - never reaches a send again. That is the difference between diagnosing one batch and never having this batch again.

Two things drift and need a re-check. First, contact data decays roughly 22% to 30% per year, so a real mailbox verified today is not verified in twelve months; re-verify before any list older than a quarter goes out. Second, the recovery calendar cliff resets every January: an address that was unrecoverable last year because the person went quiet may resolve again if they commit publicly this year. Re-run recovery on your unrecoverable subset once per calendar year before writing those contacts off for good.

When the salvage math is thin - a small segment, a heavy noreply share, a catch-all-dense domain - the honest call is to stop rescuing and start over from a source that returns verified addresses. Asking Refolk for the people you want by role, skill, and place gives you a list that has already cleared the deliverability threshold, which beats another pass over a batch that was mostly unroutable to begin with.