# Gated Model Request Emails Not Being Sent **URL:** **Author:** ![shahlab](https://avatars.discourse-cdn.com/v4/letter/s/71e660/32.png) [@shahlab](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fshahlab)%5C **Post date:** [November 16, 2025, 3:39am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fgated-model-request-emails-not-being-sent%2F170510%2F1 "2025-11-16T03:39:33Z") We have an admin email associated with our Hugging Face organization and have notifications configured to be sent daily for **gated model access requests**. However, for the past several months we haven’t received any of these email notifications. This has been frustrating for both our users and our administrators, since we have no way of knowing when new gated access requests come in. Could you please advise on how to troubleshoot or fix this issue? Thank you! ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C **Post date:** [November 16, 2025, 11:12am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fgated-model-request-emails-not-being-sent%2F170510%2F2 "2025-11-16T11:12:30Z")
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](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fi-can-t-get-email-confirmation-link%2F13776 "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](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fi-can-t-get-email-confirmation-link%2F13776%3Fpage%3D2 "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](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fi-can-t-get-email-confirmation-link%2F13776%3Fpage%3D2 "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).