Fix 550 5.4.1 Recipient Address Rejected in Microsoft 365

By Dominic LandryJune 3, 2025Updated September 16, 202610 min read

Ask AI to explain

In brief

Fix Microsoft 550 5.4.1 Recipient address rejected: verify the mailbox or alias, Exchange accepted domain, DBEB configuration, hybrid sync, and migration state.

Fix 550 5.4.1 Recipient Address Rejected in Microsoft 365

Microsoft's 550 5.4.1 Recipient address rejected: Access denied error (especially when it includes AS(201806281)) normally means Exchange Online's Directory-Based Edge Blocking (DBEB) could not find a valid recipient object for the address. It is a recipient-side directory or mail-routing problem, not a generic SPF, DKIM, DMARC, or sender blocklist error.

The full NDR commonly contains:

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

If you are the sender, verify the address and give the complete NDR to the recipient's Microsoft 365 administrator. If you administer the recipient domain, check the mailbox or alias, accepted-domain type, directory synchronization, and migration state in that order.

Start with the public route when several addresses fail or the NDR names an unexpected host: check the recipient domain's MX records. If one address fails while other addresses at the domain work, skip straight to the recipient-object checks below.

The 30-second decision tree

What you observe	Likely cause	Next check
One address fails but others at the domain work	Missing, mistyped, or unsynced recipient object	Verify the exact proxy address in Exchange Online
A recently created mailbox or alias fails	Provisioning or directory-sync delay	Check the object and force the supported sync process
All recipients fail after a migration	Accepted domain, recipient population, or routing mismatch	Check accepted-domain type, objects, connectors, and MX
The address exists only on-premises	DBEB cannot validate the recipient in Microsoft 365	Verify hybrid synchronization or use the correct relay model
The NDR names authentication instead of the recipient	Different 550 error	Follow the exact authentication code, such as 550 5.7.515

Match the NDR clue to the team that can act:

NDR clue	Who owns the next check	What to send or inspect
`Recipient address rejected: Access denied. AS(201806281)` from `mail.protection.outlook.com`	Recipient's Microsoft 365 administrator	Exact SMTP address, recipient object, proxy addresses, accepted-domain type, and directory sync
One address fails; other addresses at the same domain deliver	Sender first, then recipient administrator	Sender verifies the address; recipient administrator verifies that exact mailbox, alias, group, or contact
Every address at the domain fails, or the remote server is unexpected	Recipient mail-routing or gateway administrator	MX destination, accepted domains, connectors, migration state, and the hostname that issued the rejection
`Relay Access Denied` without the DBEB wording	Administrator of the rejecting host	Full NDR, destination domain, connector or smart-host path, and gateway logs; use the relay-variant guide
Authentication or sender reputation is named instead	Sender or sending-service owner	Follow the exact 5.7.x or reputation code rather than changing recipient objects

What Microsoft 550 5.4.1 means

DBEB rejects mail for invalid recipients at Microsoft's service network perimeter. Microsoft documents that when the address does not exist, the message is blocked before the normal anti-malware, anti-spam, and mail-flow-rule layers. That is why changing the sender's SPF record or requesting an IP delisting usually does not fix this specific NDR.

DBEB is already active when all recipients for an accepted domain are in Exchange Online. Hybrid and migration scenarios need more care because Microsoft 365 must know which addresses are valid before it can safely reject unknown ones.

How to fix 550 5.4.1 step by step

1. Preserve the complete NDR

Record the failed recipient, timestamp, rejecting hostname, and diagnostic suffix. The combination of Recipient address rejected, AS(201806281), and a hostname ending in mail.protection.outlook.com points to Exchange Online Protection and DBEB.

If the NDR instead says the sending domain does not meet the required authentication level, use the Microsoft 550 5.7.515 guide.

2. Verify the exact recipient address

Check for a typo first. Then, in the Exchange admin center, confirm the SMTP address exists on a supported recipient object:

User mailbox
Shared mailbox
Mail user or mail contact
Microsoft 365 group or distribution group, when configured to receive the message
Proxy address or alias attached to the intended object

Search for the full SMTP address, not only the display name. A mailbox can exist while the specific alias used by the sender is missing.

In an authenticated Exchange Online PowerShell session for the recipient's tenant, the administrator can inspect the recipient with this read-only command. Replace the example address with the exact address in the NDR:

POWERSHELLpowershell

Get-EXORecipient -Filter "EmailAddresses -eq 'person@example.com'" -Properties EmailAddresses |
    Format-List DisplayName,RecipientTypeDetails,PrimarySmtpAddress,EmailAddresses

Microsoft's Get-EXORecipient reference documents recipient lookup and requesting additional properties; its filter reference supports matching the full email address in EmailAddresses. Check the returned EmailAddresses collection for the rejected address, including aliases. A successful command identifies a directory object; it does not prove that the object can receive this message or that DBEB has already recognized a recent change.

For example, if alex@example.com receives mail but billing@example.com bounces, finding Alex's mailbox is not enough: billing@example.com must also be attached to the intended mail-enabled object. An empty result calls for checking the address, tenant, permissions, and synchronization. A failed connection or permission error is not evidence that the recipient is missing.

3. Check the accepted-domain type

In Exchange admin center → Mail flow → Accepted domains, inspect the recipient domain:

Authoritative: Exchange Online expects every valid recipient to exist in its directory. DBEB rejects unknown addresses.
Internal relay: Some or all recipients can live outside Microsoft 365, and mail may need to continue through a connector to another system.

