Microsoft 365 Blocking Outgoing Email: Fix a Restricted Sender

What the bounce means and who can fix it

The bounce, known as an NDR (non-delivery report), reads: Your message couldn't be delivered because you weren't recognized as a valid sender. It ends with Remote Server returned 550 5.1.8 Access denied, bad outbound sender. That wording is Microsoft telling you the mailbox has been put on a restricted list. The person can still receive mail, which is why this often goes unnoticed until someone asks why a reply never came.

Microsoft 365 applies the restriction automatically when a mailbox goes over the service's sending limits or the limits in an outbound spam policy, or when its outbound mail looks like spam. Microsoft does not publish the spam-related thresholds. It does say they are high enough that an average business user should never reach them. Our judgement: if an ordinary employee trips this, treat the account as compromised until the evidence says otherwise.

Only an administrator can lift the restriction. By default the alert policy User restricted from sending email emails the Global Administrators when it happens, so your admin may already have a message about it. If you are the affected user, send the full bounce text to your administrator and, ideally, change nothing else. If you are the administrator, the rest of this article is for you.

Check it really is a sender restriction

A few other problems look similar from the user's chair but have different fixes. It is worth thirty seconds to rule them out before you start changing anything.

• 550 5.7.233 means the whole organisation has used up its daily limit for external recipients, so everyone is affected when sending outside. That is a tenant limit, not a restricted user, and unblocking one person will not help.
• Mail that is merely slow, with no bounce, can be the message rate limit of 30 messages per minute per mailbox. Excess messages queue and go out over the following minutes.
• If your outbound spam policy is set to Restrict the user from sending mail until the following day, the user cannot send again until the next day, based on UTC time. The Restrict the user from sending mail action is the one that adds the user to the Restricted entities list and keeps them there until an admin removes them.

1. Ask the user for the complete bounce message and look for 550 5.1.8 Access denied, bad outbound sender. Anyone can do this.
2. As an administrator, open https://security.microsoft.com/restrictedentities and find the user. Their Entity value should be Mailbox. Viewing needs a read-only role such as Global Reader or Security Reader; removing a user needs more, covered below.
3. If you prefer PowerShell, connect to Exchange Online PowerShell and list restricted senders. This only reads. A hosted mailbox is identified by its UPN (user principal name), which is usually, but not always, the same as the email address.
   powershellCopy

   Connect-ExchangeOnline

   powershellCopy

   Get-BlockedSenderAddress

Work out why before you unblock

Unblocking is quick. The expensive mistake is doing it while an attacker still holds the keys, because you have just handed them back a working mail server. Microsoft's own instructions say to follow the compromised-account steps before removing a user from the list. For the outbound spam policy action that blocks until an admin steps in, Microsoft also notes that the user will not be restricted again that day once removed, so an early unblock leaves no safety net for the rest of the day.

Signs of compromise that Microsoft lists include inbox rules that forward mail to unknown addresses or move messages to Notes, Junk Email or RSS Subscriptions, odd messages in Sent Items or Deleted Items, recently added external forwarding, and unexplained password changes or lockouts. Sign-in logs in the Microsoft Entra admin centre (IP address, location, time and success or failure) and message trace in the Defender portal show what was actually sent and from where.

The innocent explanation is real too. Someone may have run a mail-merge or newsletter from their own mailbox, or an application, scanner or script may be authenticating as that user. Microsoft is explicit that bulk mailing through Microsoft 365 is not a supported use and is permitted only on a best-effort basis. For reference, Microsoft publishes these per-user limits: 10,000 recipients in a rolling 24 hours, 30 messages per minute, and 500 recipients per message by default. If the evidence points to a legitimate send, you can skip the account-security steps but should still fix the sending method (see the last section).

Secure the account

Do this when the evidence suggests compromise, or when you cannot rule it out. Two of these actions are disruptive: the user is locked out or signed out everywhere, so tell them by phone or in person. Microsoft specifically warns against sending a new password by email, because the attacker may be reading that mailbox. You need an account that can reset passwords and manage the user in Microsoft Entra ID for the first two steps, and Exchange Online PowerShell access for the fourth.

