Gated Model Request Emails Not Being Sent

🤗Hub
2

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:

  • On several affected repos/collections, explicitly confirm:

    • Mode = Manual / Manual review,
    • Notification frequency set (not left unset),
    • Notifications email correctly filled,
    • Settings are consistent across repos, not mixed.

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:

  • Collect:

    • Org name,
    • Example gated repos/collections,
    • Timeline of last working email,
    • Evidence of recent requests (e.g., via list_pending_access_requests). (Hugging Face)

  • Open a ticket to [email protected] (and/or your Enterprise support channel), explaining that:

    • Config matches the docs,
    • Requests exist,
    • Cross-domain tests fail,
    • And your mail logs show no attempts.

One-line recap (ordered)

  1. Email filtering/blocking on your side (spam, gateway, DMARC, provider blocklist).
  2. Recipient logic change (first-5-admins rule or Notifications email changed).
  3. Gating/notification setting changes (manual vs automatic, frequency, collection config).
  4. User notification preferences / unsubscribe (email channel turned off for that account).
  5. Hub-side bug or HF-provider suppression for your org/address (after 1–4 are ruled out with tests).