One user reports a flood of identical automated emails from an internal application, hundreds an hour, drowning their real mail. Only this one user is affected.
How do I stop the flood and find why it targets them?
A user is getting emails constantly from an application
Solved Email & Outlook
MS
Michael Scofield October 28, 2020
2 replies
6,940 views
Reviewed by moderators
Two jobs, immediate relief for the drowning user and the root cause so it does not resume and the one user only detail is the diagnostic thread to pull:
Immediate relief, buy the user their inbox back: a mail flow rule or their own filter moving the application's messages, matched by the sender address or subject pattern, into a folder rather than the inbox, stopping the drowning while you find the cause. Not a fix, the flood continues into the folder, but the user works again while you investigate, better than them fighting hundreds an hour in the inbox.
The root cause, why this user: applications flood one user usually because of a loop or a misconfiguration tied to them specifically. A notification loop, the application emailing on an event that its own email triggers, spiraling for one user caught in the cycle. A stuck job or queue, a process retrying a notification for this user's record endlessly. A subscription or alert misconfiguration, this user accidentally subscribed to a high frequency event or set as the recipient for something firing constantly. Or their record in the application in a state that triggers repeated notifications, a workflow stuck on their item.
The diagnosis: read the flood's content and headers, which usually name the triggering event and often the record or process behind it, the messages describing their own cause. Then check the application's logs or admin for that user, the notification settings, subscriptions and any job or workflow referencing them, the one user scope narrowing the search to what is specific about their configuration or data.
The proper fix once found: correct the misconfiguration, break the loop, clear the stuck queue or fix the record state, then remove the temporary filter and confirm normal notification volume resumes. And harden against recurrence, rate limiting on the application's notifications or loop detection, so a future misconfiguration degrades gracefully rather than flooding, the systemic lesson a single user flood teaches about the application's notification design.
The messages named their own trigger, a workflow stuck on the user's record retrying a notification every few seconds. Cleared the stuck workflow and the flood stopped, removed the temporary filter and volume is normal. Proposing rate limiting on the app's notifications so this degrades gracefully next time. Read the headers was the key.