550 5.4.1 Recipient Address Rejected: Access Denied Fix

If you sent an email to a Microsoft 365 address and got back a bounce reading 'Recipient address rejected: Access denied' with the code 550 5.4.1, you are looking at a Microsoft-specific error that reads like something you did wrong. In nearly every case, you did not — the problem lives inside the recipient's Exchange Online configuration.

The code is generated by Directory Based Edge Blocking, a feature in Exchange Online that checks the recipient address against the tenant directory before the message enters any spam or malware filtering. If the address is not found, the connection is rejected at the network edge and the bounce goes back to you.

This article explains what the error means, walks through the three root causes and how to fix each one, and gives you a copy-pasteable message to send the right person — because almost every fix to a 550 5.4.1 bounce requires action on the recipient's side, not yours.

What does 550 5.4.1 literally mean?#

The bounce code has two parts. 550 is the SMTP reply code for a permanent delivery failure — the destination server accepted your connection, examined the recipient address, and refused the message. Your server will not retry. Unlike a 4xx soft bounce, a 5xx code means the problem will not resolve itself.

5.4.1 is an enhanced status code from RFC 3463. Class 5 is permanent failure; subject 4 is network and routing status; detail 1 is no answer from the host. Microsoft uses this slot for two related but distinct conditions, which is what makes the error confusing to diagnose.

The first is 550 5.4.1 Relay Access Denied, which means the destination server does not accept mail for the recipient's domain at all — typically an MX record misconfiguration or a broken inbound connector. The second is 550 5.4.1 Recipient address rejected: Access denied, which is Directory Based Edge Blocking rejecting a specific address because it is not in the tenant's directory. Both share the same numeric code.

The NDR body distinguishes them. Look for the exact phrase in your bounce report — Relay Access Denied or Recipient address rejected — before deciding which fix to apply.

The three causes of 550 5.4.1 recipient address rejected#

Every 550 5.4.1 Recipient address rejected bounce from Microsoft 365 has one of three root causes. Identifying the right one before contacting the recipient's admin saves time and gets the correct person working on the correct fix.

Fix 1: Mailbox does not exist in Exchange Online#

The most common single cause is an address that was never created in Exchange Online, or one that was deleted when someone left the organisation. Directory Based Edge Blocking does not distinguish between the two — if the address is not in the tenant directory, the message is rejected at the network edge.

1. 1

   Confirm the domain is live

   Try sending a short test to a different address at the same domain, or check whether the organisation's website uses that domain. If another address delivers normally, the domain is active and only this specific mailbox is missing.

2. 2

   Reach the organisation through another channel

   Use the company website's contact form, a general address such as info@ or hello@ at the same domain, or a phone call. Ask whether the email address has changed or whether the account still exists in their system.

3. 3

   Forward the NDR to their IT contact

   Send the full bounce message to whoever manages Microsoft 365 at the recipient's organisation. The NDR body includes the exact failed address and the code 550 5.4.1 Recipient address rejected — enough for an M365 admin to locate and fix the problem in the Exchange admin centre in a few minutes.

4. 4

   Copy-pasteable message to send

   Hi — I am getting a 550 5.4.1 Recipient address rejected: Access denied bounce when sending to [address]. This usually means the mailbox does not exist in your Exchange Online tenant or the account has been deleted. Could you check whether the address is active or whether it has changed? I have attached the full bounce report.

Fix 2: Accepted domain set to Authoritative before all mailboxes are added#

When an organisation migrates to Microsoft 365 or adds a new domain, the accepted domain type in the Exchange admin centre controls whether Directory Based Edge Blocking is active. An Authoritative domain tells Exchange Online to reject any address it does not recognise. An Internal relay domain passes unrecognised addresses to an on-premises server instead.

The problem arises when an admin sets the domain to Authoritative before all mailboxes have been provisioned. Every unprovisioned address starts bouncing with 550 5.4.1, including addresses for employees who are actively waiting for their accounts to be created. The fix belongs entirely to the recipient's admin.

1. 1

   Open Mail flow then Accepted domains in the Exchange admin centre

   Find the domain that is producing the bounces and check whether the domain type is set to Authoritative or Internal relay.

2. 2

   Temporarily set the domain to Internal relay if migration is not complete

   This suspends DBEB for the domain and allows messages through to the on-premises server while provisioning finishes. Do not leave it as Internal relay permanently — DBEB is a meaningful rejection layer against messages to invalid addresses.

