Fix 550 5.4.1 Recipient address rejected: Access denied in Exchange Online

The 550 5.4.1 Recipient address rejected: Access denied bounce means Exchange Online's Directory-Based Edge Blocking (DBEB) rejected the message at the service perimeter because the recipient address isn't in your Microsoft 365 directory. To fix it, confirm the address is spelled correctly, then either resync the accepted domain (if every recipient in the domain is affected) or get the single missing address into Exchange Online through directory sync, a public folder sync or a mail contact. If the domain still has recipients on another mail system, set it to Internal relay until they are all in Exchange Online.

Who this is for and what you will have

This guide is for Exchange Online administrators who receive reports from external senders that their mail bounced with 5.4.1, or who see the error during a migration or in an Exchange hybrid deployment. At the end you will have:

• A clear answer on whether the problem affects one recipient or a whole domain.
• The accepted domain set to the right type for where your recipients actually live.
• Missing hybrid recipients, mail-enabled public folders and on-premises dynamic distribution groups resolvable by Exchange Online.
• A short verification routine you can repeat after every change.

What the error actually means

Directory-Based Edge Blocking checks every inbound recipient against the directory before any other filtering happens. If the address exists, the message continues through anti-malware, anti-spam and mail flow rules. If it doesn't, the service blocks the message and returns an NDR with this text:

550 5.4.1 Recipient address rejected: Access denied

DBEB is controlled by the accepted domain type. Exchange Online has two:

So the 5.4.1 bounce is almost always the correct behavior of an Authoritative domain meeting an address that Exchange Online doesn't know about. The work is finding out why the address is missing.

Two details from Microsoft's documentation are worth knowing before you start:

• In a hybrid environment, DBEB only works when the domain's MX record points to Microsoft 365, so that mail for the domain reaches Exchange Online first.
• Even with an Authoritative domain, Microsoft notes there might be infrequent cases where an address that doesn't exist is allowed through. DBEB is a perimeter filter, not a guarantee.

Prerequisites

• An account with permission to manage accepted domains (the "Domains" entry in Exchange Online feature permissions) and recipients.
• Exchange Online PowerShell with the ExchangeOnlineManagement module.
• For hybrid recipients: access to on-premises Exchange and to the server running Microsoft Entra Connect Sync.
• The full NDR from the sender, including the recipient address exactly as it was rejected.

Start with an inventory of your domains:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-AcceptedDomain | Format-Table DomainName,DomainType,MatchSubDomains

Any domain that shows Authoritative has DBEB enabled.

Step 1: Confirm the address and the scope

Microsoft's troubleshooting order starts with two simple checks, and they decide which fix applies.

1. Check the spelling of the recipient address in the NDR. A typo by the sender produces exactly this error, and nothing on your side needs to change.
2. Check the scope. If mail to alina@contoso.com bounces, send test messages from an external mailbox to two or three other recipients in contoso.com. If they all bounce, the problem is domain-wide. If only one address bounces, it's that recipient.

Then look the address up in Exchange Online:

Get-Recipient -Identity alina@contoso.com | Format-List

If the command can't find the recipient, Exchange Online doesn't know the address and DBEB will keep rejecting it. If it returns an object, check that the exact rejected address appears in the recipient's email addresses, not just a similar one.

Step 2: Fix domain-wide rejections

When every recipient in a domain is rejected, Microsoft's documented fix is to resync the domain by switching its type and switching it back.

1. In the Exchange admin center, go to Mail flow > Accepted domains and select the affected domain.
2. In the details flyout, change the domain type from Authoritative to Internal relay and select Save.
3. Change it back to Authoritative and select Save. You are asked to confirm that you want to enable Directory-Based Edge Blocking.

The PowerShell equivalent uses Set-AcceptedDomain:

Set-AcceptedDomain -Identity contoso.com -DomainType InternalRelay
Set-AcceptedDomain -Identity contoso.com -DomainType Authoritative

The Save button only appears for admins who hold the permissions required to change the domain type. If you don't see it, check your role assignment before going further.

While a domain is Internal relay, DBEB is off for it and unknown recipients are relayed to your own mail server through a connector. In a cloud-only tenant with no such server, don't leave the domain in Internal relay; switch it straight back.

When the domain type itself is wrong

Sometimes the resync isn't the answer because the domain is correctly reporting a design problem. Check these cases:

• A migration is in progress and some mailboxes are still on the old system. Microsoft recommends leaving the domain as Internal relay until all valid recipients are added to Exchange Online and replicated, then switching to Authoritative. The same applies when you move mailboxes from Google Workspace, covered in the Google Workspace to Microsoft 365 migration guide, or between tenants, covered in the cross-tenant migration architecture.
• You use match subdomains. The Accept mail for all subdomains option (MatchSubDomains) requires the domain to be Internal relay, so it can't be Authoritative at the same time. If you have only a few known subdomains, Microsoft recommends adding each one as its own accepted domain instead.
• The MX record points somewhere else. In hybrid, if the MX record points to on-premises or a third-party gateway, DBEB can't do its job as designed. Decide whether Exchange Online should receive mail for the domain first.

If you choose Internal relay, you must also have an outbound connector from Microsoft 365 to your own email server, or recipients that aren't hosted in Exchange Online won't receive mail.

