notification emails stopped: user-side checklist
A user-side checklist for notification emails that stopped arriving: spam and filters, in-app settings, unsubscribe state, and corporate quarantine. Use when users report missing alerts, when notification tickets stall, or when writing a notification-help macro. Not for mail-server deliverability engineering or for push-notification debugging.
TL;DR
When notification emails stop, the break is almost always at the mailbox, not in your app: a filter, an unsubscribe, a changed address, or a corporate quarantine. Work the checklist from the user's side inward, spam and rules first, app settings second, IT allowlist last. Only escalate to deliverability tooling after the user-side checks come back clean.
The query
notification emails stopped: user-side checklistUse this when
- A user says they stopped getting notification emails
- Alerts worked before and quietly stopped
- You need to rule out user-side causes before escalating
- You are writing a macro for missing-notification tickets
Not for
- Mail-server or SPF/DKIM deliverability engineering
- Push notification or in-app notification debugging
- Designing notification preferences
- Bulk email campaign deliverability
Steps
1. Check spam, junk, and mailbox rules
Have the user search all mail (not just the inbox) for your sender name, then check spam and any filters or rules that move mail to folders. Rules are the silent killer: the email arrives fine and gets filed somewhere the user never looks.
Expected output: the emails found in spam or a folder, or rules ruled out.
2. Check notification settings in the app
Settings change without users noticing: a plan change, a project leave-and-rejoin, or an admin toggling defaults. Walk them to the notification settings (both global and per-project) and confirm the relevant toggles are on.
Expected output: settings confirmed on, or the toggled-off setting found and fixed.
3. Check unsubscribe and email address
One accidental unsubscribe click, or a footer link hit on a shared inbox, silences everything. Check their subscription state in your admin panel. While there, verify the address on file, typos and old addresses are embarrassingly common.
Expected output: subscription active on the correct address, or the unsubscribe found.
4. Check digest and quiet-hours settings
Some users didnt lose notifications, they got batched: digest mode, do-not-disturb schedules, or per-thread mute settings collect alerts into summaries. Ask whether they get anything at all, versus getting them late or bundled.
Expected output: batching settings identified, or confirmed real-time delivery is expected.
5. Check corporate quarantine and allowlist
On work addresses, IT mail gateways quarantine automated mail without telling the user. If steps 1 to 4 are clean, ask the user (or their IT) to check the quarantine and allowlist your sending domain. This resolves most remaining cases.
Expected output: the gateway rule found, or the allowlist request sent to IT.
Ready-to-use reply
Let us run the usual checklist. Can you search all your mail for
[product name] (including spam), and check for any rules moving those
emails to a folder? Then in [product], open Settings, then Notifications and
confirm the alerts you want are switched on. If both look right, tell me
and I will check your subscription state and sending logs from my side.Variant phrasings
not receiving email notifications anymore
Steps 1 through 3. The big three cover nearly every case.
alerts stopped coming to my inbox
Steps 1 and 5. Sudden stops on work addresses point at filters or quarantine.
missing notification emails
Step 4 first. Ask whether they mean missing entirely or just delayed, digests confuse the report.
Why it happens
A notification email crosses a half-dozen independent systems: your app, your mail provider, spam filters, user rules, corporate gateways, and the inbox itself. Each one can silently swallow or reroute the message, and none of them tell the user. That is why the checklist starts at the mailbox and works backward: the failure is usually closest to the user.
Edge cases
- Shared inboxes: a colleague's rule or unsubscribe affects everyone on the address. Check who else touches it.
- The user changed their email: notifications keep going to the old address until the profile is updated. Verify, dont assume.
- Mailbox full or disabled: bouncing addresses get suppressed by mail providers. Check your suppression list.
- Only some notification types missing: per-event toggles, not a delivery problem. Compare a working type against a missing one.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_PC3PHSeDm9RceaIwOtaiKw
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.