How long does it take to unblock a user after 5.1.8?

Microsoft states that under most circumstances all restrictions are removed within one hour after an admin unblocks the user on the Restricted entities page. Transient issues can make it take longer, but the total wait should be no longer than 24 hours.

Can the blocked user still receive email?

Yes. A user on the Restricted entities page is blocked only from sending. Incoming mail continues to be delivered to the mailbox, which also means an attacker with access can still read it until you secure the account.

Who can remove a user from the Restricted entities page?

Members of the Organization Management or Security Administrator role groups in Exchange Online, or the Security Administrator or Global Administrator roles in Microsoft Entra ID. If Defender XDR unified RBAC is active for Defender for Office 365, the Core Security settings (manage) permission is required in the portal.

Is 550 5.1.8 the same as 550 5.7.233?

No. 5.1.8 blocks one user or connector that exceeded sending limits or sent suspected spam, and an admin unblocks it. 5.7.233 means the whole tenant exceeded its daily external recipient quota, affects every sender for external mail, and clears automatically as the 24-hour window moves.

Fix 550 5.1.8 Bad Outbound Sender in Exchange Online

550 5.1.8 Access denied, bad outbound sender means Exchange Online has restricted the user from sending because the account exceeded outbound sending limits or sent mail that looked like spam, usually because the account is compromised. To fix it, first secure the account: disable it or reset the password, revoke sessions, and remove malicious forwarding and inbox rules. Then remove the user from Restricted entities in the Microsoft Defender portal or with Remove-BlockedSenderAddress. Restrictions are usually lifted within one hour.

Who this is for and what you will have

This guide is for Microsoft 365 administrators and help desk staff who get a report that a user's messages all bounce with 5.1.8. At the end you will have:

Confirmed that 5.1.8 is the cause, rather than a tenant-wide limit or a recipient problem.
Secured the account so the spam doesn't start again as soon as you unblock it.
Removed the restriction in the portal or with PowerShell, and verified that the user can send.
Checked the alert and outbound spam policy settings that decide how future incidents are handled.

What the error means

The user receives a non-delivery report with this text:

Your message couldn't be delivered because you weren't recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it's no longer allowed to send email. Contact your email admin for assistance. Remote Server returned '550 5.1.8 Access denied, bad outbound sender.'

When a user exceeds the service's outbound sending limits or the limits in an outbound spam policy, three things happen:

The user can't send email but can still receive it.
The user is added to the Restricted entities page in the Microsoft Defender portal. A restricted entity can be a user account or a connector.
The default alert policy User restricted from sending email notifies admins.

Microsoft treats exceeding outbound limits as an indicator of compromise, and its procedures assume you'll investigate the account before you unblock it. A legitimate bulk send can also trigger the block. In that case, the long-term fix is to move that sending to a service designed for it.

Rule out look-alike errors

Error	Scope	Cause	How it clears
`550 5.1.8 Access denied, bad outbound sender`	One user (or connector)	Outbound spam detection or sending limits exceeded	Admin removes the user from Restricted entities
`550 5.7.233`	Whole tenant, external recipients only	Tenant External Recipient Rate Limit exceeded	Automatically as the 24-hour window moves
`550 5.7.236`	Whole tenant, mail from `onmicrosoft.com`	More than 100 external recipients from the default domain in 24 hours	Automatically; move senders to a custom domain

If several users are affected at once and only external mail bounces, the cause is probably the tenant quota, covered in Tenant External Recipient Rate Limit (TERRL).

Prerequisites

You need one of the following:

