Enhanced Status Code 5.2.121: Recipient Hourly Receive Limit From Sender Exceeded
Enhanced Status Code 5.2.121 means “Recipient Hourly Receive Limit From Sender Exceeded.” You have sent one recipient more mail in an hour than Microsoft allows from a single sender. The limit is per sender-recipient pair, so it does not affect anyone else you write to.
550 5.2.121 Recipient's per hour message receive limit from specific sender exceededWhat does 5.2.121 mean?
Microsoft returns 5.2.121 when a recipient's per hour message receive limit from a specific sender has been exceeded. The limit is scoped to the pair: it counts how much mail this particular sender has delivered to this particular recipient within the hour, and it does not restrict either party's other correspondence.
As with the other Microsoft quota codes, the 5.x numbering is misleading. The condition clears within the hour, so a message that fails now will be accepted shortly. Suppressing the recipient would be exactly the wrong response, since the address is valid and the restriction belongs to a rate rather than to a delivery problem.
The pattern that produces it is nearly always automated: a monitoring system sending an alert per event to one address, a ticketing integration echoing every update, or a retry loop resending the same notification. The fix is usually to batch or digest rather than to send per event, which is better for the recipient as well.
How 5.2.121 plays out
5.2.121 replyWhere 5.2.121 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.2.121 is | ✓ this code |
What each provider means by 5.2.121
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.2.121
- An automated system sends many notifications per hour to a single address
- A monitoring or alerting integration emits one message per event
- A retry loop is resending the same message repeatedly
- A ticketing system echoes every update to the same recipient
- A test or development environment is pointed at a real mailbox
- Several systems independently notify the same shared address
How to fix 5.2.121
- Do not suppress the recipient, since the address is valid and the limit is a rate
- Batch or digest notifications rather than sending one message per event
- Add rate limiting on your own side so you never approach the receiver limit
- Check for retry loops resending identical messages
- Point development and test environments at a sink rather than a real mailbox
- Spread alerts for one recipient across a longer window