How do I fix '550 5.4.1 Recipient address rejected: Access denied'?

Getting a 550 5.4.1 Recipient address rejected: Access denied non-delivery report (NDR) is frustrating because the wording sounds like a permissions problem, when it almost always means the recipient address simply is not recognized. Microsoft documents the exact cause in its Fix NDR error code 550 5.4.1 guide: the bounce "is generated when directory-based edge blocking in Microsoft Exchange Online blocks an incoming email message because the recipient's email address is invalid."

What the error actually means

Exchange Online has a feature called directory-based edge blocking (DBEB). When a domain is set to Authoritative in Microsoft 365, Exchange rejects any message addressed to a recipient that does not have a valid object (mailbox, distribution group, mail contact, etc.) in that tenant — at the edge, before the message is accepted. So 550 5.4.1 is Microsoft saying: "this domain is mine, and I have no recipient by that name." The "Access denied" wording is misleading; it is a recipient does not exist here error, not a sender-permission error.

If you are the sender (most common)

Work through these in order before contacting the recipient's IT team:

• Check the spelling of the recipient address. Microsoft's first troubleshooting step is to "check the spelling of the recipient's email address in the NDR." A single transposed letter or wrong domain triggers 550 5.4.1.
• Confirm the mailbox still exists. If the person left the organization, their mailbox may be disabled or deleted, which removes the directory object and makes every message to them bounce with this code.
• Re-add the contact from a fresh source. Stale autocomplete entries in Outlook frequently hold an old or malformed address. Delete the cached entry and retype the address, or get a current one from the recipient.
• Check for an alias that was removed. If you were emailing an alias or a shared address that has since been removed, the primary address may still work.

If the address is definitely correct and the recipient confirms their mailbox is active, the problem is on the recipient's side and they need to act on the items below.

How 550 5.4.1 differs from other rejection codes

It helps to know what 550 5.4.1 is not, so you do not waste time on the wrong fix:

• 550 5.1.1 — "User unknown" / mailbox does not exist. Similar symptom, but generated when the domain is not under DBEB and the address simply has no mailbox. The fix is the same: correct the address.
• 550 5.7.x (for example 550 5.7.1, 550 5.7.26, 550 5.7.515) — these are policy rejections: the recipient or its filters refused your mail for authentication or reputation reasons, not because the address is invalid. Those point back to your sending setup — SPF, DKIM, DMARC, and reputation — which the sender requirements page covers in full.
• 550 5.4.1 — specifically directory-based edge blocking: the address is unknown in this Microsoft 365 tenant. The qualifier "Recipient address rejected: Access denied" is the tell.

So if you see 5.4.1, treat it as a recipient-existence issue. If you see 5.7.x, audit your own authentication with the free email security test and fix what fails. Mixing these up is the most common reason people spend hours on the wrong side of the problem.

If you are the recipient's email administrator

Microsoft's documented fixes depend on scope:

• All recipients in the domain are bouncing — resync the domain. In the Exchange admin center, go to Mail flow > Accepted domains, select the affected domain, and in its flyout pane switch the domain type from Authoritative to Internal relay, then switch it back to Authoritative. This forces DBEB to rebuild and clears stale rejection state across the whole domain.
• One recipient in a hybrid environment — reset the SMTP proxy address. If a specific on-premises user mailbox in an Exchange hybrid (with directory sync to Microsoft Entra ID) bounces, reset that mailbox's SMTP proxy address: change it to a temporary address, then revert it to the original. Microsoft notes you should "allow up to 24 hours for directory-based edge blocking to fully update" after on-premises changes.
• A mail-enabled public folder — verify it is synced. If the recipient is an on-premises mail-enabled public folder in a hybrid setup, confirm it appears in Exchange Online. If it does not, run the Sync-ModernMailPublicFolder PowerShell script to copy on-premises mail-enabled public folders to Exchange Online.
• A dynamic distribution group — create a matching mail contact. On-premises dynamic distribution groups cannot sync to Exchange Online, so create a mail contact in Exchange Online with the same external email address.

Microsoft also recommends, when first setting up Exchange, temporarily setting the accepted domain type to Internal Relay, then switching to Authoritative only after all recipients are added and fully replicated — which avoids DBEB rejecting mail during migration.

Rule out an authentication problem on the sending side

Although 550 5.4.1 is a recipient-existence error, a misconfigured sending domain can muddy the picture — if your own SPF, DKIM, or DMARC is broken, some recipients' filters may reject or quarantine your mail with other codes that get confused with this one. It is worth confirming your sending domain is clean while you investigate:

• Validate your SPF record and keep it under the 10-lookup limit with SPF flattening if needed.
• Publish and tighten a DMARC policy so receivers have a clear instruction for your mail, and read the DMARC fundamentals to understand alignment.

A fully authenticated sender removes the variables that make recipient-side rejections hard to diagnose, leaving 550 5.4.1 as the clean recipient-existence signal it is meant to be.

Verify the recipient domain's mail setup

If you administer the receiving domain and are not sure its DNS and routing are healthy, check them:

1. Run the free email security test against the recipient domain to confirm SPF, DKIM, DMARC, and overall mail health.
2. Use the DNS lookup tool to verify the MX records point where you expect — for Microsoft 365 that is your <tenant>.mail.protection.outlook.com record. A domain whose MX still points at an old host can produce confusing recipient-rejection bounces.
3. Review the sender requirements page to make sure the sending side is fully authenticated — a clean sender setup rules out auth-related rejections and isolates the problem to recipient validity.

The bottom line

550 5.4.1 Recipient address rejected: Access denied is a recipient-existence problem, not a sender-blocking problem. Senders should verify the address and the recipient's mailbox status first; recipient admins should resync the accepted domain or fix the specific object in their hybrid directory. In the large majority of cases it is a typo or a deleted mailbox, and the fix takes seconds.