SMTP error code · permanent failure (5xx)
SMTP error 550 5.4.1: recipient address rejected, access denied
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026
550 5.4.1 Recipient address rejected: Access denied is Microsoft 365 refusing your message because the recipient's address isn't in the receiving tenant's directory: that's Directory-Based Edge Blocking doing its job. It's permanent and recipient-side: the receiving admin has to sync the missing address into Exchange Online or fix the accepted-domain and connector setup.
550 5.4.1 at a glance | |
|---|---|
| Code | 550 5.4.1 |
| Class | Permanent (5xx): the message was refused and will not retry |
| Category | Recipient |
| Side at fault | Recipient |
| Auth-related | No |
What the bounce actually says
The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.
Microsoft 365 (Exchange Online Protection) — Directory-Based Edge Blocking
550 5.4.1 550 5.4.1 Recipient address rejected: Access deniedSource: support.microsoft.com
Microsoft 365 — full NDR as it arrives in the wild
550 5.4.1 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DB5EUR01FT018.eop-EUR01.prod.protection.outlook.com]Source: learn.microsoft.com
Exchange Online — relay variant (server doesn't accept mail for the domain)
550 5.4.1 Relay Access DeniedSource: learn.microsoft.com
Why you're seeing 550 5.4.1
Almost every 550 5.4.1 you'll meet comes from Microsoft 365. Exchange Online Protection checks each incoming recipient against the tenant's directory before accepting the message (a feature called Directory-Based Edge Blocking), and when the address isn't found, it refuses the mail at the front door with Recipient address rejected: Access denied. The AS(201806281) marker in the full bounce is EOP's stamp for exactly that check. On paper, RFC 3463 labels X.4.1 a routing code ("no answer from host"), but Microsoft repurposed it, so read it as a directory verdict, not a network one. The important part for a sender: your SPF, DKIM, DMARC, and IP reputation were never consulted. Either the address genuinely doesn't exist, or the receiving tenant's directory, accepted-domain type, or connector setup is wrong, and only the receiving side can fix that.
Likely causes, ranked
| Likely cause | What's happening |
|---|---|
| The recipient address doesn't exist | The boring answer is the most common one: a typo in the address, or a mailbox that was deprovisioned when someone left. Directory-Based Edge Blocking checks the address against the tenant directory and rejects anything it can't find, before the message ever reaches a mailbox or a spam filter. |
| Hybrid directory sync gap | The mailbox lives on-premises, but its SMTP address never synced to Entra ID and Exchange Online. EOP can't see it, so DBEB treats it as invalid. Classic after adding a new user or a new proxy address on-prem: everything works internally while inbound internet mail bounces. |
| Accepted domain set to Authoritative when it shouldn't be | Authoritative means "every valid address for this domain is in my directory." If some addresses actually live on another system (mid-migration, or a shared domain), every message to those addresses gets rejected. Those setups need the Internal Relay domain type instead. |
| Unsynced public folders or dynamic distribution groups | Mail-enabled public folders and dynamic distribution groups don't automatically exist in the Exchange Online directory. Until they're synced (or represented by a mail contact), mail addressed to them bounces with this code even though the object works fine on-prem. |
| MX or connector pointing at a tenant that doesn't accept the domain | The relay-variant cause. The domain's MX record points at an Exchange Online endpoint, but the tenant behind it was never configured to accept that domain: a leftover from a migration, or a copy-paste MX from another tenant. The server refuses mail for the whole domain. |
How to fix 550 5.4.1
Check the recipient domain's Microsoft 365 setup
Run the domain that bounced you through the free Microsoft compliance checker below. It shows whether the domain actually routes to Microsoft 365, where its MX points, and whether the DNS side lines up, which tells you in one pass if this is a single bad address or a misconfigured tenant.
Run the check now
Enter the sending domain and the check runs instantly on the next page. Free, no signup.
Rule out the typo
Read the recipient address in the NDR character by character, and check whether one address bounces or every address at the domain does. One recipient failing means a bad or removed address; the whole domain failing means tenant configuration, and the remaining steps are for the receiving admin.
Re-provision the accepted domain (receiving admin)
In the Exchange admin center go to Mail flow > Accepted domains, switch the domain from Authoritative to Internal relay, save, then switch it back. That forced re-sync clears stale directory state. If some addresses genuinely live on another system, leave it on Internal Relay; that's the correct type for a shared domain.
Verify the mailbox synced to Exchange Online (hybrid)
For an on-prem mailbox, confirm its SMTP proxy address reached Entra ID. Microsoft's own workaround is to edit the proxy address, save, and revert it to force a sync, allowing up to 24 hours. Mail-enabled public folders need the Sync-ModernMailPublicFolder script; dynamic distribution groups need a matching mail contact in Exchange Online.
Confirm the MX record points at the right tenant
Look up the domain's MX with the free checker at /tools/mx. An Exchange Online domain should resolve to its own *.mail.protection.outlook.com endpoint (the host is derived from the domain with dots turned into dashes, so
contoso.comgetscontoso-com.mail.protection.outlook.com), and that tenant must list the domain under Accepted domains. An MX aimed at the wrong tenant produces the Relay Access Denied variant for the entire domain.Re-send once the directory is fixed
550 is a permanent failure: the original message was refused, not queued, and nothing retries on its own. After the receiving side confirms the fix, send the message again.
Related free tools: MX record checker · DNS lookup · Email security score
Why it matters for MSPs
A 550 5.4.1 ticket in MSP-land has an uncomfortable shape: the sender opens the complaint, but it's your managed tenant doing the rejecting. A hybrid sync gap after onboarding a new hire, an accepted domain left Authoritative after a partial migration, or an MX record cut over before the tenant accepted the domain: each one silently bounces real mail until someone outside the org complains. Be honest about scope: this is a directory problem, and no DNS record fixes it. But the same migrations that cause it are exactly where the DNS half goes wrong too, which is the half Palisade manages: hosted SPF, DKIM, DMARC, and MTA-STS records for every client domain, with native ConnectWise, HaloPSA, and Autotask integrations so domain work lives in your existing workflow. The free Microsoft compliance checker and MX checker triage a client tenant in seconds, and your own MSP domain runs free as an NFR domain.
Frequently asked questions
Related error codes
Email deliverability, fixed: the full guideNot sure this code is your only problem?
Run a free email security score: every authentication and deliverability gap for your domain, in one pass.