3. 3

   Provision all valid recipients in Exchange Online

   Add mailboxes through the Microsoft 365 admin centre, by running directory synchronisation from on-premises Active Directory via Microsoft Entra Connect, or through PowerShell. Every intended recipient at the domain needs a record in Exchange Online before DBEB is re-enabled.

4. 4

   Set the domain back to Authoritative

   Once all recipients are provisioned and directory sync has completed, switch the domain type back to Authoritative. Microsoft's documentation notes that changes can take up to 24 hours to propagate through the DBEB system.

Fix 3: Hybrid environment not synced to Exchange Online#

In a hybrid Exchange deployment — where an organisation runs on-premises Exchange servers alongside Exchange Online — some mailboxes live on-premises and some in the cloud. Directory Based Edge Blocking only checks Exchange Online's directory.

If an on-premises mailbox has not been synchronised into Exchange Online's directory, external senders get a 550 5.4.1 bounce even though the mailbox physically exists and internal senders reach it without any problem. Two objects make this harder to diagnose: on-premises mail-enabled public folders and dynamic distribution groups do not sync to Exchange Online automatically under the default configuration.

1. 1

   Force a directory synchronisation run via Microsoft Entra Connect

   This pushes on-premises user accounts into Exchange Online's directory. After the sync, allow up to 24 hours for the DBEB cache to update before testing delivery again.

2. 2

   Verify the domain MX record points to Microsoft 365

   DBEB only runs when inbound mail arrives at Exchange Online first. If the MX record still points to an on-premises server, DBEB never fires — the source of the 550 5.4.1 bounce is something else and the diagnosis changes.

3. 3

   For on-premises mail-enabled public folders

   As of mid-2024, Microsoft extended DBEB support for mail-enabled public folders in hybrid configurations, but the feature may need to be enabled explicitly in your setup. Check the Microsoft Exchange team blog for current guidance on enabling it.

4. 4

   For on-premises dynamic distribution groups

   Create a mail contact in Exchange Online with the same external SMTP address as the on-premises group. DBEB recognises the mail contact address and passes the message through to the on-premises server for delivery. This is the documented Microsoft workaround for groups that cannot sync automatically.

How to tell which cause applies#

Before contacting anyone, work through three questions. They take about two minutes and point you to the right fix.

First, read the exact phrase in the NDR body. Does it say Relay Access Denied or Recipient address rejected? Relay Access Denied points to an MX record or inbound connector issue and is not covered by the fixes above. Recipient address rejected means DBEB blocked the address — continue with the three causes.

Second, try a different address at the same domain. Send a short test to info@ or another person at the organisation. If that delivers and only your original target bounces, the problem is the specific mailbox — Fix 1. If every address at the domain bounces, the domain type is likely misconfigured — Fix 2.

Third, ask whether this address has ever worked for you. If it delivered a few months ago and broke this week, something changed in the tenant — a deleted account or a domain type switch. If it has never delivered, check the address character by character for a typo before concluding the mailbox is missing.

Preventing 550 5.4.1 bounces#

As a sender to Microsoft 365 tenants, your options for preventing this bounce are limited — the cause lives inside the recipient's configuration. What you can control is how quickly you act when one arrives.

Treat every 550 5.4.1 as a hard bounce immediately. Remove the address from active sequences rather than retrying it. The same rejection repeats on every attempt until the recipient's admin resolves the issue.

Watch for domain-wide patterns. If multiple contacts at the same organisation start bouncing on the same date, that is almost certainly a migration event — the admin switched the domain to Authoritative before finishing provisioning. A single bounce is a missing mailbox; a domain-wide wave is an admin configuration change. Contact a general address at the organisation and forward the NDR rather than waiting.

Hard bounces from Microsoft 365 arrive mixed in with regular messages, and the diagnostic detail that matters — whether the NDR reads Relay Access Denied or Recipient address rejected, whether the pattern is one address or an entire domain — is buried in the bounce body, not the subject line. We build AI Emaily, an AI-native email client that reads the enhanced status code on every NDR, surfaces it as a structured alert, and flags domain-wide bounce patterns as they form. If you send to Microsoft 365 tenants regularly, it keeps the triage from slipping. A 7-day free trial is available on the Pro plan.