550 5.2.1: the mailbox is disabled, blocked or has lost its licence

Fix it now

The recipient resolved but the mailbox behind it will not take the message. RFC 3463 defines this class as a mailbox that exists but is not accepting messages, permanently if it will never be re-enabled and transiently if it is only switched off for now. In practice there are three states to tell apart.

Get-Mailbox user@contoso.com | Format-List Name,RecipientTypeDetails,PrimarySmtpAddress,ExchangeUserAccountControl

Get-MessageTrackingLog -Recipients user@contoso.com -Start (Get-Date).AddHours(-2) | Format-Table Timestamp,EventId,Source,Recipients

1. If Get-Mailbox cannot find the identity at all, the mailbox is disabled or deleted rather than merely blocked – go looking for it as a disconnected or soft-deleted mailbox.
2. If it returns a mailbox and ExchangeUserAccountControl reports the account as disabled, the directory account was switched off with the mailbox left in place.
3. In Microsoft 365, open the admin centre, go to Users then Active users, select the person and check both the sign-in status and the Licences and apps tab.
4. If the licence is missing, reassign one. Microsoft holds the Exchange Online data for 30 days after a licence is removed, and within that window the same mailbox comes back with its contents.
5. Send one test message and confirm a DELIVER event for that recipient in the tracking log.

550 5.7.13 is not part of this. Microsoft publishes it as Sender was not authenticated for public folder – the recipient is a public folder set to reject external senders – so it points at the recipient’s configuration, not the sender’s account.

If the mailbox now accepts mail, you are done. If it is a licence or a subscription that lapsed, the next section covers what is recoverable and for how long.

Why it happens

A mailbox is two things joined together: a directory object that owns the address, and a store that holds the items. This class of failure is what you get when the first half is intact and the second is not available. The address resolves, the categoriser hands the message to the store, and the store declines. Nothing is lost in transit and nothing about the sending path is at fault.

Microsoft does not publish an Exchange-specific gloss for 5.2.1 in its Exchange Online non-delivery report reference, so treat the RFC definition as the reliable one: the mailbox exists but is not accepting messages, and the code can be permanent or transient depending on whether it will ever be re-enabled. The neighbouring 5.2.0 is the same family with nothing more specific to say – the mailbox exists and something about it caused the report.

On premises, the commonest cause is an Active Directory account disabled while the mailbox was left in place, which is exactly what happens when someone leaves and HR disables the account before IT has decided what to do with the mail. In Microsoft 365 the commonest cause is a licence: removing one leaves the mailbox unlicensed and undeliverable, and the clock starts on a 30-day retention window after which the data is deleted and cannot be recovered.

The fourth item people arrive with, Event ID 9548, is worth a word of caution. Microsoft publishes no current description for it, so do not act on a remembered meaning. Read the event’s own text in Event Viewer, which names the objects involved, and confirm the state with Get-Mailbox and Get-User before you change anything.

Full reference

Telling the states apart

What each code in this group actually says

Disable-Mailbox and Remove-Mailbox both detach live user data, and Remove-Mailbox can delete the account with it. Never run either to clear a bounce. Establish what state the mailbox is in first, and export or back up before you change anything holding mail.

Licensing, in the detail that decides the outcome

• Removing a licence holds the Exchange Online data for 30 days. After that it is deleted and cannot be recovered, though content matching retention labels is retained for discovery.
• When the licence is removed the mailbox is no longer searchable with Content Search or eDiscovery, so the discovery route disappears before the data does.
• A shared mailbox stores up to 50 GB without a licence. Above that it needs an Exchange Online Plan 2 licence, which raises the cap to 100 GB.
• A shared mailbox on litigation hold, or with in-place archiving enabled, needs Exchange Online Plan 2, or Plan 1 with the Exchange Online Archiving add-on.
• To access a shared mailbox a user needs their own licensed Exchange Online mailbox; the shared mailbox itself does not need one for ordinary use.

That last group is the reason a shared mailbox that has worked for two years suddenly starts refusing mail. Nobody changed anything: it crossed 50 GB, or somebody put it on hold as part of an unrelated matter.

Where to look when none of the three fits

• Check whether the recipient is a mail user or a mail contact pointing at an external address that is itself failing.
• Check delivery restrictions on the recipient, which produce their own codes rather than this one but look identical to the sender.
• In a hybrid organisation, confirm the recipient object exists on the side that actually holds the mailbox and that the remote routing address is correct.
• Confirm the sender is not being refused by a rule rather than by the mailbox – the tracking log shows which.
• For a linked mailbox, confirm the master account association still points at an enabled account in the accounts forest.

Every code this article covers

Confirm the fix worked

1. Get-Mailbox user@contoso.com returns a UserMailbox with the expected primary address.
2. The admin centre shows an assigned licence that includes Exchange Online, and sign-in is not blocked.
3. A test message appears with a DELIVER event in Get-MessageTrackingLog for that recipient.
4. The affected user can both receive and send.
5. For a public folder recipient, a message from the external address that was refused is now accepted.

Questions people ask about this