# Gated Model Request Emails Not Being Sent

**URL:** <https://discuss.huggingface.co/t/gated-model-request-emails-not-being-sent/170510>\
**Category:** 🤗Hub\
**Created:** [November 16, 2025, 3:39am UTC](https://discuss.huggingface.co/t/gated-model-request-emails-not-being-sent/170510 "2025-11-16T03:39:33Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [November 16, 2025, 11:12am UTC](https://discuss.huggingface.co/t/gated-model-request-emails-not-being-sent/170510/2 "2025-11-16T11:12:30Z")

</div>

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](https://discuss.huggingface.co/t/i-can-t-get-email-confirmation-link/13776 "I can't get Email confirmation link - Site Feedback"))
- HF staff explicitly mention some addresses ending up on their provider’s **blocklist** and needing manual unblocking. ([Hugging Face Forums](https://discuss.huggingface.co/t/i-can-t-get-email-confirmation-link/13776?page=2 "I can't get Email confirmation link - Page 2 - Site Feedback"))
- 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](https://huggingface.co/docs/hub/en/enterprise-hub-gating-group-collections "Gating Group Collections"))

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](https://huggingface.co/docs/hub/en/enterprise-hub-gating-group-collections "Gating Group Collections"))

**What to do:**

- For a few key gated repos/collections, check:

- 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](https://huggingface.co/docs/hub/en/models-gated "Gated models"))

**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](https://huggingface.co/docs/hub/en/enterprise-hub-gating-group-collections "Gating Group Collections"))

**What to do:**

- On several affected repos/collections, explicitly confirm:

* * *

## 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](https://huggingface.co/docs/hub/en/notifications "Notifications"))

**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](https://huggingface.co/docs/hub/en/notifications "Notifications"))

* * *

## 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 `website@huggingface.co`, then treat it as a bug. ([GitHub](https://github.com/huggingface/transformers/issues/34428 "Not Receiving Identity Verification Link via Email #34428"))
- Confirmation-email threads show specific addresses being blocked by HF’s provider and manually unblocked by staff. ([Hugging Face Forums](https://discuss.huggingface.co/t/i-can-t-get-email-confirmation-link/13776?page=2 "I can't get Email confirmation link - Page 2 - Site Feedback"))

**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:

- Open a ticket to **[website@huggingface.co](mailto:website@huggingface.co)** (and/or your Enterprise support channel), explaining that:

* * *

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

---

_[View the full topic](https://discuss.huggingface.co/t/gated-model-request-emails-not-being-sent/170510)._