Regarding 1, I assume you’ve already verified it, so it’s likely 2 or a hub bug. The fact that it suddenly started happening one day and has persisted ever since strongly suggests a hub bug—or more likely, a case of forgetting to reconfigure / restart the daemon…
Likely Causes
1. Your email system started blocking or filtering HF emails
What it is:
Your mail infrastructure (Exchange/Google Workspace/gateway) now treats @huggingface.co as spam, risky, or suppressed. Messages are sent, but:
- Go to spam/quarantine, or
- Are rejected or silently dropped due to SPF/DMARC/gateway rules, or
- Are suppressed by HF’s email provider after bounces/complaints.
Why it’s the most likely:
- Similar issues are well-documented for HF confirmation emails: users often don’t receive them until they check spam, change email settings, or HF support unblocks their address at the provider. (Hugging Face Forums)
- HF staff explicitly mention some addresses ending up on their provider’s blocklist and needing manual unblocking. (Hugging Face Forums)
- In many organizations, IT changes spam filters, gateways, or DMARC without touching HF settings, which perfectly fits “worked for months, then stopped.”
What to do:
Search all folders and quarantine for @huggingface.co, and have IT check mail logs. Run a test by sending notifications to a Gmail address instead of your corporate one; if Gmail works, the problem is almost certainly your mail system.
2. Recipients changed because of the “first 5 admins” rule or Notification email edits
What it is:
By default, for org-owned gated models/collections, HF sends access-request emails to the first 5 admins of your org, unless you explicitly set a Notifications email override. (Hugging Face)
If:
- New admins were added,
- Admin ordering changed, or
- Someone edited/cleared the Notifications email field,
then HF can still be sending emails—but to different people than before.
Why it’s very likely in your case:
- It exactly explains “worked for a long time, then stopped,” with no infrastructure change: all it takes is adding/removing admins or touching one field.
- The current docs clearly state this default behavior for both Gating Group Collections and per-repo gating: “by default, emails are sent to the first 5 admins… you can also set a different email address in the Notifications email field.” (Hugging Face)
What to do:
-
For a few key gated repos/collections, check:
- Manual approval is enabled,
- Notification frequency is set to daily/real-time,
- Notifications email is either correctly set to your admin alias or left blank intentionally. (Hugging Face)
-
List org admins and see who the first 5 are. If you rely on defaults, your observed recipient may simply no longer be in that top 5.
3. Gating mode or notification settings changed on some repos/collections
What it is:
A repo or Gating Group Collection was switched between Manual and Automatic approval, or its Notification frequency / Notifications email settings were changed inadvertently.
- Manual → you get access-request lists and notification options.
- Automatic → users are auto-approved; pending list is empty; email expectations change. (Hugging Face)
Why it’s plausible:
- If someone changed approval mode (e.g., to “automatic for now”) and later flipped it back, they may not have restored Notification frequency or Notifications email properly.
- If you are using Gating Group Collections, configuring gating there might override or effectively replace previous per-repo behavior. (Hugging Face)
What to do:
4. User-level notification preferences or unsubscribes
What it is:
The HF user account tied to your admin mailbox changed its notifications settings or clicked “unsubscribe” in a past email, turning off that email category.
- HF docs: “You’ll get new notifications by email and directly on the website, you can change this in your notifications settings.” (Hugging Face)
Why it’s somewhat less likely than 1–3:
- It requires a deliberate user action (or confusion) in that account’s settings.
- It doesn’t explain missing emails if you now use a generic alias that isn’t one user’s primary address.
What to do:
- Log in as the admin user that used to get emails.
- Open notification settings and ensure email is still enabled for repo/org activity. (Hugging Face)
5. Hub-side bug or provider suppression specific to your org/addresses
What it is:
- A genuine Hub/backend bug where gated-request emails are not queued/sent, or
- HF’s email provider suppressed your address/domain at their side (blocklist), not just at your mail server.
We know from public reports:
- Some users hit “Not Receiving Identity Verification Link via Email” for HF verification flows; maintainers ask them to contact
[email protected], then treat it as a bug. (GitHub)
- Confirmation-email threads show specific addresses being blocked by HF’s provider and manually unblocked by staff. (Hugging Face Forums)
Why it’s last (but real):
- First, you must rule out 1–4 with tests: especially sending notifications to a Gmail test address.
- If even Gmail gets nothing while requests clearly exist and config is correct, then a Hub-side or provider-side issue is very plausible.
What to do if you reach this point:
One-line recap (ordered)
- Email filtering/blocking on your side (spam, gateway, DMARC, provider blocklist).
- Recipient logic change (first-5-admins rule or Notifications email changed).
- Gating/notification setting changes (manual vs automatic, frequency, collection config).
- User notification preferences / unsubscribe (email channel turned off for that account).
- Hub-side bug or HF-provider suppression for your org/address (after 1–4 are ruled out with tests).