Step 3: Fix a single hybrid recipient

If only one recipient is rejected and that person has an on-premises mailbox in an Exchange hybrid deployment that uses directory synchronization, the address most likely never reached Exchange Online. Microsoft's fix is to reset the recipient's SMTP proxy address on-premises:

1. In on-premises Exchange, change the affected proxy address to a temporary value.
2. Let directory synchronization run.
3. Change the proxy address back to the original value and let synchronization run again.
4. Allow up to 24 hours for DBEB to fully update after changes to the on-premises mailbox.

Before you do this, run the Get-Recipient check from Step 1 in Exchange Online. If the recipient object exists but the rejected address is missing from its email addresses, the reset is the right fix. If no object exists at all, look at the Entra Connect Sync scope first: an object outside the synchronized organizational units or filtered out by a sync rule will never appear in Exchange Online, however often you reset its address.

Step 4: Public folders and dynamic distribution groups

These two recipient types used to be a common reason to turn DBEB off, and the rules changed in June 2025, when Microsoft announced that DBEB now works for mail-enabled public folders and dynamic distribution groups. Before that, Exchange Online-only organizations that wanted external mail delivered to them had to turn DBEB off. The Microsoft Learn page on enabling mail flow for subdomains still says that DBEB can't be used for public folders; the 2025 announcement is the more recent statement.

On-premises mail-enabled public folders

Check whether the folder is visible in Exchange Online:

Get-MailPublicFolder

If the folder doesn't appear, run the Sync-ModernMailPublicFolders.ps1 script on-premises to copy your mail-enabled public folders to Exchange Online. If you previously synchronized public folders only to Microsoft Entra ID through the Exchange Mail Public Folders option in Entra Connect, Microsoft's guidance is to sync them to Exchange Online with the script first and then turn that Entra Connect option off. You find it in the Entra Connect wizard under Customize synchronization options > Optional features.

On-premises dynamic distribution groups

Dynamic distribution groups created in Exchange Server don't sync to Exchange Online, so DBEB rejects mail sent to them through Exchange Online. Microsoft's documented workaround is a mail contact in Exchange Online that has the same external email address as the group:

New-MailContact -Name "All Staff (on-premises DDG)" -ExternalEmailAddress "allstaff@contoso.com"

Test delivery to the group from an external mailbox after you create the contact. The alternative is to set the domain to Internal relay so that unknown addresses are relayed to your on-premises servers, which turns DBEB off for the whole domain.

Verify the fix

1. Run Get-AcceptedDomain and confirm each domain has the type you intended.
2. Run Get-Recipient for each previously rejected address and confirm it resolves.
3. Send a test message from an external mailbox to each previously rejected address and confirm delivery.
4. Send a test message to an address that doesn't exist, for example does-not-exist@contoso.com. On an Authoritative domain it should bounce with 5.4.1. That confirms DBEB is still protecting the domain.
5. If you changed anything on-premises, repeat the tests the next day, because DBEB can take up to 24 hours to reflect on-premises mailbox changes.

You can follow the test messages with the tools described in message trace in Exchange Online with Get-MessageTraceV2.

Troubleshooting

Every recipient in a newly added domain bounces. The domain was set to Authoritative before the recipients' addresses existed in Exchange Online. Add the addresses (or finish directory sync), then resync the domain as in Step 2. During a migration, keep the domain on Internal relay until the move is complete.

A user who was just created or renamed bounces for a while. New addresses need to replicate before DBEB accepts them. For on-premises changes, Microsoft says to allow up to 24 hours.

An address that only exists on a non-Microsoft system bounces. With an Authoritative domain, Exchange Online accepts mail only for addresses it knows. Either represent the recipient in Exchange Online (for example through directory synchronization) or keep the domain on Internal relay with a connector to the other system until it is retired.

The NDR shows a different 5.x.x code. A different code means a different control rejected the message, and the steps in this guide won't help. For example, your own users get 5.7.703 when they send to a domain or address blocked in the Tenant Allow/Block List, covered in Tenant Allow/Block List for spoofed senders and domains.

Checklist

• NDR checked for a misspelled recipient address.
• Scope established: one recipient or the whole domain.
• Get-AcceptedDomain reviewed; Authoritative only where every recipient is known to Exchange Online.
• Domain-wide failures: domain resynced by switching to Internal relay and back.
• Hybrid recipient: proxy address reset on-premises, sync completed, 24 hours allowed.
• On-premises mail-enabled public folders synced with Sync-ModernMailPublicFolders.ps1.
• On-premises dynamic distribution groups covered by a mail contact in Exchange Online.
• MX record points to Microsoft 365 for hybrid domains that rely on DBEB.
• Positive and negative tests completed from an external mailbox.

References

• Fix NDR error 550 5.4.1 in Exchange Online
• Use Directory-Based Edge Blocking to reject messages sent to invalid recipients
• Manage accepted domains in Exchange Online
• Enable mail flow for subdomains in Exchange Online
• Directory Based Edge Blocking now available for public folders and dynamic distribution groups
• Japan Exchange and Outlook Support Blog translation of the DBEB announcement
• Get-Recipient
• New-MailContact