An authoritative domain can still include on-premises mailboxes when their mail-enabled recipient objects are represented in Microsoft 365. Mailbox location alone does not determine the accepted-domain type. Microsoft's accepted-domain guidance explains the directory requirement and the connector needed to relay unknown recipients downstream.

Do not toggle Internal relay and Authoritative as a generic cache reset. Microsoft's DBEB setup procedure uses Internal relay while valid recipients are being populated, then switches to Authoritative after those recipients have replicated. The recipient-population step is essential; the procedure does not establish that toggling the setting repairs a correctly configured tenant.

Choose the type that matches the real mail architecture and verify the connector or downstream route before changing production flow. If the type is already correct, continue with recipient and synchronization checks.

4. Fix hybrid directory synchronization

In a hybrid environment, confirm that the on-premises recipient and every required proxy address synchronize into Microsoft Entra ID and Exchange Online. Check:

The recipient is in the synchronization scope.
The primary address and aliases are present in proxyAddresses.
The latest synchronization cycle completed successfully.
The object appears as the expected mail-enabled recipient in Exchange Online.
Public folders or other special recipient types follow Microsoft's supported hybrid configuration.

If the object is absent, correct the directory source and use the organization's supported synchronization process. Creating a separate cloud object to mask the issue can produce address conflicts later.

5. Check migration sequencing

This error often appears when MX is moved to Microsoft 365 before every recipient has been provisioned or synchronized. During a cutover:

Inventory every address that must receive mail.
Create or synchronize the recipients.
Configure the accepted domain and any connectors.
Test representative addresses from outside the organization.
Change MX only when Microsoft 365 can resolve the full recipient set.

Use the MX lookup tool to confirm where public mail is routed. An MX result can confirm the public destination, but it cannot inspect the Microsoft 365 recipient directory.

6. Run message trace as the recipient administrator

The recipient's administrator can use Exchange admin center → Mail flow → Message trace to correlate the sender, recipient, and failure time. Also review service health and recent directory or migration changes.

Because DBEB can reject at the perimeter, the trace may contain less detail than a message that entered the later filtering pipeline. The NDR and recipient-object state remain essential evidence.

Use this receiving-admin checklist before escalating:

Check	Evidence to capture	Passing condition
Recipient object	Object type and the exact primary or proxy SMTP address	The rejected address appears on one intended, mail-enabled object
Accepted domain	Domain type and the actual recipient architecture	Authoritative when every valid recipient is represented in the Microsoft 365 directory; Internal relay with a working downstream route when needed
Directory synchronization	Source object, sync scope, last successful cycle, and cloud object	The intended address is visible on the Exchange Online recipient
Connectors and migration	Connector target, scope, recent cutover changes, and representative tests	Unknown or migrated recipients follow the intended route without a loop
Public MX	Current MX answer from the MX lookup tool	The domain advertises the intended receiving service and tenant

If the address, accepted domain, synchronization, connectors, and route are correct but the same DBEB response persists, the recipient administrator should escalate through their Microsoft 365 support channel. Include the complete NDR, UTC timestamp, rejected address, Message-ID when available, rejecting hostname, sender address and IP, tenant domain, message-trace result, recent changes, and a controlled retry. Send unredacted evidence only through the organization's approved support channel.

7. Retest the exact address

After the recipient object and routing are correct, send one external message to the same address. Then test an alias and another known-valid address at the domain. This separates an object-specific problem from a domain-wide routing problem.

What senders can and cannot do

The sender can:

Confirm the recipient address with another channel.
Preserve and forward the complete NDR.
Retry after the recipient administrator confirms the object is valid.
Test whether other addresses at the same domain work.

The sender usually cannot repair DBEB, create the missing recipient object, change the accepted-domain type, or run the recipient tenant's message trace. Those actions belong to the recipient's Microsoft 365 administrator.

What not to change first

SPF, DKIM, or DMARC: important for authentication, but they do not create a missing recipient object.
Sender blocklist status: the AS(201806281) DBEB failure is about recipient validity.
The sender's MX record: inbound routing for the recipient domain is the relevant route.
The accepted-domain type without a routing plan: an incorrect relay change can send mail to the wrong place or create loops.

Evidence

Sources and further reading

Other bounce codes: the SMTP error code index covers the common rejection codes, each with causes and fixes.

Questions readers ask

Frequently asked questions

Is 550 5.4.1 always a Microsoft 365 error?

Other mail systems can reuse enhanced status codes, so read the complete text and rejecting hostname. The Recipient address rejected: Access denied. AS(201806281) form from a mail.protection.outlook.com host is the Microsoft DBEB pattern covered here.

Why does one recipient fail while others work?

The exact mailbox or alias may be missing, misspelled, recently provisioned, outside synchronization scope, or absent from the cloud directory. Search for the full SMTP address in Exchange Online.

Can fixing SPF resolve this error?

Not when the NDR is the DBEB AS(201806281) recipient-address failure. SPF evaluates a sending identity; DBEB is rejecting because the destination address is not recognized. Follow a different guide if the NDR explicitly names sender authentication.

How long does a directory fix take?

Timing depends on whether the object is cloud-only, synchronized from on-premises, or part of a migration. Verify that the corrected recipient actually appears in Exchange Online before retesting rather than relying on a generic propagation estimate.

Why did this start after changing MX?

The MX change may have directed mail to Exchange Online before all recipients, accepted domains, and connectors were ready. Confirm the public MX route, then verify the tenant can resolve every intended recipient.