550 5.4.1 Recipient address rejected: Access denied explained
550 5.4.1 Recipient address rejected: Access denied means Exchange Online found no such recipient in the tenant and blocked it at the edge. Check the address.
On this page(8 sections)
- What does 550 5.4.1 Recipient address rejected: Access denied mean?
- Is it a problem with my sending domain or reputation?
- What should the sender do?
- What if the address definitely exists?
- Why does this show up during a migration?
- How does this look to an application that sends email?
- Checklist for a 5.4.1 bounce
- Bottom line
550 5.4.1 Recipient address rejected: Access denied is a bounce from Exchange Online. It means the recipient's domain is hosted in Microsoft 365, but the service found no recipient with that address, so it refused the message before any spam or malware filtering ran. In almost every case it is not a block against you as a sender.
The mechanism behind it is Directory-Based Edge Blocking, or DBEB: Microsoft 365 checks the recipient address against the tenant's directory at the network perimeter and rejects addresses that do not exist. This guide covers how to read the bounce as a sender, what the recipient's administrator should check, and how to handle it in an app that sends email.
What does 550 5.4.1 Recipient address rejected: Access denied mean?
It means the address does not exist in the recipient's Microsoft 365 directory. Microsoft's DBEB documentation says that if a message is sent to a valid address, it continues through anti-malware, anti-spam and mail flow rules. If the address does not exist, the service blocks the message before filtering occurs and returns an NDR (non-delivery report, the bounce message).
Microsoft's NDR reference lists this exact text for 5.4.1 with the cause "the recipient's address doesn't exist." The enhanced status code 5.4.x belongs to the "network and routing" family (see our status code guide), which is why people expect a routing problem. Here the routing worked: your message reached the right place and was turned away at the door.
Is it a problem with my sending domain or reputation?
Almost certainly not. DBEB looks only at the recipient. Your SPF, DKIM, DMARC and IP reputation were not what failed. If you see this code for one address while mail to colleagues at the same domain is delivered, the address is the problem.
Compare it with the Microsoft codes that really are about the sender:
| Code and text | What it says | Where to look |
|---|---|---|
| 550 5.4.1 Recipient address rejected: Access denied | No such recipient in the tenant | The recipient address, or the recipient's directory |
| 550 5.4.1 Relay Access Denied | The server does not accept mail for that domain (Microsoft cites mail server or DNS misconfiguration) | The recipient domain's MX and accepted domain setup |
| 550 5.7.509 / 5.7.515 | Authentication or DMARC failure (guide) | Your DNS records |
| 550 5.7.705 / 5.7.708 | Tenant ban or low-reputation IP (guide) | Your sending IP and reputation |
Note that 5.4.1 appears twice in Microsoft's table with different meanings. Read the text after the code, not only the number.
What should the sender do?
Treat it as a hard bounce to an address that does not exist, and check the address before anything else.
- Read the address in the bounce. Look for a typo, a missing letter, or a wrong domain such as
.cofor.com. - Confirm with the person by another channel if the address came from a form, an import or a guess.
- Try one other address at the same domain. If a different person there receives your mail, the domain is fine and this one address is invalid.
- Stop retrying. A 550 is a permanent failure. Repeated sends to a nonexistent address add to your bounce rate for no gain, as covered in hard vs soft bounces.
- Suppress the address in your sending system so the next campaign or trigger skips it.
If your own customers get this bounce from your app, the plain-language version is: the address you entered does not exist at that company. Our post on explaining a bounced email to a customer has wording that works.
What if the address definitely exists?
Then the recipient's directory and the edge service disagree, and only the recipient's administrator can fix it. Pass them the full bounce. Microsoft's fix article for 5.4.1 gives these steps for an administrator in the recipient's organization:
- Check the spelling of the recipient's address in the NDR.
- Decide whether it affects one recipient or everyone in the domain.
- If everyone at the domain is affected, in the Exchange admin center go to Mail flow > Accepted domains, select the domain, switch its type from Authoritative to Internal relay, then switch back to Authoritative. Microsoft describes this as resyncing the domain.
- If one recipient is affected and has an on-premises mailbox in a hybrid environment with directory sync, reset the SMTP proxy address: change it to a temporary address, then revert it. Microsoft says to allow up to 24 hours for DBEB to fully update after on-premises changes.
- If the recipient is an on-premises mail-enabled public folder, verify it is synced to Exchange Online.
- If it is an on-premises dynamic distribution group in a hybrid setup, create a mail contact in Exchange Online with the same external address, because those groups cannot be synced.
Microsoft also notes that in hybrid environments DBEB only works as designed when the domain's MX record points to Microsoft 365, so mail is routed there first.
Why does this show up during a migration?
Because the accepted domain type decides whether Microsoft 365 treats itself as the only home for a domain's mail. Microsoft's guidance is to leave the domain as Internal relay while you are adding users, and switch to Authoritative only after every intended recipient is in Exchange Online and fully replicated. Switching too early makes real addresses that still live on the old system bounce with 5.4.1.
If you are on the sending side of someone's migration, the symptom is a customer whose mail worked last week and now returns 5.4.1 for some staff. Tell them the exact bounce text. It points their administrator at the directory and the domain type, not at you.
How does this look to an application that sends email?
Your sending system should classify it from the code and text, not from a human reading. A simple rule set:
550 5.4.1 + "Recipient address rejected" -> permanent, recipient invalid, suppress
550 5.4.1 + "Relay Access Denied" -> permanent for now, recipient domain misconfigured, flag the domain
550 5.7.x -> sender-side problem, do not suppress the addressSuppressing on every 550 is the common mistake: a 5.7.x policy block says nothing about whether the address is real. For how to wire bounce events into your own database, see the bounce and complaint webhook pipeline and per-customer suppression.
Koltrix's transactional email API and webhooks report bounces so your app can react to them; see docs.koltrix.com for the event fields.
Checklist for a 5.4.1 bounce
- I copied the full text after the code, not just "5.4.1".
- The text says "Recipient address rejected: Access denied" (an address problem) and not "Relay Access Denied" (a domain problem).
- I checked the address for typos and confirmed it with the owner.
- I tested another address at the same domain.
- I stopped retrying and suppressed the address.
- If the address is valid, I sent the bounce to the recipient's administrator with the accepted domain and proxy address steps above.
Bottom line
550 5.4.1 Recipient address rejected: Access denied is Exchange Online's Directory-Based Edge Blocking telling you the address does not exist in the recipient's tenant. Fix the typo, or ask the recipient's administrator to check their directory sync and the domain type, then suppress the address if it stays invalid. Leave your own DNS and reputation alone: they were not part of this rejection.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