1. Cut off the attacker. Microsoft's preferred option is to disable the user account while you investigate; if you cannot, reset the password to a strong, unique one. The user cannot use any Microsoft 365 service until the account is re-enabled. If the account syncs from on-premises Active Directory, reset the password there. If it is federated, change it in the on-premises environment. App passwords are not revoked by a password reset, so have the user delete and recreate them.
2. Revoke the active sign-in sessions so tokens the attacker already holds stop working. This signs the genuine user out on every device, and they will need to sign in again. It requires the Microsoft Graph PowerShell modules Microsoft.Graph.Authentication and Microsoft.Graph.Users.Actions, and replaces YOUR_USER_UPN with the user's UPN.
   powershellCopy

   Connect-MgGraph -Scopes User.RevokeSessions.All

   powershellCopy

   Revoke-MgUserSignInSession -UserId YOUR_USER_UPN

3. Review what an attacker would leave behind in Entra ID: unfamiliar MFA methods and registered devices, applications the user has consented to, and any administrative roles the account should not hold. Remove anything you do not recognise.
4. Check for mail forwarding. These two commands only read. Replace YOUR_USER_UPN with the user's UPN. The first shows mailbox-level forwarding (a value in ForwardingSmtpAddress means mail is going to an external address). The second lists every inbox rule, including hidden ones, that redirects or forwards mail. Note what you find before deleting anything, as it is useful evidence of how far the attacker got.
   powershellCopy

   Get-Mailbox -Identity YOUR_USER_UPN | Format-List Forwarding*Address,DeliverTo*

   powershellCopy

   Get-InboxRule -Mailbox YOUR_USER_UPN -IncludeHidden | Format-List Name,Enabled,RedirectTo,Forward*,Identity

5. Make sure the account is protected by MFA (multifactor authentication) before it goes back into use. The UK National Cyber Security Centre also recommends 2-step verification on email accounts. A password alone is what got you here.

Remove the restriction in the Defender portal

This removes the sending block for that one mailbox. It needs membership of the Organization Management or Security Administrator role groups in Exchange Online, or the Entra roles Security Administrator or Global Administrator, or the Core Security settings (manage) permission under Defender unified RBAC if that is active in your tenant. If you can see the page but there is no Unblock action, your role is probably read-only.

1. Go to https://security.microsoft.com/restrictedentities, or navigate to Email & collaboration > Review > Restricted entities.
2. Select the check box next to the user, then select Unblock.
3. In the Unblock user flyout, read the Overview page, including the Recommendations section, and confirm you have dealt with them. Select Next.
4. On the Unblock user page, use the Enable MFA and Reset the user's password links if you have not already done those things. Select Submit.
5. In the warning dialog that confirms you are about to remove the sending restriction, select Yes only if you are satisfied the account is secured. Microsoft says restrictions are normally removed within one hour, and that transient issues can stretch that, but the total should not exceed 24 hours. There is nothing to do while you wait except resist the urge to unblock again.

Removing the restriction with PowerShell instead

The same removal can be done from Exchange Online PowerShell with the same permissions and the same wait afterwards. Replace YOUR_USER_UPN with the UPN of the hosted mailbox. For a sender outside Exchange Online, such as an on-premises sender, use the SMTP address they send from.

Remove-BlockedSenderAddress -SenderAddress YOUR_USER_UPN

Check sending works again

Once an hour has passed, ask the user to send a short test message to a colleague and to an external address you control. A successful result is delivery with no 5.1.8 bounce. In the Defender portal, the user should no longer appear on the Restricted entities page, and Get-BlockedSenderAddress should not list their UPN.

If it still fails after 24 hours with the user no longer on the list, that goes beyond what Microsoft's documentation says to expect, and the next stop is a support request to Microsoft. For a few days afterwards, keep an eye on message trace and sign-in logs for the account, because a second restriction is the clearest sign that something was missed.

If it keeps happening

Most repeat cases fall into a few patterns.

• The user is restricted again soon after unblocking: assume the compromise is not closed. Look again for forwarding and inbox rules, consented applications, extra MFA methods and sign-ins from unfamiliar places, and keep the account disabled while you do.
• The sending is legitimate, such as a newsletter or invoice run: Microsoft recommends a non-Microsoft bulk email provider or your own mail servers for mass mailings, ideally from a subdomain with SPF, DKIM and DMARC set up. Applications and devices that send routine mail should use SMTP relay through a connector rather than a person's mailbox.
• Everyone is failing to send externally with 550 5.7.233: you have hit the tenant external recipient rate limit. The Tenant Outbound External Recipients report in the Exchange admin centre shows usage against it.
• You set low per-hour or daily limits in an outbound spam policy and users trip them in normal work: review the External message limit, Internal message limit and Daily message limit values in the policy before raising anything, and keep the action as restrictive as you can justify.