Exchange Online role groups: Organization Management or Security Administrator to remove users. Global Reader, Security Reader or View-Only Organization Management give read-only access.
Microsoft Entra roles: Security Administrator or Global Administrator to remove users. Use Global Administrator only when no other role is available.
Defender XDR unified RBAC (if it's active for Defender for Office 365): Authorization and settings/Security settings/Core Security settings (manage). This applies to the portal only, not to PowerShell.

To secure the account you also need permissions in Microsoft Entra ID to disable users and revoke sessions, and the Exchange Online and Microsoft Graph PowerShell modules if you script the steps.

Step 1: Confirm the user is restricted

In the Microsoft Defender portal, go to Email & collaboration > Review > Restricted entities (https://security.microsoft.com/restrictedentities). Find the user. The Entity value for a user is Mailbox.

Or in Exchange Online PowerShell:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
 
# All restricted senders
Get-BlockedSenderAddress
 
# Details for one user (use the UPN for a cloud mailbox)
Get-BlockedSenderAddress -SenderAddress jason@contoso.com | Format-List

For a cloud mailbox the identifier is the user principal name, which doesn't have to match the primary SMTP address. For a non-hosted sender, such as an on-premises sender, it's the SMTP address that the sender uses.

Step 2: Secure the account before you unblock it

If you unblock a compromised account, the attacker can start sending again straight away. Microsoft's procedure for a compromised mailbox covers the following steps.

Disable the account and reset credentials

Connect-MgGraph -Scopes "User.ReadWrite.All"
$user = Get-MgUser -Search UserPrincipalName:'jason@contoso.com' -ConsistencyLevel Eventual
Update-MgUser -UserId $user.Id -AccountEnabled $false

If you can't disable the account, reset the password and don't send the new password to the user by email. For accounts synced from Active Directory, reset the password in Active Directory twice. Existing app passwords aren't revoked by a reset, so the user must delete them and create new ones.

Revoke sessions

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId jason@contoso.com

Remove persistence

MFA methods: remove any authentication methods or devices the user doesn't recognize.
Consented applications: review and revoke apps the user granted access to.
Admin roles: remove any role assignments that shouldn't be there.
Mailbox forwarding and inbox rules:

Get-Mailbox -Identity jason@contoso.com | Format-List Forwarding*Address,DeliverTo*
Get-InboxRule -Mailbox jason@contoso.com -IncludeHidden | Format-List Name,Enabled,RedirectTo,Forward*,Identity

A value in ForwardingSmtpAddress sends mail to an external address. Rules with RedirectTo, ForwardTo or ForwardAsAttachmentTo targets you don't recognize should be removed.

Investigate

Review the Microsoft Entra sign-in logs (IP address, location, time, success or failure), the audit log in the Defender portal from just before the suspicious activity, and message trace for what the account sent. Turn on multifactor authentication for the account before you re-enable it. The Zero Trust remote access architecture guide covers the wider controls that make this kind of compromise less likely.

If the investigation shows a legitimate bulk send instead, note what was sent and plan to move it (see Step 5).

Step 3: Remove the user from Restricted entities

In the Microsoft Defender portal

Go to Email & collaboration > Review > Restricted entities.
Select the check box for the user, then select Unblock.
In the Unblock user flyout, read the Overview page and work through the Recommendations section. Select Next.
On the Unblock user page, use the Multi-factor authentication and Change password links if you haven't already enabled MFA and reset the password. Select Submit.
Confirm the warning dialog with Yes.

In Exchange Online PowerShell

Remove-BlockedSenderAddress -SenderAddress jason@contoso.com

Re-enable the account in Microsoft Entra ID if you disabled it:

Update-MgUser -UserId $user.Id -AccountEnabled $true

Step 4: Verify

Run Get-BlockedSenderAddress -SenderAddress jason@contoso.com and confirm the user is no longer listed. In the portal, confirm that the user is gone from Restricted entities.
Wait. Microsoft states that restrictions are usually removed within one hour and that the total wait should be no longer than 24 hours.
Ask the user to send a test message to an external address and confirm that no 5.1.8 NDR comes back.
Watch the account's sign-ins and sent mail for the next few days.

Step 5: Check the policies that caused the block

Outbound spam policy action

In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-spam and open the outbound policy that applies to the user. Restriction placed on users who reach the message limit decides what happens next time:

Action	Behavior
Restrict the user from sending mail until the following day (default)	The user can't send until the following day, based on UTC time
Restrict the user from sending mail	The user is added to Restricted entities and can't send until an admin removes them. After removal, the user isn't restricted again that day
No action, alert only	Admins are notified through the Email sending limit exceeded alert

The limits themselves (external and internal recipients per hour, recipients per day) accept 0 to 10,000, where 0 means the service default. Lowering them for shared or service mailboxes contains damage sooner. In PowerShell, review the current values, then use a custom policy with lower limits for a group of high-risk senders (this example follows Microsoft's documented pattern):

Get-HostedOutboundSpamFilterPolicy | Format-List Name,RecipientLimit*,ActionWhenThresholdReached
 
New-HostedOutboundSpamFilterPolicy -Name "Service senders" -RecipientLimitExternalPerHour 400 -RecipientLimitInternalPerHour 800 -RecipientLimitPerDay 800 -ActionWhenThresholdReached BlockUser
New-HostedOutboundSpamFilterRule -Name "Service senders" -HostedOutboundSpamFilterPolicy "Service senders" -FromMemberOf "Service Senders Group"

The same outbound spam policy also controls automatic external forwarding. Set Automatic forwarding rules to Off - Forwarding is disabled unless the business needs it, because attackers commonly use forwarding.

Alert recipients

Go to Email & collaboration > Policies & rules > Alert policy, open User restricted from sending email and confirm that it's on and that the recipients include a mailbox someone monitors. The default recipient is the TenantAdmins group. Alerts depend on audit logging, which is on by default.

Move legitimate volume elsewhere

If a person or application legitimately sends large volumes, Microsoft's guidance is to stop using a user mailbox for it. Use Azure Communication Services Email for external or bulk mail, or High Volume Email for internal notifications. The options are compared in SMTP AUTH vs Direct Send vs relay connector and the internal option is covered in High Volume Email for Microsoft 365.

Troubleshooting

The user still gets 5.1.8 after an hour. Check that the removal succeeded with Get-BlockedSenderAddress. Allow up to 24 hours before you open a support case.
The user is restricted again soon after unblocking. The account is probably still compromised, or the application that triggered the block is still running. Check for remaining sessions, app passwords, consented apps and forwarding rules, and review message trace.
The user isn't on the Restricted entities page. Check the NDR text again: a 5.7.233 or 5.7.236 code points to a tenant-wide limit rather than a restricted user. Also check the outbound spam policy action. With Restrict the user from sending mail until the following day, Microsoft documents that the user can't send until the following day, based on UTC time.
A connector, not a user, is restricted. Restricted entities can include connectors. Microsoft documents that procedure separately in "Remove blocked connectors from the Restricted entities page".
Remove-BlockedSenderAddress fails with an access error. The account running it needs membership in the Organization Management or Security Administrator role group in Exchange Online, or the Security Administrator role in Microsoft Entra ID. Defender XDR unified RBAC permissions apply to the Defender portal only, not to PowerShell.

Fix 550 5.1.8 Access denied, bad outbound sender in Exchange Online