550 5.4.1: Recipient Address Rejected, Access Denied (Microsoft)

A 550 5.4.1 from Microsoft means the receiving Microsoft 365 organization looked up the address you sent to and didn't find it in its directory, so it refused the message at the door. It's not a spam block and has nothing to do with your reputation. Either the address is wrong or no longer exists, or the recipient's Microsoft 365 setup is missing that user. If you've double-checked the address, the fix is on their side.

What the bounce says

Microsoft's documented text is short:

550 5.4.1 Recipient address rejected: Access denied

In real bounces it often carries a suffix, like this one posted to Microsoft Q&A:

550 5.4.1 Recipient address rejected: Access denied. AS(201806281)

You'll usually see the rejecting host as something ending in mail.protection.outlook.com, which tells you the recipient's mail is handled by Microsoft 365.

What it means

The rejection comes from a Microsoft 365 feature called Directory-Based Edge Blocking (DBEB). Microsoft describes it as rejecting "messages for invalid recipients at the service network perimeter." If the address doesn't match any user, group, contact or other mail-enabled object in that organization, the message is blocked "before filtering even occurs."

DBEB is switched on when a domain is set as Authoritative in Exchange Online, meaning Microsoft 365 is the only place mailboxes for that domain live. If a domain is set to Internal relay instead, Microsoft passes unknown recipients on to another mail system, and a truly invalid address would bounce somewhere else with a different code, typically the familiar 550 5.1.1 user unknown.

So, functionally, 5.4.1 is Microsoft 365's version of "no such user." The difference is that it can also fire for users who do exist, when the organization's directory isn't in sync.

Common causes, most likely first

1. The address is wrong. A typo, an old domain, or a person who has left the company and whose mailbox was removed.
2. An old list. On B2B lists, people change jobs constantly. Addresses that worked a year ago now return 5.4.1 or 5.1.1. A lot of them in one send means the list is stale.
3. The recipient's directory is out of sync. In hybrid setups (some mailboxes on-premises, some in Microsoft 365), a user, public folder or dynamic distribution group that exists on-premises might not be known to Exchange Online.
4. A migration in progress. If the domain was switched to Authoritative before every mailbox was moved and replicated, any user not yet in Exchange Online gets 5.4.1. Microsoft's guidance is to leave the domain on Internal relay until all recipients are added.

How to fix it

If you're the sender:

1. Check the address in the bounce character by character, and confirm the domain is current.
2. Try another recipient at the same domain. If they get through, the problem is that one address. If everyone at the domain bounces, it's their configuration.
3. Contact the recipient another way (phone, another address, LinkedIn) and tell them about the bounce. Send their admin the full bounce text; it points them straight at the fix.
4. If you're sending to a list, suppress the address like any other hard bounce. Don't keep retrying it.

Requesting IP delisting at sender.office.com won't help. DBEB is about whether the recipient exists, not about who you are.

If you're the recipient's admin, Microsoft's steps are:

1. Confirm the scope. Check whether mail to other users in the same domain also gets 5.4.1.
2. If the whole domain is affected, resync it. In the Exchange admin center, go to Mail flow > Accepted domains, open the domain, change it from Authoritative to Internal relay, then change it back to Authoritative.
3. If it's one on-premises mailbox in a hybrid setup with directory sync, reset the user's SMTP proxy address: change it to a temporary address, then change it back. Microsoft says to allow up to 24 hours for DBEB to update.
4. If it's an on-premises mail-enabled public folder, make sure it's synced to Exchange Online (Microsoft points to the Sync-ModernMailPublicFolder script).
5. If it's an on-premises dynamic distribution group, create a mail contact in Exchange Online with the group's external address, since dynamic groups can't sync.

How to confirm it's fixed

The sender resends the original message. If it delivers, you're done. For admin changes to on-premises objects, give it up to 24 hours before testing again, since that's how long Microsoft says DBEB can take to update. You can also run a message trace in the Exchange admin center to confirm the message was accepted.

How to keep it from coming back

• Senders: suppress hard bounces automatically and keep mailing your list regularly, so dead B2B addresses get removed when they die rather than piling up. See how to read a bounce message for sorting address problems from reputation problems.
• Admins: add every mail-enabled object to Exchange Online before setting a domain to Authoritative, and check directory sync health after changes to on-premises users.

For other "permanent failure" bounces, the SMTP 550 overview and the SMTP error code lookup table explain how to tell them apart.

When to get help

If a large share of a B2B list is suddenly returning 5.4.1 and 5.1.1, the list probably needs a proper review before the next send. Get in touch.

FAQ

Is 550 5.4.1 a spam block?

No. It's a recipient validation failure. Microsoft 365 rejects the message before spam filtering even runs, because the address isn't in the recipient organization's directory.

Can I fix a 550 5.4.1 from my side?

Only if the address is wrong. If the address is correct, the recipient's Microsoft 365 admin has to fix their directory or accepted domain settings.

What's the difference between 550 5.4.1 and 550 5.1.1?

Both mean the recipient wasn't found. Microsoft 365 returns 5.4.1 when Directory-Based Edge Blocking rejects the address at the edge (domain set to Authoritative); 5.1.1 is the general "user unknown" code used by most mail servers.

Should I remove 550 5.4.1 addresses from my list?

Yes, treat them as hard bounces. If you later learn the address was valid and the recipient fixed their setup, you can add it back.