550 5.1.90 and 550 5.7.232: Exchange Online sending limits have been hit

Fix it now

550 5.1.90 means the sender has reached the daily limit for message recipients. 550 5.7.232 means a trial tenant has passed its daily limit for external recipients. These are enforced caps, not faults, and the honest fix is usually to change how the mail is sent rather than to ask for a bigger number.

Get-Mailbox app@contoso.com | Select RecipientLimits
Get-MessageTrace -SenderAddress app@contoso.com -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) | Measure-Object

1. Identify the sender and whether it is a person or an application submitting over SMTP. The remedy differs.
2. Check the Restricted entities page in the Microsoft Defender portal. If the account is listed, an outbound spam policy has restricted it and that is a separate, more serious problem.
3. If the account was restricted, investigate before releasing it. A mailbox that suddenly sends thousands of messages is more often compromised than busy – reset credentials and revoke sessions.
4. For application mail, spread submissions out rather than sending in bursts: the message rate limit is per minute, the recipient rate limit is a 24-hour sliding window.
5. For genuine bulk mail, move it off Exchange Online to a service built for it. That is the only fix that stays fixed.

The daily recipient limit is a sliding window, not a midnight reset. The mailbox can send again once the 24-hour total drops below the cap.

If mail is flowing again you can stop here. If not, the next section explains which cap you hit and which of these codes is not a sending limit at all.

Why it happens

Exchange Online applies caps to how many recipients a mailbox can address in a day, how quickly it can submit, and how many external recipients a whole tenant can reach. They exist to keep the platform out of the bulk mail business and to contain compromised accounts, and they are enforced without warning once you cross the line.

Three limits do most of the work. The recipient rate limit is 10,000 recipients per day, measured over a 24-hour sliding window – the mailbox cannot send again until the trailing total drops below the cap. The message rate limit is 30 messages per minute, with excess submissions throttled and carried into following minutes. The per-message recipient limit defaults to 500 and is customisable from 1 to 1,000 in the Exchange admin centre or PowerShell. Only that last one can be changed.

Above the mailbox sits the tenant external recipient rate limit, and this is where the codes diverge. 550 5.7.232 is the trial-tenant form: a trial has exceeded its daily limit for sending to external recipients. 550 5.7.233 is the same limit applied to a paid tenant, and when it trips, all users sending externally are blocked, not just the one who caused it. 550 5.7.236 is narrower still: no more than 100 external recipients in a 24-hour rolling window from the tenant’s own onmicrosoft.com domain, which Microsoft describes as being for testing rather than for real mail.

Two of the codes in this article are not sending limits. 432 4.3.2 is “STOREDRV.Deliver; recipient thread limit exceeded”: the recipient’s mailbox is being throttled for receiving too many messages too quickly. Slowing down the sender helps, but the limit belongs to the other end. 450 4.4.244 applies only to High Volume Email submissions, where many messages were sent to a small number of recipients in a short window.

Full reference

The limits, and which ones move

Which code is which

Counting recipients the way the service counts them

A distribution group counts every member it expands to. A message to a 400-person group is 400 recipients, not one, and a daily report to three such groups eats an eighth of the allowance before anyone has written an email. The same applies to nested groups: what matters is the expanded set, not the address you typed.

This is why the recipient rate limit catches automated senders far more often than people. A human who sends 200 messages a day is nowhere near it. An application that mails a 2,000-member list five times a day is over it by lunchtime, every day, and no configuration change inside Exchange Online alters that arithmetic.

Application mail that keeps working

• Space submissions so the per-minute rate stays under 30. Excess is throttled and carried forward, so a burst does not fail outright but does queue behind itself.
• Give the application its own mailbox rather than borrowing a person’s, so a throttle does not take a member of staff offline with it.
• Keep Sent Items under control on the sending mailbox: SMTP AUTH submissions are stored there and a full mailbox blocks submission entirely.
• Set the per-message recipient limit deliberately for that mailbox rather than leaving it at the default and discovering it at 500.

When it is genuinely bulk mail

There is a point at which the answer is not Exchange Online. Newsletters, marketing campaigns, transactional notification streams and anything that needs bounce handling, list management or delivery analytics belong on a service built for them. Microsoft’s own High Volume Email is aimed at internal bulk mail and comes with its own limits and its own codes, including 450 4.4.244. Moving that traffic off a user mailbox also stops one campaign taking the whole tenant’s external sending down with it.

Every code this article covers

Confirm the fix worked

1. A message trace over the last 24 hours shows the sender’s recipient count below 10,000.
2. The account no longer appears on the Restricted entities page in the Microsoft Defender portal.
3. A test message to an external recipient is delivered.
4. For an application sender, the submission rate stays under 30 messages a minute across a full run.
5. Sending from a custom domain rather than onmicrosoft.com, if 5.7.236 was the code.

Questions people ask about this